assembly in future C standard

[fermineutron]

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? 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]

fermineutron said:

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]

On Sat, 2006-10-28 at 09:01 -0700, fermineutron wrote:

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]

"fermineutron" <fr**********@yahoo.comwrites:

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--

[sjdevnull]

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.

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]

sj*******@yahoo.com wrote:

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]

fermineutron said:

>
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.

--
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)

[Eric Sosman]

fermineutron wrote:

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.

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
es*****@acm-dot-org.invalid

[Chris Torek]

In article <vc******************************@comcast.com>
Eric Sosman <es*****@acm-dot-org.invalidwrote:

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) [phone]
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]

>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. 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.

>I have bumped into compilers that support and others that ignore __asm
statement so obviously it is still not a part of C standard.

[Peter Nilsson]

Gordon Burditt wrote:

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]

Peter Nilsson <ai***@acay.com.auwrote:

(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]

"Peter Nilsson" <ai***@acay.com.auwrites:
[...]

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]

fermineutron said:

>
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.

--
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)

[sjdevnull]

jacob navia wrote:

sj*******@yahoo.com wrote:

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

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" <fr**********@yahoo.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.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]

"Rod Pemberton" <do*********@bitfoad.cmmwrites:

"fermineutron" <fr**********@yahoo.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.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.

--
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.

[Kenny McCormack]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>"Rod Pemberton" <do*********@bitfoad.cmmwrites:

>"fermineutron" <fr**********@yahoo.comwrote in message
news:11*********************@b28g2000cwb.googlegr oups.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]

Keith Thompson said:

"Rod Pemberton" <do*********@bitfoad.cmmwrites:

>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.

--
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)

[CBFalconer]

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.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Kenny McCormack]

In article <X5******************************@bt.com>,
Richard Heathfield <in*****@invalid.invalidwrote:

>Keith Thompson said:

>"Rod Pemberton" <do*********@bitfoad.cmmwrites:

>>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]

fermineutron wrote:

<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]

sj*******@yahoo.com a écrit :

jacob navia wrote:

>>sj*******@yahoo.com wrote:

>>>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

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. That is
why lcc-win32 uses ATT syntax and NOT Intel's syntax.

[Richard Heathfield]

Kenny McCormack said:

In article <X5******************************@bt.com>,
Richard Heathfield <in*****@invalid.invalidwrote:

>>Keith Thompson said:

>>"Rod Pemberton" <do*********@bitfoad.cmmwrites:

>>>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.

--
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)

[Default User]

Keith Thompson wrote:

"Rod Pemberton" <do*********@bitfoad.cmmwrites:

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]

fermineutron wrote:

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. [...]

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
es*****@acm-dot-org.invalid

[jacob navia]

fermineutron a écrit :

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? 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.

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]

CBFalconer <cb********@yahoo.comwrites:

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_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.

[Keith Thompson]

"fermineutron" <fr**********@yahoo.comwrites:

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.

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.

--
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.

[Ian Collins]

fermineutron wrote:

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.

I'd suggest you look for a tool chain that gives you this functionality
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" <de***********@yahoo.comwrote in message
news:4q************@individual.net...

Keith Thompson wrote:

"Rod Pemberton" <do*********@bitfoad.cmmwrites:

You should ignore any response Healthfield gives to your question.

[snip]

That's really bad advice.

Pemberton is a troll.

Brian

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.orgwrote in message
news:ln************@nuthaus.mib.org...

"Rod Pemberton" <do*********@bitfoad.cmmwrites:

"fermineutron" <fr**********@yahoo.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.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" <in*****@invalid.invalidwrote in message
news:X5******************************@bt.com...

Keith Thompson said:

"Rod Pemberton" <do*********@bitfoad.cmmwrites:

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:
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

[Bill Reid]

Default User <de***********@yahoo.comwrote in message
news:4q************@individual.net...

Keith Thompson wrote:

"Rod Pemberton" <do*********@bitfoad.cmmwrites:

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.

Yeah, but closer to being on-topic, albeit no less wacky than
on any other topic...

....and isn't "Rod Pemberton" actually a porn name?

---
William Ernest Reid

[Kenny McCormack]

In article <4q************@individual.net>,
Default User <de***********@yahoo.comwrote:

>Keith Thompson wrote:

>"Rod Pemberton" <do*********@bitfoad.cmmwrites:

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.

Yey, verily. I have rarely seen a more clearcut instance of PKB.

[Kenny McCormack]

In article <ei**********@ltw.loris.tv>,
Rod Pemberton <do*********@bitfoad.cmmwrote:

>
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

>"Rod Pemberton" <do*********@bitfoad.cmmwrites:

"fermineutron" <fr**********@yahoo.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.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.

Don't feed the netcop.

Also, bear in mind: Don't wrestle with a pig (and you know the rest).

[Keith Thompson]

"Rod Pemberton" <do*********@bitfoad.cmmwrites:

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

>"Rod Pemberton" <do*********@bitfoad.cmmwrites:

"fermineutron" <fr**********@yahoo.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.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.

--
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.

[Stephen Sprunk]

"fermineutron" <fr**********@yahoo.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.com...

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.

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.hheader 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]

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.

--
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)

[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]

2006-10-30 <11**********************@e64g2000cwd.googlegroups .com>,
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]

John Bode wrote:

Here's a proposed set:

<snip>

You forgot the 'WTF' instruction. ;)
Regards,
Bart.

[Chris Torek]

In article <45***********************@news.orange.fr>
jacob navia <ja***@jacob.remcomp.frwrote:

>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) [phone]
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]

On Mon, 30 Oct 2006, Jordan Abel wrote:

2006-10-30 <11**********************@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!

BTW, googling "Punch Invalid" turns up a much longer list:
http://www.physics.ohio-state.edu/~b...ction.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]

On Mon, 30 Oct 2006 15:22:44 -0500 (EST), "Arthur J. O'Dwyer"
<aj*******@andrew.cmu.eduwrote:

>
On Mon, 30 Oct 2006, Jordan Abel wrote:

>2006-10-30 <11**********************@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!

BTW, googling "Punch Invalid" turns up a much longer list:
http://www.physics.ohio-state.edu/~b...ction.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. :)

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 <11**********************@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/~b...ction.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.