assembly in future C standard
fermineutron
and raw assembly code. A while back I asked a question about such
syntax and was told that __asm is not a part of a C standard. My
question now is:
Is there a chance that such statement will become a part of C standard
in the future? In some cases using asm language is the best way to
acomplish some small task, hence integration of C and asm would greatly
enhence C, or atleast it would in my opinion.
Is there a good reason why __asm is not a part of current C standard?
I have bumped into compilers that support and others that ignore __asm
statement so obviously it is still not a part of C standard.
Richard Heathfield
> Some compilers support __asm{ } statement which allows integration of C
> and raw assembly code. A while back I asked a question about such
> syntax and was told that __asm is not a part of a C standard. My
> question now is:
>
> Is there a chance that such statement will become a part of C standard
> in the future?
No.
> In some cases using asm language is the best way to
> acomplish some small task, hence integration of C and asm would greatly
> enhence C, or atleast it would in my opinion.
No.
> Is there a good reason why __asm is not a part of current C standard?
Yes.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Andrew Poelstra
> Is there a chance that such statement will become a part of C standard
> in the future? In some cases using asm language is the best way to
> acomplish some small task, hence integration of C and asm would greatly
> enhence C, or atleast it would in my opinion.
>
I'd say no, but the fact that system() is a part of the C standard
makes that answer questionable.
> Is there a good reason why __asm is not a part of current C standard?
>
It's 100% non-portable among different architectures, which is contrary
to the spirit of C.
--
Andrew Poelstra <http://www.wpsoftware.net/projects/>
Michal Nazarewicz
> Is there a good reason why __asm is not a part of current C standard?
It'll make C language not portable.
--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>---<jid:mina86*chrome.pl>--ooO--(_)--Ooo--
sjde...@yahoo.com
>
> Is there a good reason why __asm is not a part of current C standard?
>
non-portable between different implementations.
Even on the same OS and hardware assembly language may differ. e.g. on
Windows, Microsoft VC++ uses the MASM:
mov ebx, eax
(AKA "Intel syntax")
while gcc uses the AT&T-style:
movl %eax, %ebx
(AKA "AT&T syntax")
The instruction name, register ordering, and register syntax are all
different. And that's on the same OS & architecture. If you change
chips, the target assembly language won't even bear the superficial
simlarities seen here. To standardize __asm or __asm__ even only on
one platform would mean standardizing the entire assembly language for
that platform too, and even then it wouldn't result in code being
portable to other hardware.
Thomas Lumley
fermineutron wrote:
> Some compilers support __asm{ } statement which allows integration of C
> and raw assembly code. A while back I asked a question about such
> syntax and was told that __asm is not a part of a C standard. My
> question now is:
>
> Is there a good reason why __asm is not a part of current C standard?
As everyone else has pointed out, you can't portably specify the output
of a program that contains any call to __asm{} and so it isn't in the
proper domain of the C standard.
The C standard does specify that __asm is in the implementation
namespace. This means that an implementation can choose to specify what
__asm{} does, without causing any name clashes with portable code, and
presumably without any conflicts with subsequent versions of the
Standard. That's about all you *can* guarantee for raw assembly code,
and it is quite a useful guarantee.
-thomas
jacob navia
> fermineutron wrote:
>
>>Is there a good reason why __asm is not a part of current C standard?
>>
>
> Yes. There's no portable assembly, using it makes your code
> non-portable between different implementations.
>
My qfloat package has been ported to linux/windows/ and it will run
(unmodified) under Solaris, Mac (x86) and aix (x86).
Assembly is quite portable between OSes, but not within
different processors
fermineutron
jacob navia wrote:
> My qfloat package has been ported to linux/windows/ and it will run
> (unmodified) under Solaris, Mac (x86) and aix (x86).
>
> Assembly is quite portable between OSes, but not within
> different processors
Makes sense.
I guess portability of C is a bigger Ace than the gain from clock-cyle
level of the CPU controll.
Richard Heathfield
>
> jacob navia wrote:
>>
>> Assembly is quite portable between OSes, but not within
>> different processors
>
> Makes sense.
Would that it were true - but it isn't. There is no such thing as "assembly
language". There are, rather, a great many assembly languages. One
particular assembly language may well be portable between two or even more
OSs, and yet not be portable between two different assemblers on the same
OS. One assembly language may be portable between two different assemblers
on the same OS, and yet not be portable to some other OS.
> I guess portability of C is a bigger Ace than the gain from clock-cyle
> level of the CPU controll.
It depends what you need. But the best solution to your immediate problem -
that of performance - lies in choosing better, faster algorithms and
implementing them well. You have a great many gains to realise from doing
this; if you do it well, you may well decide that you have no need for any
assembly language after all. Implementing your current algorithms in some
assembly language or other is unlikely to result in significant performance
improvements.
Eric Sosman
Inserting assembly language into the middle of C code (if
the compiler permits it) is rarely the road to a noticeable
performance improvement. It may even disimprove performance by
creating an "opaque" section whose purpose the compiler cannot
fathom, thus inhibiting optimizations that would span the area
of impenetrable code. Once in a very great while, embedded
assembly is the cat's pajamas -- but most of the time the cat
sleeps nude.
A more usual motivation is to make use of special machine
instructions the compiler would not generate on its own. If
you need to fetch a value with "cache-bypass load" or execute
the "refresh TLB tag bits" instruction, injecting assembly into
the middle of the C source may be attractive. But even in such
cases it is usually cleaner to package the screwball instructions
in external functions that are themselves written in assembly,
and write an ordinary function call in the C code. This has the
benefit of pulling the machine-dependent stuff out of the main
stream of your program, making it easier to substitute "morally
equivalent" external functions when porting the code to new
platforms. You are almost always better off writing and calling
an AtomicIncrementInt() function than trying to embed assembly
for a compare-and-swap loop.
--
Eric Sosman
eso...@acm-dot-org.invalid
Chris Torek
Eric Sosman <eso...@acm-dot-org.invalid> wrote:
> A more usual motivation is to make use of special machine
>instructions the compiler would not generate on its own. If
>you need to fetch a value with "cache-bypass load" or execute
>the "refresh TLB tag bits" instruction, injecting assembly into
>the middle of the C source may be attractive. But even in such
>cases it is usually cleaner to package the screwball instructions
>in external functions that are themselves written in assembly,
>and write an ordinary function call in the C code. This has the
>benefit of pulling the machine-dependent stuff out of the main
>stream of your program, making it easier to substitute "morally
>equivalent" external functions when porting the code to new
>platforms. You are almost always better off writing and calling
>an AtomicIncrementInt() function than trying to embed assembly
>for a compare-and-swap loop.
I agree with all of this; however, in some (sometimes significant)
cases (e.g., the actual implementation for a mutex), you may want
to have an inline expansion of the underlying atomic operation,
typically via a macro. For instance, if you have a mutex construct
that -- at least in the uncontested case -- is just a (possibly
locked) compare-and-swap, you may want the x86-specific version
of:
MUTEX_GET(mutex_ptr);
to turn into the assembly equivalent of:
if (compare_and_exchange(mutex_ptr->key, __self()->key) != SUCCEEDED)
mutex_get_contested(mutex_ptr); /* blocks until success */
The tricky part lies not only in arranging for the assembly equivalent
to be inserted inline, but in *also* informing the compiler that
it must not move certain memory operations across the "special"
instruction(s). That is, if the mutex protects a data structure,
the compiler *must not* turn:
MUTEX_GET(&data->mutex);
data->field = newvalue;
MUTEX_RELEASE(&data->mutex);
into, e.g.:
data->field = newvalue;
MUTEX_GET(&data->mutex);
MUTEX_RELEASE(&data->mutex);
The compiler may think the second version is superior (because it
uses less CPU time overall, e.g., due to reduced register pressure
or because it schedules better), but in fact, it is not. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
fermineutron
Richard Heathfield wrote:
> It depends what you need. But the best solution to your immediate problem -
> that of performance - lies in choosing better, faster algorithms and
> implementing them well. You have a great many gains to realise from doing
> this; if you do it well, you may well decide that you have no need for any
> assembly language after all. Implementing your current algorithms in some
> assembly language or other is unlikely to result in significant performance
> improvements.
Well, it seems to me that it is not so much the speed gain as a
functionality gain that can be realized from assembly language. For
example, a while back i wrote a simple C profiler, which parces C file
and inserts RDTSC statements before and after each C statement, hence
determining the number of clock cycles it took to execute that line of
code. Now the only compiler that my profiler will work with is lcc
because the RDTSC is a part of intrinsics library of LCC, but it is not
a part of BC++ 5.02 for example. Had there been a full support for
assembly code within C I could have used inline assembly to do this and
not rely on intrinsics library of LCC.
To the best of my knowlege most of modern C compilers produce assembly
code whih is as good as one could optimize it by hand, so clearly there
is no speed gain from asm for a general purpose code.
Speaking of speed gains:
Richard, you may be pleased to hear that after reworking my code for
calculation of factorials of large numbers, to not use the stack space
but to use malloc instead, i realized a performance gain of about 60
times. So a correctly writtec C code does not loose to correctly
writtem asm code in speed, but it is somewhat limited in CPU control.
Theoretically it seems possible to develop a subset of assembly
languages which are used by motern CPUs and include in a C standard a C
library which would allow user to use the assembly subset. Since it is
a limited subset and its sintax is goverened by C it should not present
portability challenges with possible exception of older systems. any
thoughts about this?
Gordon Burditt
>and raw assembly code. A while back I asked a question about such
>syntax and was told that __asm is not a part of a C standard. My
>question now is:
>
>Is there a chance that such statement will become a part of C standard
>in the future?
NO. And I believe the same applies to __COBOL{}.
>In some cases using asm language is the best way to
>acomplish some small task, hence integration of C and asm would greatly
>enhence C, or atleast it would in my opinion.
In my opinion, you should write a function in pure asm, assemble
it separately, and link it with the C program. That requires you
to know things like function linkage conventions, symbol naming
conventions, etc.
If you write inline assembly, how does the assembly talk to the
non-assembly part, as far as passing data between them? The part
about function linkage conventions and symbol naming conventions
aren't enough. You have to have "unwarranted chumminess with the
compiler" to know what register the compiler puts stuff in.
>Is there a good reason why __asm is not a part of current C standard?
There's no way to describe what the stuff in the {} DOES in any
reasonable way. There are, for example, often several
mutually-incompatible assembly languages for the *SAME* CPU.
And, unlike system(), you can't generate the assembly-language
code at runtime for the purpose of passing data to it.
Peter Nilsson
> > Is there a good reason why __asm is not a part of current C standard?
>
> There's no way to describe what the stuff in the {} DOES in any
> reasonable way.
There doesn't actually need to be. C++ has...
An asm declaration has the form
asm-definition:
asm ( stringliteral ) ;
The meaning of an asm declaration is implementation defined.
The question is better asked in comp.std.c. But as I see it, the
purpose
of standardisation is to bring common elements into line. But trying
to bring into line a can of worms can be difficult. I know of many C++
implementations that don't support the standard form of asm, but have
retained their own syntax.
Looking back, I imagine many prestandard compilers already had their
own inline assembler syntax and that those implementations, as today,
varied wildly.
> There are, for example, often several mutually-incompatible assembly
> languages for the *SAME* CPU.
True, but system() is often subject to the same problems. [Generate a
command that calls a function and pipes the output to a given name
and it will work under one implementation and not others, even on
the same platform. Quoting arguments that contain whitespace can
be handled differently by different implementations on the same
platform.]
Perhaps the most non-portable programming that is in the standard is
support for locales.
> And, unlike system(), you can't generate the assembly-language
> code at runtime for the purpose of passing data to it.
Some old implementations allowed you to put machine code into an
unsigned char and 'call' that code like a function. However there are
problems on modern machines, e.g. instruction caching, and code
data lying in non-executable segments.
The system() function brings up the topic of command line options.
Lot's of programs use argc/argv, but their use itself is inherently
(even if not dramatically) non-portable. For example, some
implementations will perform wildcard replacement for you, others
won't.
> > I have bumped into compilers that support and others that ignore __asm
> > statement so obviously it is still not a part of C standard.
Contrary to Richard Heathfield's categorical statement, it is not an
absolute given that there will never be an asm keyword in C. But it
is unlikely because it's already clear that the asm keyword in C++ has
not served to truly standardise the syntax of inline assembly.
At the end of the day, the committee could probably spend many man
weeks deciding issues on an __asm keyword, but for what? Most
implementations will keep their existing syntax, and most programmers
who use inline assembly will no doubt continue to prefer the localised
syntax because it's less cumbersome than any standard syntax.
--
Peter
Christopher Benson-Manica
(Crossposted to comp.std.c, with followups directed there, hopefully
appropriately. The original post discussed the possibility of whether
__asm or something similar to it would be added to the C standard.)
> Contrary to Richard Heathfield's categorical statement, it is not an
> absolute given that there will never be an asm keyword in C. But it
> is unlikely because it's already clear that the asm keyword in C++ has
> not served to truly standardise the syntax of inline assembly.
One idea that was not mentioned in the original thread (I imagine for
good reason, because it's a half-baked and probably stupid idea that
occurred to me reading your post) would be to allow for some kind of
conditional assembly, just perhaps something like
#pragma assemble
#pragma X86 /* Inner pragma's implementation-defined */
/* Inline assembly, which the implementation can ignore or not */
#pragma no-assemble
/* Stock C code for implementations that can't or won't accept the
* assemble pragma: */
for( i=1; i < 10; i++ ) {
foo();
/* ... */
}
#pragma end-assemble
The end result would be something like "If the implementation attempts
to inline the assembly code contained within a #pragma assemble
directive, the behavior is implementation-defined. Otherwise the
assembly code shall be ignored and the C code contained within any
corresponding #pragma no-assemble directive shall be compiled as
though no directives were present." It would require adding some
duties to the #pragma directive, but it would allow implementors to
take a reasonable shot at using targetted assembly instructions when
appropriate and available, and reverting to ordinary C otherwise.
I'm sure there are reasons why this is stupid and/or impossible, or it
would have been done already :-)
> At the end of the day, the committee could probably spend many man
> weeks deciding issues on an __asm keyword, but for what? Most
> implementations will keep their existing syntax, and most programmers
> who use inline assembly will no doubt continue to prefer the localised
> syntax because it's less cumbersome than any standard syntax.
Indeed, but it's an interesting thought experiment to consider how the
committee *might* add assembly to C if they chose to do so. (Well,
interesting to me, at least.)
--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Keith Thompson
[...]
> Contrary to Richard Heathfield's categorical statement, it is not an
> absolute given that there will never be an asm keyword in C. But it
> is unlikely because it's already clear that the asm keyword in C++ has
> not served to truly standardise the syntax of inline assembly.
>
> At the end of the day, the committee could probably spend many man
> weeks deciding issues on an __asm keyword, but for what? Most
> implementations will keep their existing syntax, and most programmers
> who use inline assembly will no doubt continue to prefer the localised
> syntax because it's less cumbersome than any standard syntax.
C99 Annex J (J.5.10) shows "asm" as a common extension:
J.5.10 The asm keyword
The asm keyword may be used to insert assembly language directly
into the translator output (6.8). The most common implementation
is via a statement of the form:
asm ( character-string-literal );
Of course, such an extension would render the implementation
non-conforming, since it would break some strictly conforming
programs.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Richard Heathfield
>
> Richard Heathfield wrote:
>
>> Implementing your current algorithms in
>> some assembly language or other is unlikely to result in significant
>> performance improvements.
>
>
> Well, it seems to me that it is not so much the speed gain as a
> functionality gain that can be realized from assembly language.
Um, *what*?
> For
> example, a while back i wrote a simple C profiler, which parces C file
> and inserts RDTSC statements before and after each C statement,
Note that the term "RDTSC" is meaningless unless you happen to be using an
Intel processor in the x86 family, from the Pentium onwards, or a clone
thereof. Any code you write that relies on an RDTSC instruction is
inherently non-portable.
> hence
> determining the number of clock cycles it took to execute that line of
> code. Now the only compiler that my profiler will work with is lcc
> because the RDTSC is a part of intrinsics library of LCC, but it is not
> a part of BC++ 5.02 for example. Had there been a full support for
> assembly code within C I could have used inline assembly to do this and
> not rely on intrinsics library of LCC.
BC++ 5.02 supports inline assembly language. So does Visual C++. Both are C
compilers if you tickle them properly. In both it is possible to access the
RDTSC by using the inline assembly language supported by that
implementation. It is also possible to access the RDTSC through inline
assembly language in gcc, which exists for your platform. But since inline
assembly language itself is not standardised, you may well end up having to
rewrite the program for each new platform. If you don't like this, complain
simultaneously to every assembly language designer in the world.
> To the best of my knowlege most of modern C compilers produce assembly
> code whih is as good as one could optimize it by hand, so clearly there
> is no speed gain from asm for a general purpose code.
>
> Speaking of speed gains:
> Richard, you may be pleased to hear that after reworking my code for
> calculation of factorials of large numbers, to not use the stack space
> but to use malloc instead, i realized a performance gain of about 60
> times.
I am delighted to hear it, but it would have been wiser to fix the bugs
first. Still, okay, you've got the speed somewhere approaching sensible, so
- better late than never, and now would therefore be a good time to fix
those bugs.
> So a correctly writtec C code does not loose to correctly
> writtem asm code in speed, but it is somewhat limited in CPU control.
It is certainly true that correctly written C code can be of comparable
performance to correctly written assembly language code, but with the added
advantage that it can run on any computer. Weighing C down with some way of
tickling the frobnitz might sound attractive to those with a frobnitz-based
machine, but everyone else is bound to see it as pointless fluff.
> Theoretically it seems possible to develop a subset of assembly
> languages which are used by motern CPUs
Feel free to try. Don't forget to include CPUs manufactured by Cray, Unisys,
the mainframe division of IBM, Analog, Motorola... and many many more
besides. Once you see how long the list is, and how many different assembly
languages with different syntaxes are out there, you'll realise why nobody
is doing this.
sjde...@yahoo.com
Seems like you're using an odd definition of "portable" here. On
common platforms assembly is not portable between different
compilers/assemblers on the same OS and architecture, let alone between
OSes. Certainly on a single architecture it's possible to write an
assembler that runs under many OSes, but having just one standard
assembly language even in one OS is _not_ the current state of the
world on everyday architectures--witness the x86 example I gave in the
message you replied to.
Rod Pemberton
"fermineutron" <free4t...@yahoo.com> wrote in message
news:1162076742....@b28g2000cwb.googlegroups.com...
> Theoretically it seems possible to develop a subset of assembly
> languages which are used by motern CPUs and include in a C standard a C
> library which would allow user to use the assembly subset. Since it is
> a limited subset and its sintax is goverened by C it should not present
> portability challenges with possible exception of older systems. any
> thoughts about this?
>
You should ignore any response Healthfield gives to your question.
This problem was solved in the very first assembly language:
http://en.wikipedia.org/wiki/Autocode
A modern version is available here:
http://microautocode.sourceforge.net/
It has also been solved by many other languages, the most effectively by
FORTH and C. If hadn't been solved, the basic features of the C language
wouldn't be portable (at all):
constants
variables
simple flow control (if,while,etc)
complex flow control (procedures, setjmp)
arithmetic (addition, bitshifts)
pointers
The above functionality of C can be represented by 16 "actions" and 20
arithmetic operations. That means that C can be written on an interpreter.
The highly portable QEMU emulator reduces host specific CPU instructions to
"micro-ops" for a virtual machine. Those "micro-ops" could be considered to
be a portable assembly. Research into the FORTH language, shows that the
_entire_ functionality of FORTH language (which is just as powerful as C)
reduces to 13 "primitives." Many years ago, I personally reduced the full
functionality 6502 instruction set (56) to minimal set of 13. Betov, the
nemesis of Randall Hyde, has reduced the x86 instruction to a minimal set
for his own use.
The table I compiled (below) is a basic comparison of the required
functionality of various FORTH's, C libraries (including Plauger, Redhat),
OS's (GNU, HURD) , and Java.
The following table lists these:
1) primitives - smallest FORTH instructions, coded in assembly
2) functions - FORTH functions, coded in FORTH
3) syscalls - OS specific system calls, usually through an interrupt
interface
4) bytecodes - interpreter functions
Note that primitives and functions are small routines in assembly and FORTH
respectively, while the other two are large assembly routines.
3 primitives - Frank Sargent's "3 Instruction Forth"
13 primitives - theoretical minimum needed to implement full FORTH
16,29 primitives - CH Moore's word set for the F21 CPU (minimal or full)
18 syscalls - OS specific functions required by P.J. Plauger's Standard
C Library
19 syscalls - OS specific functions required by Redhat's newlib
20 primitives - Philip Koopman's "dynamic instruction frequencies"
25 primitives - CH Moore's instruction set for MuP21 CPU
36 primitives - Dr. CH Ting's eForth, a highly portable forth
40 syscalls - Linux v0.01 (67 total, 13 unimplemented, 14 minimally, 40
moderately)
46 primitives - GNU's GFORTH for 8086
58-255 functions - FORTH-83 Standard (255 defined, 132 required, 58 nucleus)
60-63 primitives - considered the essence of FORTH by CH Moore
72 primitives - Brad Rodriguez's 6809 CamelForth
74-236 functions - FORTH-79 Standard (236 defined, 147 required, 74 nucleus)
94-229 functions - fig-FORTH Std. (229 defined, 117 required, 94 level zero)
~120 syscalls - OpenWATCOM v1.3, calls DOS, BIOS, DPMI for PM DOS apps.
133-? functions - ANS-FORTH Standard (? defined, 133 required, 133 core)
150 syscalls - GNU HURD kernel
170 syscalls - DJGPP v2.03, calls DOS, BIOS, DPMI for PM DOS apps.
200 functions - FORTH 1970, the original Forth by CH Moore
200 syscalls - Linux Kernel (POSIX.1)
206 bytecodes - Java Virtual Machine bytecodes
240 functions - MVP-FORTH (FORTH-79)
~1000 functions - F83 FORTH
~2500 functions - F-PC FORTH
Rod Pemberton
Keith Thompson
> "fermineutron" <free4t...@yahoo.com> wrote in message
> news:1162076742....@b28g2000cwb.googlegroups.com...
>> Theoretically it seems possible to develop a subset of assembly
>> languages which are used by motern CPUs and include in a C standard a C
>> library which would allow user to use the assembly subset. Since it is
>> a limited subset and its sintax is goverened by C it should not present
>> portability challenges with possible exception of older systems. any
>> thoughts about this?
>
> You should ignore any response Healthfield gives to your question.
That's really bad advice.
Kenny McCormack
Keith Thompson <ks...@mib.org> wrote:
>"Rod Pemberton" <do_no...@bitfoad.cmm> writes:
>> "fermineutron" <free4t...@yahoo.com> wrote in message
>> news:1162076742....@b28g2000cwb.googlegroups.com...
>>> Theoretically it seems possible to develop a subset of assembly
>>> languages which are used by motern CPUs and include in a C standard a C
>>> library which would allow user to use the assembly subset. Since it is
>>> a limited subset and its sintax is goverened by C it should not present
>>> portability challenges with possible exception of older systems. any
>>> thoughts about this?
>>
>> You should ignore any response Healthfield gives to your question.
>[snip]
>
>That's really bad advice.
Said Tweedle Dee of Tweedle Dumb.
Richard Heathfield
> "Rod Pemberton" <do_no...@bitfoad.cmm> writes:
>> You should ignore any response Healthfield gives to your question.
> [snip]
>
> That's really bad advice.
If he were capable of giving good advice, he would probably also be capable
of spelling my name correctly.
CBFalconer
>
... snip ...
>
> Note that the term "RDTSC" is meaningless unless you happen to be
> using an Intel processor in the x86 family, from the Pentium
> onwards, or a clone thereof. Any code you write that relies on an
> RDTSC instruction is inherently non-portable.
Which is what Jacob has done in lcc-win32, thus making it unusable
on any 486 system. He obviously has failed to guard its use
against the executing CPU. He can't even find the offensive code,
as of several years ago. This is a good illustration of the
penalties for using non-standardisms cavalierly.
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Kenny McCormack
Richard Heathfield <inv...@invalid.invalid> wrote:
>Keith Thompson said:
>
>> "Rod Pemberton" <do_no...@bitfoad.cmm> writes:
>
>>> You should ignore any response Healthfield gives to your question.
>> [snip]
>>
>> That's really bad advice.
>
>If he were capable of giving good advice, he would probably also be capable
>of spelling my name correctly.
Typos hppen.
Don't take it personally. Don't go all girly, girly on us now.
fermineutron
CBFalconer wrote:
> Which is what Jacob has done in lcc-win32, thus making it unusable
> on any 486 system. He obviously has failed to guard its use
> against the executing CPU. He can't even find the offensive code,
> as of several years ago. This is a good illustration of the
> penalties for using non-standardisms cavalierly.
>
This seems to develop into an optimization problem. That is, compiler
authors have to choose between limiting their code output to
instruction set of older CPUs and perhaps realizing a speed gain from
modern architecture.
For example lets consider realoc function, or more precicely the copy
portion of that function.
The most comforming way would be to move 4 bytes into EAX register from
mem1, then move 4 bytes fom EAX register to mem2, increment mem1 and
mem2 by 4, loop untill all data is copied. Probably moving 1 byte at a
time is even more conforming, since then we do not have to worry wether
the size of the data to be copied is a multiple of 4.
Now a better way for a modern system would be to use the MMX registers,
to copy data in larger chunks.
So the question becomes: should the compiler author implement method 1
or method 2?
Probably 90% of moden CPUs will accept code generated by method 2,
which is allot faster than method 1.
Some compilers will give an option to which set of cpu instruction
limit the compiler output, but not all.
So now, that modern CPUs are quite different from older ones, the C
standard comity is faced with a disision of to what extent, in time,
the C stndard has to be portable. Just like the 32 bit code is not
expected to run on 16 bit machine, why should C code written in
complience with standard XX run on a cpu predated XX. This does not
violate requirement that code written prior to XX standard has to run
on XX standard.
Again ill use an example of RDTSC (ReaD Time Stamp Counter):
A C call to a function tat uses RDTSC is non-portable to older cpus, i
think 586 is the 1st one that recognizes RDTSC. Now, does that mean
that C code which uses RDTSC can not conform to modern day C standard?
I think that when C99 came out RDTSC was already supported by CPUs, so
shouldn't C99 recognize code implementing RDTSC as conforming to C99
standard. If yes then why RDTSC call can not be a part of C99 standard
library.
Naturally mnemonic and opcode for RDTSC cpu instruction will be
different for different processors, but as long as compiler knows what
that opcode for a given cpu is, a compiler can compile code that uses
RDTSC to run on what ever cpu the compiler is intended for.
By the way, returning to the minimal list of cpu instructions, i thing
that thre true bare bone will have 2 instructiions, Move and Add. Move
can be used to read and write, whie add can be used to to addition,
subtraction, multiplication and division. Shift instructions would
speed it up, but are redundant. So if C is to be truly compatible
whith anything and everything, should not it limit the compiler output
to these 2 instructions. Obviously its an overkill, but gets my point
across.
Flash Gordon
<snip>
> So now, that modern CPUs are quite different from older ones, the C
> standard comity is faced with a disision of to what extent, in time,
> the C stndard has to be portable. Just like the 32 bit code is not
> expected to run on 16 bit machine,
It is quite possible to write code that will run on 16 bit, 32 bit, 64
bit and any other size machine. You just have to do it correctly,
something that the C99 standard makes a bit easier,
> why should C code written in
> complience with standard XX run on a cpu predated XX.
Because a lot of CPUs pre-dating the standard still have code actively
being developed for them.
> This does not
> violate requirement that code written prior to XX standard has to run
> on XX standard.
Actually, that gets broken to an extent. For example removing implicit
int in C99 means that some valid C89 code is not valid C99 code. Of
course they are selective about such things.
> Again ill use an example of RDTSC (ReaD Time Stamp Counter):
> A C call to a function tat uses RDTSC is non-portable to older cpus, i
> think 586 is the 1st one that recognizes RDTSC. Now, does that mean
> that C code which uses RDTSC can not conform to modern day C standard?
> I think that when C99 came out RDTSC was already supported by CPUs, so
> shouldn't C99 recognize code implementing RDTSC as conforming to C99
> standard. If yes then why RDTSC call can not be a part of C99 standard
> library.
>
> Naturally mnemonic and opcode for RDTSC cpu instruction will be
> different for different processors, but as long as compiler knows what
> that opcode for a given cpu is, a compiler can compile code that uses
> RDTSC to run on what ever cpu the compiler is intended for.
Now what about the processors that simply don't have anything of the
sort? What about Windows systems which have the problems mentioned here
http://en.wikipedia.org/wiki/RDTSC ? I'm sure the problem is not limited
to Windows.
> By the way, returning to the minimal list of cpu instructions, i thing
> that thre true bare bone will have 2 instructiions, Move and Add. Move
> can be used to read and write, whie add can be used to to addition,
> subtraction, multiplication and division. Shift instructions would
> speed it up, but are redundant. So if C is to be truly compatible
> whith anything and everything, should not it limit the compiler output
> to these 2 instructions. Obviously its an overkill, but gets my point
> across.
C specifies nothing about what instructions the compiler output uses.
This means that implementers are free to make the best possible use of
the processors instruction set that they can manage.
The C standard attempts to strike a sensible balance between being
possible to implement on a wide range of systems and providing useful
functionality. Since the authors of the standard know rather more about
what systems are out there than you do I'm rather more inclined to trust
their judgement on the matter than yours.
--
Flash Gordon
jacob navia
and since that compiler has an assembler, using that assembler
makes your code portable to any of those architectures. That is
why lcc-win32 uses ATT syntax and NOT Intel's syntax.
Richard Heathfield
> In article <X5qdnfxpSrIWNtnY...@bt.com>,
> Richard Heathfield <inv...@invalid.invalid> wrote:
>>Keith Thompson said:
>>
>>> "Rod Pemberton" <do_no...@bitfoad.cmm> writes:
>>
>>>> You should ignore any response Healthfield gives to your question.
>>> [snip]
>>>
>>> That's really bad advice.
>>
>>If he were capable of giving good advice, he would probably also be
>>capable of spelling my name correctly.
>
> Typos hppen.
...over and over again. Yeah, right.
> Don't take it personally.
Oh, I don't.
Default User
> "Rod Pemberton" <do_no...@bitfoad.cmm> writes:
> > You should ignore any response Healthfield gives to your question.
> [snip]
>
> That's really bad advice.
Pemberton is a troll.
Pemberton is a troll.
Pemberton is a troll.
Pemberton is a troll.
Pemberton is a troll.
Brian
Eric Sosman
> Richard Heathfield wrote:
>
>
>>It depends what you need. But the best solution to your immediate problem -
>>that of performance - lies in choosing better, faster algorithms and
>>implementing them well. You have a great many gains to realise from doing
>>this; if you do it well, you may well decide that you have no need for any
>>assembly language after all. Implementing your current algorithms in some
>>assembly language or other is unlikely to result in significant performance
>>improvements.
>
>
>
> Well, it seems to me that it is not so much the speed gain as a
> functionality gain that can be realized from assembly language. For
> example, a while back i wrote a simple C profiler, which parces C file
> and inserts RDTSC statements before and after each C statement, hence
> determining the number of clock cycles it took to execute that line of
This strategy is almost guaranteed to produce a wrong answer.
Ever done "step to next line" in a debugger after an optimizing
compiler has had a whack at the code? You may have noticed that
the apparent position in the source jumps around a lot: You start
at line L, step once and hit L+1, step again to line L, step again
to line L+3, step again to line L-1, ... Then you look at the
actual instructions, and you see that they're a sort of Cuisinarted
puree of bits and pieces from a whole lot of nearby lines, plus a
few things from lines that are quite a ways off, and maybe even a
few that aren't easily attributed to any particular line at all.
Then again, the presence of all these foreign tidbits may just
tie the optimizer's hands, preventing aggressive reorganizations and
forcing the code generator into a line-at-a-time mode. If so, you've
instrumented something that's quite different from the uninstrumented
programs you'll actually wind up running, and you get a very accurate
measurement of something not very relevant.
--
Eric Sosman
eso...@acm-dot-org.invalid
jacob navia
> Some compilers support __asm{ } statement which allows integration of C
> and raw assembly code. A while back I asked a question about such
> syntax and was told that __asm is not a part of a C standard. My
> question now is:
>
> Is there a chance that such statement will become a part of C standard
> acomplish some small task, hence integration of C and asm would greatly
> enhence C, or atleast it would in my opinion.
>
>
> statement so obviously it is still not a part of C standard.
>
From the compiler's perspective, the _asm() keyword is quite
difficult...
In lcc-win32 (as in any other compiler by the way) there are some
assumptions about which registers are used/free, which are scratch,
which are saved across function calls and which are not.
If you make some assembly code inline, you better do not
touch those assumptions and follow them 100%. If not, a sure
catastrophe is bound to happen, since the compiler will not
parse asm statements to figure out which registers did you
use.
In general _asm() will interact very badly with the optimizer,
specially the peephole optimizer of lcc-win32. Since
the optimizer is geared to code produced by the compiler, it will
get confused by your asm statements.
To avoid this problems, gcc has developed a language that
has been always a closed book for me, where you describe your
assembly statements to the compiler.
That language is a pure horror, I have never been able to understand
it even after some time spent (wasted?) in it.
Obviously that is a better solution that asm, but it
would be very difficult to standardize.
Because of this problems, asm() usage in lcc-win32 is severely
restricted and fifficult to use. The assembler anyway, is completely
machine oriented, and putting (for instance) an extra blank in
your instruction will produce a crash:
movl -8(%ebp),%eax
is not the same as
movl -8(%ebp),%eax
since in the first line there is a tab (acccepted)
and in the second there are 8 spaces (crash).
Nothing has been done to support asm() really, and with a reason, see
above.
In general is better to put your assembly language functions in
a separate file and use a human oriented assembler, with macros,
and all the things you need to debug your assembly
programs...
jacob
Keith Thompson
> Richard Heathfield wrote:
>>
> ... snip ...
>>
>> Note that the term "RDTSC" is meaningless unless you happen to be
>> using an Intel processor in the x86 family, from the Pentium
>> onwards, or a clone thereof. Any code you write that relies on an
>> RDTSC instruction is inherently non-portable.
>
> Which is what Jacob has done in lcc-win32, thus making it unusable
> on any 486 system. He obviously has failed to guard its use
> against the executing CPU. He can't even find the offensive code,
> as of several years ago. This is a good illustration of the
> penalties for using non-standardisms cavalierly.
I think you're talking about two different things. Richard, I think,
is talking about C code that uses some kind of inline assembly
extension to explicitly specify an RDTSC instruction; obviously such
source code will be portable only to systems that have the RDTSC
instruction (and to compilers that support that particular form of
inline assembly).
lcc-win32, if I understand you correctly, uses the RDTSC instruction
*in the generated code* for C source code that does not expliclitly
refer to it. Translating C source code to machine code is, of course,
what compilers do, and the generated machine code is potentially much
less portable than the C source from which it was generated. If
lcc-win32 generates code that won't work on a 486, that may be
inconvenient for some, but it's not a C language issue.
Keith Thompson
The compiler generates machine code from C source code. How it does
so is not the concern of the C language standard (or of this
newsgroup).
> So now, that modern CPUs are quite different from older ones, the C
> standard comity is faced with a disision of to what extent, in time,
> the C stndard has to be portable. Just like the 32 bit code is not
> expected to run on 16 bit machine, why should C code written in
> complience with standard XX run on a cpu predated XX. This does not
> violate requirement that code written prior to XX standard has to run
> on XX standard.
You used realloc() as an example. I can write perfectly portable C
code that uses realloc(); I don't care how the copying is implemented,
as long as it works. Obviously a compiler writer (actually, a runtime
library writer) does care, but that's not a C language issue.
> Again ill use an example of RDTSC (ReaD Time Stamp Counter):
> A C call to a function tat uses RDTSC is non-portable to older cpus, i
> think 586 is the 1st one that recognizes RDTSC. Now, does that mean
> that C code which uses RDTSC can not conform to modern day C standard?
> I think that when C99 came out RDTSC was already supported by CPUs, so
> shouldn't C99 recognize code implementing RDTSC as conforming to C99
> standard. If yes then why RDTSC call can not be a part of C99 standard
> library.
You want x86 instruction opcodes to be part of the C standard?
No.
> Naturally mnemonic and opcode for RDTSC cpu instruction will be
> different for different processors, but as long as compiler knows what
> that opcode for a given cpu is, a compiler can compile code that uses
> RDTSC to run on what ever cpu the compiler is intended for.
There may not be an RDTSC CPU instruction. There may be something
similar to it that behaves differently in some critical way.
If you want to write C, write C. If you want to specify individual
instructions write assembly language (possibly via some *non-standard*
compiler extension).
> By the way, returning to the minimal list of cpu instructions, i thing
> that thre true bare bone will have 2 instructiions, Move and Add. Move
> can be used to read and write, whie add can be used to to addition,
> subtraction, multiplication and division. Shift instructions would
> speed it up, but are redundant. So if C is to be truly compatible
> whith anything and everything, should not it limit the compiler output
> to these 2 instructions. Obviously its an overkill, but gets my point
> across.
Not really. Generated code is not portable. And, of course, move and
add are not nearly sufficient for general programming.
C source code specifies the behavior of the compiled program, in
accordance with the standard. It says nothing about the CPU
instructions used to implement that behavior.
Ian Collins
> Richard Heathfield wrote:
>
>
>>It depends what you need. But the best solution to your immediate problem -
>>that of performance - lies in choosing better, faster algorithms and
>>implementing them well. You have a great many gains to realise from doing
>>this; if you do it well, you may well decide that you have no need for any
>>assembly language after all. Implementing your current algorithms in some
>>assembly language or other is unlikely to result in significant performance
>>improvements.
>
>
>
> Well, it seems to me that it is not so much the speed gain as a
> functionality gain that can be realized from assembly language. For
> example, a while back i wrote a simple C profiler, which parces C file
> and inserts RDTSC statements before and after each C statement, hence
> determining the number of clock cycles it took to execute that line of
> code. Now the only compiler that my profiler will work with is lcc
> because the RDTSC is a part of intrinsics library of LCC, but it is not
> a part of BC++ 5.02 for example. Had there been a full support for
> assembly code within C I could have used inline assembly to do this and
> not rely on intrinsics library of LCC.
>
so you don't have to mess with the code. As Eric pointed out, you
probably are profiling something completely different form what you
would have without the intrusive test code.
--
Ian Collins.
Rod Pemberton
"Default User" <defaul...@yahoo.com> wrote in message
news:4qked8F...@individual.net...
> Keith Thompson wrote:
>
> > "Rod Pemberton" <do_no...@bitfoad.cmm> writes:
>
> > > You should ignore any response Healthfield gives to your question.
> > [snip]
> >
> > That's really bad advice.
>
> Pemberton is a troll.
>
My post was an accurate and informative response to the OP's question, with
covered both the issue of C and other languages which applied.
No. You're a troll and a coward. Be brave: use your last name (Rodenborn)
.
Rod Pemberton
Rod Pemberton
"Keith Thompson" <ks...@mib.org> wrote in message
news:lnmz7fx...@nuthaus.mib.org...
> "Rod Pemberton" <do_no...@bitfoad.cmm> writes:
> > "fermineutron" <free4t...@yahoo.com> wrote in message
> > news:1162076742....@b28g2000cwb.googlegroups.com...
> >> Theoretically it seems possible to develop a subset of assembly
> >> languages which are used by motern CPUs and include in a C standard a C
> >> library which would allow user to use the assembly subset. Since it is
> >> a limited subset and its sintax is goverened by C it should not present
> >> portability challenges with possible exception of older systems. any
> >> thoughts about this?
> >
> > You should ignore any response Healthfield gives to your question.
> [snip]
>
> That's really bad advice.
>
How so? It appears that your response is incorrectly biased...
Heathfield's response was totally incorrect and borders upon incompetence.
My response was the best introduction to the minimal necessary interface to
C and various C libraries and other languages that he'll ever get. He won't
find anything even remotely close in hundreds, if not thousands, of
programming books.
Rod Pemberton
Rod Pemberton
"Richard Heathfield" <inv...@invalid.invalid> wrote in message
news:X5qdnfxpSrIWNtnY...@bt.com...
> Keith Thompson said:
>
> > "Rod Pemberton" <do_no...@bitfoad.cmm> writes:
>
> >> You should ignore any response Healthfield gives to your question.
> > [snip]
> >
> > That's really bad advice.
>
> If he were capable of giving good advice, he would probably also be
capable
> of spelling my name correctly.
>
I'm sorry that I unintentionally mispelled of your name out of a thousand or
so. You know that I haven't mispelled it elsewhere. I guess it was a
convenient excuse for you to ignore the fact that your response was totally
incorrect and borders upon incompetence.
I'll reiterate:
Bill Reid
on any other topic...
...and isn't "Rod Pemberton" actually a porn name?
---
William Ernest Reid
Kenny McCormack
Yey, verily. I have rarely seen a more clearcut instance of PKB.
Kenny McCormack
Don't feed the netcop.
Also, bear in mind: Don't wrestle with a pig (and you know the rest).
Keith Thompson
> "Keith Thompson" <ks...@mib.org> wrote in message
> news:lnmz7fx...@nuthaus.mib.org...
>> "Rod Pemberton" <do_no...@bitfoad.cmm> writes:
>> > "fermineutron" <free4t...@yahoo.com> wrote in message
>> > news:1162076742....@b28g2000cwb.googlegroups.com...
>> >> Theoretically it seems possible to develop a subset of assembly
>> >> languages which are used by motern CPUs and include in a C standard a C
>> >> library which would allow user to use the assembly subset. Since it is
>> >> a limited subset and its sintax is goverened by C it should not present
>> >> portability challenges with possible exception of older systems. any
>> >> thoughts about this?
>> >
>> > You should ignore any response Healthfield gives to your question.
>> [snip]
>>
>> That's really bad advice.
>
> How so? It appears that your response is incorrectly biased...
Here's what Richard wrote:
| Would that it were true - but it isn't. There is no such thing as "assembly
| language". There are, rather, a great many assembly languages. One
| particular assembly language may well be portable between two or even more
| OSs, and yet not be portable between two different assemblers on the same
| OS. One assembly language may be portable between two different assemblers
| on the same OS, and yet not be portable to some other OS.
|
| [...]
|
| It depends what you need. But the best solution to your immediate problem -
| that of performance - lies in choosing better, faster algorithms and
| implementing them well. You have a great many gains to realise from doing
| this; if you do it well, you may well decide that you have no need for any
| assembly language after all. Implementing your current algorithms in some
| assembly language or other is unlikely to result in significant performance
| improvements.
Is that what you're referring to?
> Heathfield's response was totally incorrect and borders upon incompetence.
No, he was quite correct. If you disagree, by all means say so;
there's no need to make it personal.
> My response was the best introduction to the minimal necessary interface to
> C and various C libraries and other languages that he'll ever get. He won't
> find anything even remotely close in hundreds, if not thousands, of
> programming books.
That may or may not be true; I was commenting specifically on your
advice about what Richard wrote, not on the rest of your article.
Stephen Sprunk
news:1162076742....@b28g2000cwb.googlegroups.com...
>> It depends what you need. But the best solution to your immediate
>> problem - that of performance - lies in choosing better, faster
>> algorithms and implementing them well. You have a great many
>> gains to realise from doing this; if you do it well, you may well
>> decide that you have no need for any assembly language after all.
>> Implementing your current algorithms in some assembly language
>> or other is unlikely to result in significant performance
>> improvements.
>
> functionality gain that can be realized from assembly language.
Ah, but _which_ assembly language? There are hundreds of them, and they
contain orthogonal feature sets. Any common subset, if there even is
one, would be constrained to what you can express in C itself, rendering
the concept useless.
That also ignores the fact that the C standard's use of the word
"translator" allows for interpreters, which may not have any underlying
assembly language at all, and not just compilers.
> For example, a while back i wrote a simple C profiler, which parces
> C file and inserts RDTSC statements before and after each C statement,
> hence determining the number of clock cycles it took to execute that
> line of code. Now the only compiler that my profiler will work with is
> lcc
> because the RDTSC is a part of intrinsics library of LCC, but it is
> not
> a part of BC++ 5.02 for example. Had there been a full support for
> assembly code within C I could have used inline assembly to do this
> and not rely on intrinsics library of LCC.
How exactly is your program supposed to work on platforms that don't
have _any_ assembly instruction similar to RDTSC?
If you want to limit yourself to x86 platforms, you could have easily
created a macro that expands to compiler-specific assembly or
intrinsics. Your program would then add that macro definition to each
file it modified, and then insert calls to that macro instead of to
LCC's nonstandard intrinsic. That's about as "portable" as you're going
to get when you're looking for such implementation-dependent
functionality, and having a "standard" assembly language would merely do
the same thing (perhaps encapsulated in a <stdasm.h> header file to be
neat).
Another point is that once you instrument code, it necessarily changes
what the optimizer can do with it, and you're no longer measuring how
the original code performs but rather how the instrumented code
performs. It's quite easy to design a scenario where algorithm A runs
faster than algorithm B when instrumented, but B runs faster than A when
not instrumented. Physics has something similar called the Heisenberg
Uncertainty Principle -- the very act of measuring something necessarily
changes the value you were trying to measure.
> To the best of my knowlege most of modern C compilers produce assembly
> code whih is as good as one could optimize it by hand, so clearly
> there
> is no speed gain from asm for a general purpose code.
That is fundamentally false. A compiler will never produce code faster
than a competent human can, because the human can start with the
compiler's output and tune from there. Good asm programmers can improve
on that by a factor of two in many cases, and five in exceptional ones.
If you want the big gains, though, you need to change the algorithm
completely as RH noted, and you can typically do that while staying in
C.
> Theoretically it seems possible to develop a subset of assembly
> languages which are used by motern CPUs and include in a C standard a
> C
> library which would allow user to use the assembly subset. Since it is
> a limited subset and its sintax is goverened by C it should not
> present
> portability challenges with possible exception of older systems. any
> thoughts about this?
"with possible exception of older systems" is a large part of the point.
C runs on thousands of different implementations, and any changes to
Standard C must be available on all of them. There's a reason the
Standard is so vague on so many fundamental details, e.g. sizeof(int),
and that's so C can be available on the widest possible range of
platforms. When you start ignoring certain systems because they're
inconvenient, you're limiting the applicability of the standard.
That's fine in your own code, because you can make a judgement call
about how portable you want your code to be, but the ISO folks don't get
to make calls like that. They have to produce something that works on
everything from wristwatches to supercomputers to whatever we'll be
using 20 years from now. You don't get that by ignoring what's
inconvenient.
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com
Richard Heathfield
<snip>
>>
>> If he were capable of giving good advice, he would probably also be
> capable
>> of spelling my name correctly.
>>
>
> I'm sorry that I unintentionally mispelled of your name out of a thousand
> or
> so. You know that I haven't mispelled it elsewhere.
You know that, and I know that, but the Google archives disagree with us
both.
> I guess it was a
> convenient excuse for you to ignore the fact that your response was
> totally incorrect and borders upon incompetence.
I stand by the accuracy and correctness of my response.
John Bode
fermineutron wrote:
[snip]
> Theoretically it seems possible to develop a subset of assembly
> languages which are used by motern CPUs and include in a C standard a C
> library which would allow user to use the assembly subset. Since it is
> a limited subset and its sintax is goverened by C it should not present
> portability challenges with possible exception of older systems. any
> thoughts about this?
Here's a proposed set:
ARG : Agree to Run Garbage
BDM : Branch and Destroy Memory
CMN : Convert to Mayan Numerals
DDS : Damage Disk and Stop
EMR : Emit Microwave Radiation
ETO : Emulate Toaster Oven
FSE : Fake Serious Error
GSI : Garble Subsequent Instructions
GQS : Go Quarter Speed
HEM : Hide Evidence of Malfunction
IDD : Inhale Dust and Die
IKI : Ignore Keyboard Input
IMU : Irradiate and Mutate User
JPF : Jam Paper Feed
JUM : Jeer at Users Mistake
KFP : Kindle Fire in Printer
LNM : Launch Nuclear Missiles
MAW : Make Aggravating Whine
NNI : Neglect Next Instruction
OBU : Overheat and Burn if Unattended
PNG : Pass Noxious Gas
QWF : Quit Working Forever
QVC : Question Valid Command
RWD : Read Wrong Device
SCE : Simulate Correct Execution
SDJ : Send Data to Japan
TTC : Tangle Tape and Crash
UBC : Use Bad Chip
VDP : Violate Design Parameters
VMB : Verify and Make Bad
WAF : Warn After Fact
XID : eXchange Instruction with Data
YII : Yield to Irresistible Impulse
ZAM : Zero All Memory
PI : Punch Invalid
POPI : Punch Operator Immediately
RASC : Read And Shred Card
RPM : Read Programmers Mind
RSSC : Reduce Speed, Step Carefully (for improved accuracy)
RTAB : Rewind Tape and Break
RWDSK : ReWind DiSK
SPSW : Scramble Program Status Word
SRSD : Seek Record and Scar Disk
WBT : Water Binary Tree
Basically what you're asking for is an assembly language version of
Java. Is that *really* what you want?
Jordan Abel
John Bode wrote:
>
> fermineutron wrote:
>
> [snip]
>
>> Theoretically it seems possible to develop a subset of assembly
>> languages which are used by motern CPUs and include in a C standard a C
>> library which would allow user to use the assembly subset. Since it is
>> a limited subset and its sintax is goverened by C it should not present
>> portability challenges with possible exception of older systems. any
>> thoughts about this?
>
> Here's a proposed set:
(snip)
No HCF?
Where'd you get these anyway?
Bart
> Here's a proposed set:
You forgot the 'WTF' instruction. ;)
Regards,
Bart.
Chris Torek
jacob navia <ja...@jacob.remcomp.fr> wrote:
>In general _asm() will interact very badly with the optimizer,
>specially the peephole optimizer of lcc-win32. Since
>the optimizer is geared to code produced by the compiler, it will
>get confused by your asm statements.
>
>To avoid this problems, gcc has developed a language that
>has been always a closed book for me, where you describe your
>assembly statements to the compiler.
>
>That language is a pure horror, I have never been able to understand
>it even after some time spent (wasted?) in it.
Actually, it is a pretty straightforward system[%], using a constraint
model and gcc's internal "register transfer language" as the basic
building blocks. What you stick in a gcc "asm" statement is
essentially the same as what you stick in the machine description
file that gcc uses to produce machine code in the first place.
(There are some limitations and problems with this, that have
Special Hacks for them, more of which are accessible from the .md
files than from asm() constructs.)
>Obviously that is a better solution that asm, but it
>would be very difficult to standardize.
In particular, it ties you to RTL, and to those things that are
in the original .md file.
As an example, consider asm() constructs for x86 targets compared
to those for m68k targets. The "d" constraint on x86 refers to
the %edx register, but the "d" constraint on m68k refers to any
available data register (as opposed to any available address
register, which uses the letter "a" -- which on the x86 means the
%eax register).
Since the 680x0 has no %edx register, it makes no sense to tell
the asm() line that, e.g., the output of the instruction is in the
edx/eax register pair. Of course, the 680x0 has no "rdtsc"
instruction either.
[% Some of the corner cases get sticky: when do you use the "&"
constraint vs the "+" constraint, for instance? Use the wrong one
and the reload pass can get confused.]
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Arthur J. O'Dwyer
At first I thought that was a stupid question... but googling "tangle
tape and crash" turned up 64 hits. So, your question wasn't stupid;
there are at least 64 possible answers, and we have no way of knowing
which is correct until John responds!
BTW, googling "Punch Invalid" turns up a much longer list:
http://www.physics.ohio-state.edu/~bcd/humor/instruction.set.html
I do wonder if "Punch Invalid" had originally been a real error
message on a mainframe somewhere (relating to a broken or missing
cardpunch), and made it into these lists due to the double entendre. :)
-Arthur
Richard Harter
My favorite real command was the rewind card reader command, which was
legal on the CDC 3400.
John Bode
Arthur J. O'Dwyer wrote:
> On Mon, 30 Oct 2006, Jordan Abel wrote:
> > 2006-10-30 <1162233459.2...@e64g2000cwd.googlegroups.com>,
> > John Bode wrote:
> >>
> >> fermineutron wrote:
> >>> Theoretically it seems possible to develop a subset of assembly
> >>> languages which are used by motern CPUs and include in a C standard a C
> >>> library which would allow user to use the assembly subset. Since it is
> >>> a limited subset and its sintax is goverened by C it should not present
> >>> portability challenges with possible exception of older systems. any
> >>> thoughts about this?
> >>
> >> Here's a proposed set:
> >
> > (snip)
> >
> > No HCF?
> >
> > Where'd you get these anyway?
>
> At first I thought that was a stupid question... but googling "tangle
> tape and crash" turned up 64 hits. So, your question wasn't stupid;
> there are at least 64 possible answers, and we have no way of knowing
> which is correct until John responds!
>
I googled on "Inhale Dust and Die" which led me to
http://www.cs.inf.ethz.ch/37-023/fun/UAB.pdf
I first saw that list back in '87 or '88, and I think a couple of
entries are missing (eXecute OPerator and eXecute OPerator Immediate
(20,000 volts to the console). I remembered IDD and figured I'd get
the list on the first hit. However, the first page came back with
stories of kids who inhaled dust and died as a result.
Google's a scary place sometimes.
> BTW, googling "Punch Invalid" turns up a much longer list:
> http://www.physics.ohio-state.edu/~bcd/humor/instruction.set.html
I think that's the list I remember. Of course, I'm old now, so what I
think I remember and what I really remember are often two different
things.
Gordon Burditt
>>
>> Where'd you get these anyway?
>
>At first I thought that was a stupid question... but googling "tangle
>tape and crash" turned up 64 hits. So, your question wasn't stupid;
>there are at least 64 possible answers, and we have no way of knowing
>which is correct until John responds!
>
> BTW, googling "Punch Invalid" turns up a much longer list:
>http://www.physics.ohio-state.edu/~bcd/humor/instruction.set.html
>I do wonder if "Punch Invalid" had originally been a real error
>message on a mainframe somewhere (relating to a broken or missing
>cardpunch), and made it into these lists due to the double entendre. :)
Real OS/360 card readers had this error called a "validity check".
They had to read 1 column (with positions for 12 punches) and
translate this into a byte (8 bits), unless the cards were being
read in "column binary" mode (12 bits per column), which was rarely
used. Describing this as "Punch Invalid" was reasonable, since it
read an invalid combination of punches.
Naturally, with 4096 possible codes and only 256 valid ones (the
maximum number of punches for a valid column was 6, as in 12-11-0-7-8-9),
a lot of combinations were invalid, particularly the infamous
"ventilator column" (all 12 positions punched out) often appearing
on the "ventilator card" (all 12 positions X 80 columns punched
out, which weakened the card so much it was likely to jam, in both
card readers and keypunches).
If the card reader stopped with a validity check, you retrieved the card
with the error, put it first in the hopper, and started reading again.
If it kept doing it, you took the offending deck out, handed it back
to the person submitting it, and told them to fix it.
Chris Dollin
> I first saw that list back in '87 or '88, and I think a couple of
> entries are missing (eXecute OPerator and eXecute OPerator Immediate
> (20,000 volts to the console).
Similar lists existed before 1979 (I encountered one before I started
Paid Work). Possibly my favourite pair was Switch Off (boring) and
Switch On (less boring).
--
Chris "hashed up hashing" Dollin
"Who are you? What do you want?" /Babylon 5/
Richard Bos
> "fermineutron" <free4t...@yahoo.com> wrote in message
> news:1162076742....@b28g2000cwb.googlegroups.com...
> > Theoretically it seems possible to develop a subset of assembly
> > languages which are used by motern CPUs and include in a C standard a C
> > library which would allow user to use the assembly subset. Since it is
> > a limited subset and its sintax is goverened by C it should not present
> > portability challenges with possible exception of older systems. any
> > thoughts about this?
>
> You should ignore any response Healthfield gives to your question.
>
> This problem was solved in the very first assembly language:
> http://en.wikipedia.org/wiki/Autocode
"Very first" is debatable; there were assemblers for the ENIAC. You may
or may not count these, depending on how you count.
In any case, that does not solve the OP's problem. It doesn't allow you
to use all the dirty tricks that you can use in native assembly
language, such as controlling the pipelining or addressing specific
hardware directly. OTOH, if you extend it so that you can use these
tricks, the result will ipso facto not be portable to all systems,
simply because the processor and hardware on other systems may not allow
you to pull the tricks you wanted to pull on the first system, and where
they do, may have different constraints.
> It has also been solved by many other languages, the most effectively by
> FORTH and C.
Ah. Yes. And there's the rub, isn't it? To the advocates of __asm, the
way it's been solved by C isn't effective enough. If it were, they'd use
C as it is, rather than asking for assembly language to be shoehorned
in. (Whether such advocates are correct in their desires is another
matter. IMO they're not.)
> The above functionality of C can be represented by 16 "actions" and 20
> arithmetic operations. That means that C can be written on an interpreter.
> The highly portable QEMU emulator reduces host specific CPU instructions to
> "micro-ops" for a virtual machine. Those "micro-ops" could be considered to
> be a portable assembly. Research into the FORTH language, shows that the
> _entire_ functionality of FORTH language (which is just as powerful as C)
> reduces to 13 "primitives."
Amateurs.
<http://catseye.mine.nu:8080/projects/smetana/doc/smetana.html>. Two.
<http://catseye.mine.nu:8080/projects/thue/doc/thue.txt>. Three, if you
count Production, Input and Output, but unlike Smetana, known to be
Turing-complete. And if you only care about calculation and are willing
to write and read the data straight from the chip, you can reduce this
to a single primitive.
Richard
Richard Bos
> John Bode wrote:
> >
> > fermineutron wrote:
> >
> >> Theoretically it seems possible to develop a subset of assembly
> >> languages which are used by motern CPUs and include in a C standard a C
> >> library which would allow user to use the assembly subset. Since it is
> >> a limited subset and its sintax is goverened by C it should not present
> >> portability challenges with possible exception of older systems. any
> >> thoughts about this?
> >
> > Here's a proposed set:
> No HCF?
No Sign Extend, either. I want my Sign Extend! Not to mention a Halt and
Terminate Operator instruction, although there are several which could
be used for roughly the same purpose.
> Where'd you get these anyway?
The back of a C-Flat manual, I'd guess.
Richard
Richard Bos
> sjde...@yahoo.com a écrit :
> > jacob navia wrote:
> >
> >>Assembly is quite portable between OSes, but not within
> >>different processors
> >
> > Seems like you're using an odd definition of "portable" here. On
> > common platforms assembly is not portable between different
> > compilers/assemblers on the same OS and architecture, let alone between
> > OSes. Certainly on a single architecture it's possible to write an
> > assembler that runs under many OSes, but having just one standard
> > assembly language even in one OS is _not_ the current state of the
> > world on everyday architectures--witness the x86 example I gave in the
> > message you replied to.
> >
> Since Mac OS, Windows, Linux and Solaris all run the gcc compiler
> and since that compiler has an assembler, using that assembler
> makes your code portable to any of those architectures.
Oh, right? So calling interrupt 20h will do the same thing under MS-DOS
that it does under MS-Windows? Int 13 can be used to read the disk
allocation tables under Linux? Or are you perhaps limiting yourself to a
severely restricted sub-set of that assembly code?
(Note also that you contradict yourself, since MacOS, MS Windows, and
Solaris may all sometimes use gcc, they typically run on different
processors; so according to your previous post, quoted above, assembly
would not be portable across those three, while here you claim that it
should be.)
Richard
fermineutron
have additional instructionl like
OP - Order Pizza
PSG - Port Scan Google
I also want an SFP instruction, so the the computer could Show Free
Porn. With todays grafix that should be possible.
Rod Pemberton
"Richard Heathfield" <inv...@invalid.invalid> wrote in message
> Rod Pemberton said:
>
> <snip>
> >>
> >> If he were capable of giving good advice, he would probably also be
> > capable
> >> of spelling my name correctly.
> >>
> >
> > I'm sorry that I unintentionally mispelled of your name out of a
thousand
> > or
> > so. You know that I haven't mispelled it elsewhere.
>
> You know that, and I know that, but the Google archives disagree with us
> both.
>
> > I guess it was a
> > convenient excuse for you to ignore the fact that your response was
> > totally incorrect and borders upon incompetence.
>
> I stand by the accuracy and correctness of my response.
>
You weren't qualified to respond, but you did so anyway, provided a
ludricrously false response, and expected everyone here to accept it as
truth? As an example of falseness of your response, I provided facts,
statistics, and proof, which contradicted your claims. Where's yours (just
like Bill Reid, do you have none)? I even forgot to mention a couple of the
best cases against your argument. I guess you can stand anywhere you want.
But, your attempt to claim that there is any accuracy or correctness of your
response is a blatant lie.
Rod Pemberton
Rod Pemberton
> "Rod Pemberton" <do_no...@bitfoad.cmm> writes:
> > "Keith Thompson" <ks...@mib.org> wrote in message
> > news:lnmz7fx...@nuthaus.mib.org...
> >> "Rod Pemberton" <do_no...@bitfoad.cmm> writes:
> >> > "fermineutron" <free4t...@yahoo.com> wrote in message
> >> > news:1162076742....@b28g2000cwb.googlegroups.com...
> >> >> Theoretically it seems possible to develop a subset of assembly
> >> >> languages which are used by motern CPUs and include in a C standard
a C
> >> >> library which would allow user to use the assembly subset. Since it
is
> >> >> a limited subset and its sintax is goverened by C it should not
present
> >> >> portability challenges with possible exception of older systems. any
> >> >> thoughts about this?
> >> >
> >> > You should ignore any response Healthfield gives to your question.
> >> [snip]
> >>
> >> That's really bad advice.
> >
> > How so? It appears that your response is incorrectly biased...
>
> Here's what Richard wrote:
>
> | Would that it were true - but it isn't. There is no such thing as
"assembly
> Is that what you're referring to?
>
No. You're off by one level. Please, try to follow. I told "fermineutron"
to ignore any response to the question above that he posted. Heathfield's
response was posted prior to my statement. This is Heathfield's response to
the said question:
RH> Feel free to try. Don't forget to include CPUs manufactured by Cray,
Unisys,
RH> the mainframe division of IBM, Analog, Motorola... and many many more
RH> besides. Once you see how long the list is, and how many different
assembly
RH> languages with different syntaxes are out there, you'll realise why
nobody
RH> is doing this
> > Heathfield's response was totally incorrect and borders upon
incompetence.
>
> No, he was quite correct. If you disagree, by all means say so;
> there's no need to make it personal.
>
No, he wasn't and still isn't. Reread the facts I posted to the contrary.
Rod Pemberton
.
Rod Pemberton
"Richard Bos" <r...@hoekstra-uitgeverij.nl> wrote in message
news:45470236....@news.xs4all.nl...
> "Rod Pemberton" <do_no...@bitfoad.cmm> wrote:
>
> > "fermineutron" <free4t...@yahoo.com> wrote in message
> > news:1162076742....@b28g2000cwb.googlegroups.com...
> > > Theoretically it seems possible to develop a subset of assembly
> > > languages which are used by motern CPUs and include in a C standard a
C
> > > library which would allow user to use the assembly subset. Since it is
> > > a limited subset and its sintax is goverened by C it should not
present
> > > portability challenges with possible exception of older systems. any
> > > thoughts about this?
> >
> > You should ignore any response Healthfield gives to your question.
> >
> > This problem was solved in the very first assembly language:
> > http://en.wikipedia.org/wiki/Autocode
>
> "Very first" is debatable; there were assemblers for the ENIAC. You may
> or may not count these, depending on how you count.
>
> In any case, that does not solve the OP's problem. It doesn't allow you
> to use all the dirty tricks that you can use in native assembly
> language, such as controlling the pipelining or addressing specific
> hardware directly. OTOH, if you extend it so that you can use these
> tricks, the result will ipso facto not be portable to all systems,
> simply because the processor and hardware on other systems may not allow
> you to pull the tricks you wanted to pull on the first system, and where
> they do, may have different constraints.
>
The only issue you mentioned that isn't supported by Autocode is pipelining.
Autocode even supports segmentation or multiple address spaces.
But, you're taking the issue of a "portable assembly" language and
attempting to turn it into a "comprehensive assembly" language. The two are
different. The full feature set of a CISC, and alomost VLIW, CPU such as
the x86 isn't needed to make a portable assembly language. And, the OP was
wanting a portable assembly language based on the functionality of C. I
listed that functionality. The functionality of C can be represented by 16
"actions" and 20 arithmetic operations. Even if one assumes that I'm
completely incorrect, say by 600% thereby giving C about minimum of 200
required operations, C could still be implemented as an interpreter. Those
16/20 (or 200) operations are the portable assembly he seeks.
> > It has also been solved by many other languages, the most effectively by
> > FORTH and C.
>
> Ah. Yes. And there's the rub, isn't it? To the advocates of __asm, the
> way it's been solved by C isn't effective enough.
For the OP, I believe it has been solved, because he wanted a C based
portable assembly. But, for the "advocates of __asm", it hasn't. C
captures the abilities of RISC, and most other early CPU's, but hasn't added
any additional complexity for CISC or VLIW CPU's, DSP's etc. Without __asm,
you need a kludge or extension to C to support segmentation, CPU registers,
etc. (see TR 18037: Embedded C, http://www.open-std.org/jtc1/sc22/wg14/).
> If it were, they'd use
> C as it is, rather than asking for assembly language to be shoehorned
> in. (Whether such advocates are correct in their desires is another
> matter. IMO they're not.)
>
They ask for assembly to be "shoehorned" in because extensions like TR18037
are about two decades _late_... Almost everything it adds has been in
needed and in use since the late '80's. I doubt the "original authors"
(knowing full well who they are) intended C to be a "dead" or static
language. So, now that everyone knows how to use __asm, instead of
extensions like TR18037, what is the point of extending C? (i.e., force
people to waste more time learning more C when they've already learned
assembly and it does the job?)
> > The above functionality of C can be represented by 16 "actions" and 20
> > arithmetic operations. That means that C can be written on an
interpreter.
> > The highly portable QEMU emulator reduces host specific CPU instructions
to
> > "micro-ops" for a virtual machine. Those "micro-ops" could be
considered to
> > be a portable assembly. Research into the FORTH language, shows that
the
> > _entire_ functionality of FORTH language (which is just as powerful as
C)
> > reduces to 13 "primitives."
>
> Amateurs.
>
> <http://catseye.mine.nu:8080/projects/smetana/doc/smetana.html>. Two.
> <http://catseye.mine.nu:8080/projects/thue/doc/thue.txt>. Three, if you
> count Production, Input and Output, but unlike Smetana, known to be
> Turing-complete. And if you only care about calculation and are willing
> to write and read the data straight from the chip, you can reduce this
> to a single primitive.
>
Both of those appear to be theoretical. I listed Frank Sargent's 3
instruction FORTH which is an actual working FORTH using only 3 instructions
for embedded environments. In this case, the assembly instructions and
FORTH primitives were the same.
Rod Pemberton
Rod Pemberton
You're responding to the wrong stuff. You snipped the important part of his
statement. So, let's back it up:
> Since Mac OS, Windows, Linux and Solaris all run the gcc compiler
> and since that compiler has an assembler, using that assembler
> makes your code portable to any of those architectures. That is
> why lcc-win32 uses ATT syntax and NOT Intel's syntax.
He stated, albeit less than elegantly, that he uses the gcc assembler as a
back-end to lcc-win32 because the gcc assembler supports multiple targets.
Rod Pemberton
Richard Heathfield
> "Richard Heathfield" <inv...@invalid.invalid> wrote in message
> news:OamdnWLBSf0aPtjY...@bt.com...
<snip>
>>
>> I stand by the accuracy and correctness of my response.
>>
>
> You weren't qualified to respond, but you did so anyway, provided a
> ludricrously false response, and expected everyone here to accept it as
> truth? As an example of falseness of your response, I provided facts,
> statistics, and proof, which contradicted your claims.
No, you didn't. I'm not sure what you think you were contradicting, but it
isn't anything I said.
Andreas Kochenburger
Because asm is not C, thus not part of the C language specification.
Linking is also not part of the standard. Since you can create object
files with external assemblers and link them with your C code, there
is no need for over-standardization.
Andreas
-------
1 + 1 = 3, for large values of 1.
jacob navia
No, I do not use any gcc software, but lcc-win32's assembler
uses the same SYNTAX as gcc's assembler.
And for the poster that complains about assembly language not being
portable, what is portable is the same processor, not the interrupts,
not the calls to some specific procedure. Portable assembly is,
for instance, a package to calculate with floats 350 bits
wide, or another package to implement bignums. Those packages do not
use any OS dependent features, and even if written entirely
in assembly language they are portable to any OS that supports the
same processor.
jacob
jacob navia
What is portable is the same processor opcodes, not the interrupts,
not the calls to some specific procedure. Portable assembly is,
for instance, a package to calculate with floats 350 bits
wide, or another package to implement bignums. Those packages do not
use any OS dependent features, and even if written entirely
in assembly language they are portable to any OS that supports the
same processor.
The inputs are standard, the outputs are well defined, they are portable
across any processor that implements the x86 instruction set.
Obviously interrupts (supervisor calls, system() etc)are not portable.
This is the same as C. C is portable but
system("ls");
will work in Unix and not in windows.
Bob Martin
Your last sentence sums up the flaw in your argument. The Intel processors
are not the be-all and end-all of computing. More code is written for non-Intel
processors than for Intel. Code that is "portable" to less than 50% of applications
does not deserve the label.
You should widen your horizons. Have you done any mainframe programming?
CBFalconer
>
... snip ...
>
> This is the same as C. C is portable but
> system("ls");
> will work in Unix and not in windows.
Oh? It works fine here under W98.
[1] c:\c\factsize>ls
a.exe a.out factsize.bak factsize.c factsize.exe factsize.o
[1] c:\c\factsize>lsl
total 260
-rwxr-xr-x 1 dosuser 86866 Sun Oct 08 23:33:16 2006 a.exe
-rwxr-xr-x 1 dosuser 84818 Sun Oct 08 23:33:14 2006 a.out
-rw-r--r-- 1 dosuser 839 Sun Oct 08 23:33:06 2006
factsize.bak
-rw-r--r-- 1 dosuser 839 Sun Oct 08 23:34:00 2006
factsize.c
-rwxr-xr-x 1 dosuser 86735 Sat Oct 07 12:17:42 2006
factsize.exe
-rw-r--r-- 1 dosuser 4310 Sun Oct 08 23:26:42 2006
factsize.o
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Flash Gordon
It's worse that you pain. Not all x86 systems are programmed using the
same assembler syntax (as Jacob admitted), so at the source level it is
not portable to all x86 systems. Not all x86 systems use the same object
format, so it's not portable to all x86 systems at the object level.
Then we get on to the mess of calling conventions, since not everything
for the x86 uses the same calling conventions. So it is far from
portable to all x86 systems without even starting to wonder about which
processors in the series it supports, since I know there are still 8086
and 80186 systems out there in real use, although I'm no longer in a
position to know if any development is being done for them.
--
Flash Gordon
Andrew Poelstra
> jacob navia wrote:
> >
> ... snip ...
> >
> > This is the same as C. C is portable but
> > system("ls");
> > will work in Unix and not in windows.
>
> Oh? It works fine here under W98.
Not over here under Media Center or Blister RC2.
The chances of someone installing UNIX tools on their system seems
lower than that of them installing cgywin or just plain Linux. And
both of those chances are still pretty low right now.
--
Andrew Poelstra <http://www.wpsoftware.net>
For email, use 'apoelstra' at the above site.
"You're only smart on the outside." -anon.
james of tucson
> The chances of someone installing UNIX tools on their system seems
> lower than that of them installing cgywin or just plain Linux. And
> both of those chances are still pretty low right now.
Chances? Anybody that wants to is free to run cygwin or linux. That's
the whole point. I don't see where there is any chance involved.
Jordan Abel
Chance can be used as another term for probability. The probability that
any given user has done so is low.
Walter Roberson
jacob navia <ja...@jacob.remcomp.fr> wrote:
>And for the poster that complains about assembly language not being
>portable, what is portable is the same processor, not the interrupts,
>not the calls to some specific procedure. Portable assembly is,
>for instance, a package to calculate with floats 350 bits
>wide, or another package to implement bignums. Those packages do not
>use any OS dependent features, and even if written entirely
>in assembly language they are portable to any OS that supports the
>same processor.
I'm almost sure we went over this before??
You are assuming that just because two systems support the same
processor, that they support the same assembly language. That is
manifestly false. There are an amazing number of different and
incompatible assemblers for systems in the Motorola 68000 line,
and similarily for several of the MIPS processors (both have been
fairly popular in the embedded processor market.)
Let me give a concrete example: SGI's IRIX, the assembler changed
greatly (different software company, different processor status
word setup, different calling conventions, different object file
format, different symbol table format) between IRIX 5.3 and IRIX
6.0, and yet both assemblers supported the MIPS R3000 CPU.
You are also assuming that any two systems with the same processor
will use the processor the same way. Bad assumption. It is common
for processors to be designed to support a number of different
memory models (especially different cache sizes), with the
actual cache size to be used being retrieved via pins at power-up
time. There are CPUs that are designed to be able emulate
several different brands of CPUs, possibly even switching emulations
for different programs. And there are entire CPU families such as
MIPS that can be used in either "big endian" or "little endian" mode,
with the mode hardwireable (if so desired) or changable via a
processor control bit (for those systems that so desire.) In each
of these cases, even if the *same* assembler was used for the same
processor, the program could end up incompatible because of very
small differences in the hardwiring of the CPU setup.
--
Programming is what happens while you're busy making other plans.
CBFalconer
> On Thu, 2006-11-02 at 09:08 -0500, CBFalconer wrote:
>> jacob navia wrote:
>>>
>> ... snip ...
>>>
>>> This is the same as C. C is portable but
>>> system("ls");
>>> will work in Unix and not in windows.
>>
>> Oh? It works fine here under W98.
>
> Not over here under Media Center or Blister RC2.
>
> The chances of someone installing UNIX tools on their system seems
> lower than that of them installing cgywin or just plain Linux. And
> both of those chances are still pretty low right now.
Not UNIX tools, just DJGPP. Simple. Most unixy things just work.
Keith Thompson
[...]
> And for the poster that complains about assembly language not being
> portable, what is portable is the same processor, not the interrupts,
> not the calls to some specific procedure. Portable assembly is,
> for instance, a package to calculate with floats 350 bits
> wide, or another package to implement bignums. Those packages do not
> use any OS dependent features, and even if written entirely
> in assembly language they are portable to any OS that supports the
> same processor.
Sheesh!
Portability to a single processor, or to a single processor family,
*is not portability*.
If you want to do stuff that will only work on an x86, feel free to do
so, but please find someplace else to talk about it. We discuss
standard C here.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Andrew Poelstra
The chances that they know they can, then. Or the chances that
they're willing, or allowed to. (Perhaps they're at school and
are using public computers on which they have no administrative
permissions).
People in general haven't figured out that all the world ain't
a Wintel.
james of tucson
> The chances that they know they can, then. Or the chances that
> they're willing, or allowed to.
Specify that it's required, and then it's their problem.
Bill Reid
Rod Pemberton <do_no...@bitfoad.cmm> wrote in message
news:ei3f3p$msb$1...@ltw.loris.tv...
>
This is the most brilliant part of this latest troll:
>
> your response was totally
> incorrect and borders upon incompetence.
>
> find anything even remotely close in hundreds, if not thousands, of
> programming books.
>
Behold the beauty of this insane troll logic. It is a glittering diamond of
unassailable non-reason that can be used for any topic. A few examples:
"The Earth isn't round, or flat, but kind of a twisted toroidal donut
shape with a 7000 mile hole in the center. You won't find anything
even remotely like that in hundreds, even thousands of geology
books; therefore, you are an incompetent geologist if you don't
know this!"
"The United States was formed when it fought the Reactionary
War to free itself from China in 1927. You won't find anything
even remotely like that in hundreds, even thousands of American
history books; therefore, you are an incompetent historian if you
don't know this!"
Architecture, art, astronomy, right on down to zoology, the entire
sum of human knowledge and all constructive endeavors, can be brought
to their collective knees with a single mighty blow from this lunatic
tactic of epic genius. Bravo! Troll on, "Rod"!
---
William Ernest Reid
Richard Heathfield
> On Thu, 2006-11-02 at 09:01 -0700, james of tucson wrote:
>> Andrew Poelstra wrote:
>>
>> > The chances of someone installing UNIX tools on their system seems
>> > lower than that of them installing cgywin or just plain Linux. And
>> > both of those chances are still pretty low right now.
>>
>> Chances? Anybody that wants to is free to run cygwin or linux. That's
>> the whole point. I don't see where there is any chance involved.
>
> The chances that they know they can, then. Or the chances that
> they're willing, or allowed to. (Perhaps they're at school and
> are using public computers on which they have no administrative
> permissions).
Or perhaps they're working in a company which likes to keep careful control
over what software is installed on its computers, for legal and safety
reasons. Almost all the companies I've worked for in the UK are like this.
> People in general haven't figured out that all the world ain't
> a Wintel.
That too. Try running cygwin on a 4341. :-)
james of tucson
> Andrew Poelstra said:
>
>> On Thu, 2006-11-02 at 09:01 -0700, james of tucson wrote:
>>> Andrew Poelstra wrote:
>>>
>>>> The chances of someone installing UNIX tools on their system seems
>>>> lower than that of them installing cgywin or just plain Linux. And
>>>> both of those chances are still pretty low right now.
>>> Chances? Anybody that wants to is free to run cygwin or linux. That's
>>> the whole point. I don't see where there is any chance involved.
>> The chances that they know they can, then. Or the chances that
>> they're willing, or allowed to. (Perhaps they're at school and
>> are using public computers on which they have no administrative
>> permissions).
>
> Or perhaps they're working in a company which likes to keep careful control
> over what software is installed on its computers, for legal and safety
> reasons. Almost all the companies I've worked for in the UK are like this.
>
>> People in general haven't figured out that all the world ain't
>> a Wintel.
>
> That too. Try running cygwin on a 4341. :-)
Well, in that case, *definitely* don't deliver something to them that
requires Cygwin.
I still don't see what the problem is.
Bob Martin
>
>That too. Try running cygwin on a 4341. :-)
>
The 4341 was a great machine (I was a test engineer on the build line).
Richard Heathfield
So I can blame you, then? :-)
Walter Banks
mnemonic in Byte article about decoding the undocumented
Motorola 6800 instructions. The HCF (Halt Catch Fire) opcode $DD
or $D9. HFC locked up the processor and cycled the address bus
The author of that article was Gerry Wheeler.
Gerry Wheeler, 54, died October 15, 2006, advanced non-Hodgkins
lymphoma cancer. Gerry made significant contributions to the technology
of the embedded systems world and was a key part of the development
of many household name products.
Programmer, Ham KG4NBB, author, father, husband, active commuity
participant Gerry will be missed by all.
w..
Andrew Poelstra
> Andrew Poelstra said:
> > a Wintel.
>
> That too. Try running cygwin on a 4341. :-)
>
The closest I got was running Linux on a Linksys WRT54GL router and an
iPod. There was also that foray into NES assembler, but that ended with
a lack of EEPROM hardware.
Chris Thomasson
news:ei0kp...@news3.newsguy.com...
> In article <vcCdnYd3bKeeUd7Y...@comcast.com>
> Eric Sosman <eso...@acm-dot-org.invalid> wrote:
>> A more usual motivation is to make use of special machine
>>instructions the compiler would not generate on its own.
[...]
> I agree with all of this; however, in some (sometimes significant)
> cases (e.g., the actual implementation for a mutex), you may want
> to have an inline expansion of the underlying atomic operation,
> typically via a macro. For instance, if you have a mutex construct
> that -- at least in the uncontested case -- is just a (possibly
> locked) compare-and-swap, you may want the x86-specific version
> of:
>
[...]
> The tricky part lies not only in arranging for the assembly equivalent
> to be inserted inline, but in *also* informing the compiler that
> it must not move certain memory operations across the "special"
> instruction(s).
[...]
Indeed!
http://groups.google.com/group/comp.arch/msg/c6f096adecdd0369
(refer to the last couple of paragraphs...)
;^)
FWIW, in order to correctly implement this kind of stuff, you simply have to
define exactly how you are going to address two fundamental problems:
1: Compiler Reordering
2: Hardware Reordering
--1-- The compiler reordering issue can "usually" be resolved by strictly
adhering to a design policy which declares that all functions that contain
"critical-sequences" of instructions that have to be executed in precise
order must be externally assembled. This is due to the current fact that the
C Standard doesn't think threads even exist. However, an Assembler is a
different story IMO simply because it gives you full access to the
architecture your targeting and it will not reorder any your assembly
statements; what you see is exactly what you get.
IMO, a typical C compiler is usually forced to treat any call into an
"unknown and external" function in a fairly "pessimistic" manor", which in
turn basically renders its behavior to something that is analogous to a
so-called "compiler barrier". However, please note that some compilers are
exploring link-time optimizations which can, and probably will, turn out to
be an annoying and potentially hazardous scenario to any function that
simply expects every instruction its made up of will be executed exactly
as-is. Period. Unfortunately, this definitely includes basically all
externally assembled functions that a lock-free library may export by
default.
;^(...
However, all is not list because it does seem like the compilers that do
support link-time optimizations' also provide some method for turning it
on/off. Usually, they allow you to decorate your "critical-function"
declarations with something that guarantees that they will never be
subjected to this particular type of optimization.
--2-- Hardware reordering is easily solved by placing the proper the memory
barrier instructions in the correct places throughout your externally
assembled lock-free library. The assembler won't reorder any instructions,
therefore, this is the only real solution wrt actually implementing this
kind of stuff.
Therefore, it is my theses that a safe method for ensuring that calls into
"critical-function" will not be tampered with must include a combination of
solutions that directly resolve all of the reordering issues that are
attributed to both the hardware your targeting, and the C compiler your
using...
Any thoughts?
[...]
> The compiler may think the second version is superior (because it
> uses less CPU time overall, e.g., due to reduced register pressure
> or because it schedules better), but in fact, it is not. :-)
;^)
Markus....@web.de
> adhering to a design policy which declares that all functions that contain
> "critical-sequences" of instructions that have to be executed in precise
> order must be externally assembled. This is due to the current fact that the
> C Standard doesn't think threads even exist. However, an Assembler is a
> different story IMO simply because it gives you full access to the
> architecture your targeting and it will not reorder any your assembly
> statements; what you see is exactly what you get.
I imagine that optimizing assembler implementations might exist that
break your expectation.
http://en.wikipedia.org/wiki/Assembly_language
Which pragmas or flags would you like to present to those specific
compiler tools to keep the specified instruction sequence until it will
be put into an executable file by an also optimizing linker?
I guess that such tools do not provide the guarantees that are required
for program correctness so far.
> IMO, a typical C compiler is usually forced to treat any call into an
> "unknown and external" function in a fairly "pessimistic" manor", which in
> turn basically renders its behavior to something that is analogous to a
> so-called "compiler barrier". However, please note that some compilers are
> exploring link-time optimizations which can, and probably will, turn out to
> be an annoying and potentially hazardous scenario to any function that
> simply expects every instruction its made up of will be executed exactly
> as-is. Period. Unfortunately, this definitely includes basically all
> externally assembled functions that a lock-free library may export by
> default.
I assume that the compiler barrier can be unsafe and fragile.
Portability will only be limited to some system environments.
There are so many preconditions to consider.
Regards,
Markus
Chris Thomasson
news:1163074967.6...@f16g2000cwb.googlegroups.com...
>> --1-- The compiler reordering issue can "usually" be resolved by
>> strictly
>> adhering to a design policy which declares that all functions that
>> contain
>> "critical-sequences" of instructions that have to be executed in precise
>> order must be externally assembled. This is due to the current fact that
>> the
>> C Standard doesn't think threads even exist. However, an Assembler is a
>> different story IMO simply because it gives you full access to the
>> architecture your targeting and it will not reorder any your assembly
>> statements; what you see is exactly what you get.
>
> I imagine that optimizing assembler implementations might exist that
> break your expectation.
> http://en.wikipedia.org/wiki/Assembly_language
[...]
Here is my response:
http://groups.google.com/group/comp.programming.threads/msg/b09fe7e6a5b23de0
This is more topic in c.p.pt anyway: Optimizing assembler doesn't exist;
suspiciously sounds like C compiler anyway...
Dave Thompson
wrote:
<snip>
> By the way, returning to the minimal list of cpu instructions, i thing
> that thre true bare bone will have 2 instructiions, Move and Add. Move
> can be used to read and write, whie add can be used to to addition,
> subtraction, multiplication and division. Shift instructions would
> speed it up, but are redundant. So if C is to be truly compatible
> whith anything and everything, should not it limit the compiler output
> to these 2 instructions. Obviously its an overkill, but gets my point
> across.
Actually that's neither necessary nor sufficient.
Add by itself cannot build negate, subtract, and divide, but subtract
can build add (and multiply) and compare.
You need some kind of transfer of control; you can use move (or add)
for this if (and only if) you make the PC addressable as a register
(e.g. PDP-11) or put it in memory (I think some early machines did
this); or you can have explicit successors (as I know some did). And
you need some kind of conditional operation. If by move vs add you
mean the RISC-style division between memory reference instructions and
in-CPU-only computation ones, yes you need both; but if you have a
common but general format you can use ADD-zero for move. In fact a
common and practical RISC technique is not to waste an ALU code for
move rega to regb, just have a general three-address format and a zero
operand and OR rega with zero to regb or ADD rega plus zero to regb.
But those functions needn't be in separate instructions. The "one
instruction set computer" architecture -- there's a website somewhere
I've forgotten -- is something like "decrement and jump if zero". Then
you don't need an opcode field at all, your instruction (format)
consists entirely of address fields. But it's about as hugely and
gloriously inefficient as a (conventional) universal Turing machine,
so no consumer would ever buy one to use for anything, which rather
limits the market for programs written on it.
And that (kind of limitation) isn't what we C folks want.
- David.Thompson1 at worldnet.att.net