|Looking for redistributable C or C++ compiler to make MS-Win DLL firstname.lastname@example.org (1994-12-20)|
|Re: Looking for redistributable C or C++ compiler to make MS-Win DLL email@example.com (1995-01-04)|
|From:||firstname.lastname@example.org (Anton Ertl)|
|Organization:||Institut fuer Computersprachen, Technische Universitaet Wien|
|Date:||Wed, 4 Jan 1995 16:44:46 GMT|
email@example.com (Niels Ull Jacobsen) writes:
|> We are looking for a compiler, which can generate DLL code for
|> MS Windows and which can use a numeric coprocessor.
|>[in order to generate code on the fly for numerical simulations]
I would suggest using a sequentialized interpreted code instead of a
syntax tree, e.g., a stack machine. Since you want to evaluate
floating point expressions, the interpretation overhead will be low on
many processors, since the interpretation can be performed in parallel
with the floating point computation. In other words, the
interpretation overhead can be partly (and sometimes completely)
hidden in the floating point latencies.
You just have to make sure that the result of a floating point
operation is not used in the same virtual machine instruction. I.e.,
the result should be kept in a C local variable (for a stack machine
this means you have to keep the top of stack in a local variable) and
a C compiler with decent register allocation should be used, so the
result is not stored into memory (the store would expose the latency
of the FP operation).
Let's look at some numbers:
switch threading overhead ~10 12
direct threading overhead 7 3
FP double add reg to reg 8-20 2
FP double mul reg to reg 16 5
"Switch threading" is the typical method of interpreting virtual
machine code in C by having a switch in a loop. Direct threading is
the fastest interpretation method, but cannot be implemented in C (but
it can be implemented using GNU C's "labels as values" extension).
As you can see, on the 486 direct threaded overhead will be hidden
completely by the FP latency, and even switch threading is hidden most
of the time.
M. Anton Ertl
Return to the
Search the comp.compilers archives again.