Re: C code .vs. Assembly code for Microcontrollers/DSPs ?

torbenm@diku.dk (Torben AEgidius Mogensen)
25 Mar 1996 21:49:01 -0500

          From comp.compilers

Related articles
[40 earlier articles]
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? cliffc@ami.sps.mot.com (1996-03-21)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? schwarz@mips.complang.tuwien.ac.at (1996-03-22)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? jfc@mit.edu (1996-03-22)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? chuck@aage.mit.edu (1996-03-22)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? preston@tera.com (1996-03-22)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? bobduff@world.std.com (1996-03-22)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? torbenm@diku.dk (1996-03-25)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) (1996-03-25)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? schwarz@mips.complang.tuwien.ac.at (1996-03-25)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? pardo@cs.washington.edu (1996-03-25)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? mgrice@iastate.edu (1996-03-27)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? sberg@camtronics.com (1996-03-31)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? nather@astro.as.utexas.edu (R. Edward Nather) (1996-04-02)
[3 later articles]
| List of all articles for this month |

From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.compilers,comp.dsp
Date: 25 Mar 1996 21:49:01 -0500
Organization: Department of Computer Science, U of Copenhagen
References: 96-03-006 96-03-044 96-03-078 96-03-098 96-03-144
Keywords: architecture



Robert A Duff <bobduff@world.std.com> wrote:
>The size in bits of the result
>should be determined by the size of the operands, and not their "type".


jfc@mit.edu (John Carr) writes:
>Unless you move away from a static typed language, the C model has a
>great advantage. If the result of an operation is defined to have
>infinite precision a long expression gains bits for every operator and
>the code to implement it is big and slow.


>To get the exact result for


> (x + y) * (a + b) / d


>where all variables are 32 bits requires 66 bit arithmetic. Addition
>adds 1 bit and multiplication doubles the number of bits. The quotient
>has the same number of bits as the dividend.


Robert Duff's proposal should be refined: the size in bits of the
result should be determined by the size of the operands and the type
(size) of the variable that gets the result. Hence, multiplying two
n-bit numbers and putting the result in an n-bit variable doesn't need
a 2n-bit intermediate result. Hence, the compiler should move size
information both forwards (upwards in the expression tree) and
backwards (downwards in the expression tree): The forwards information
describes the maximum number of bits required to hold the full
precision, the backwards information the number of bits required by
the destination. The compiler can choose any number of bits that is at
least the _minimum_ of these two numbers. Hence, you don't get the
explosion in the size of intermediate results that John Carr fears.


I much favour the Pascal idea of specifying exact number ranges, e.g.


var x : -13342..275249;


The compiler can choose any word size that contains this range for
implementing x. This will typically be the register size if this is
large enough, as this would give the best speed. For arrays, the
'packed' keyword tells the compiler that it should try to optimize the
array for size rather than speed, but it gives no guarantee that the
absolute minimum space is used.


Pascal does have an 'integer' type that is machine specific. I would
actually prefer omitting this altogether. If you think it is tedious
to write -32768..32767 every time you declare a variable, you are free
to declare


type integer = -32768..32767;


which gives the compiler useful information when moving to a different
platform. Note that nothing prevents the compiler from using 32-bit
words to implement this type. If you want to have a type that is
exactly 16 bits (for bitwise operations etc.), you could add an
'exact' keyword to specify that the machine should use the least
number of bits that can hold the range.


Torben Mogensen (torbenm@diku.dk)


--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.