Re: assembly in future C standard


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.

.

Relevant Pages

  • Re: assembly in future C standard
    ... should the compiler author implement method 1 ... Some compilers will give an option to which set of cpu instruction ... standard comity is faced with a disision of to what extent, in time, ...
    (comp.lang.c)
  • Re: [PATCH 02/22 -v7] Add basic support for gcc profiler instrumentation
    ... let's start with the compiler. ... generates an expensive cache miss. ... Now consider the following sequence of events on a superscalar CPU: ... One special part of this is that the ops structure is never to be freed ...
    (Linux-Kernel)
  • Re: code optimization- Removing if .. else conditions in for loops
    ... >>> I am still not clear why would the compiler generate a branch condition ... If the CPU provides an instruction that compares two ... the C standard is happy. ...
    (comp.lang.c)
  • Re: another way to shoot yourself in the foot?
    ... interpreters are allowed) it is at least a close enough approximation ... when the standard talks about the kinds that a processor ... that does not mean the kinds that the CPU natively supports. ... The compiler is free to support extra kinds in software, ...
    (comp.lang.fortran)
  • Re: [PATCH 02/22 -v7] Add basic support for gcc profiler instrumentation
    ... let's start with the compiler. ... generates an expensive cache miss. ... Now consider the following sequence of events on a superscalar CPU: ... One special part of this is that the ops structure is never to be freed ...
    (Linux-Kernel)