|C compiler for DLX email@example.com (Roman T. Grizulyak) (1998-09-24)|
|Re: C compiler for DLX firstname.lastname@example.org (1998-09-26)|
|Re: C compiler for DLX email@example.com (1998-09-29)|
|Re: C compiler for DLX firstname.lastname@example.org (1998-10-01)|
|Re: C compiler for DLX email@example.com (Peter Bergner) (1998-10-07)|
|From:||Peter Bergner <firstname.lastname@example.org>|
|Date:||7 Oct 1998 23:01:47 -0400|
Robert Rayhawk wrote:
: There is plenty of DLX material at
: for example, from here you can find a gccdlx made with GNU C 2.7.x
: at the University of Minnesota
We've been having some problems with our web server lately,
which hopefully is fixed now. If anyone failed to load this
page, please try again.
: It may well be the best to look to for use of the most recent GCC.
: This good work by Dr. Aaron Sawdey, and others, at UMN is thorough.
: IMPORTANTLY, they also note a GNU C library version 1.09 compiled for
: DLX. That probably creates an entirely different foundation for DLX
: code generation and simulation. Clearly program linkage would be an
: issue for researchers. Examiniation of such an area could not be
: complete without a review of the putative machine behavior for the
: standard lib function invocation.
: The web page indicates they have regenned even stdio. (Iterested
: parties should look for the libs themselves on this site, regenning
: yourself will take considerable time).
: This solution permits moving a large class of existing programs into a
: DLX research environment. Researchers would not have to code with kid
: gloves when using this environment.
I should note that the assembly code generated by gcc-dlx will
*not* run on the "dlxsim" simulator that was distributed with H&P.
The main reason is we changed the stack pointer register as well
as adding a few extra instructions and assembler directives.
This isn't a real loss since dlxsim isn't really usable for anything
other than small (ie, short execution run time) benchmarks.
These assembly files *will* run on a simulator we built from the
ground up here at Minnesota called "fast-dlx". Fast stands for
Flexible Architecture Simulator Tool. This can be downloaded from:
We've compiled and run the simulator on SunOS 4.x, IRIX and Linux.
Some of the benefits of fast-dlx over dlxsim are:
* Faster execution time compared to dlxsim. Depending on the host
machine, we've experienced anywhere between 5K-10K instructions
executed per second with dlxsim. Using fast-dlx, this ranges
from 150K-5M instructions executed per second.
The large variance with fast-dlx is due to our simulation
methodology. Fast-dlx consists of two simulators. An ISA
simulator which executes our program and a separate timing
simulator. The ISA simulator executes our program and is
responsible for computing our "answer" as well as keeping
track of instruction counts. Is also can conditionally
generate an instruction trace file which can be fed to
the timing simulator. The nice benefit of this is that
you don't have to pay the penalty of generating cycle time
information if you don't want it. With dlxsim, you get
cycle time information whether you want it or not.
We've also strived to make the common case fast within
the simulator. In dlxsim, they have lots of code that
says: Is this instruction address an address the user
has placed a break point at?, Did they overwrite r0?,
Is there a full moon? We've removed all of these types
of checks by adding an extra instruction opcode that is
only available for use by the simulator. For example,
if we want to set a break point in the simulator, instead
of checking each instruction address we encounter, we
replace the instruction at the address we want the break
point with our new instruction; the new instruction
contains an index into a table which holds the original
instruction plus some other information. At run time,
if we end up trying to execute that instruction, we'll
branch to special case code within the simulator which
will bring us back to our debugger prompt. We use these
new instructions for handling break points, writes to r0
(which is hard coded to zero in DLX), instruction count
statistics (we keep block counters and compute instruction
counts from them after simulation is done),...
* We support the simulation of muliproccessor programs via:
fork(), join(), barrier(bar_num,num_bars) and shared memory.
An interesting point with respect to our execution of fork()
versus some other simulators is that when we encounter a
fork() call, we actually fork off another simulator process.
With our fixed up version of dlxsim, simulating explicitly
parallel programs generally leads to a simulation time slowdown
equal to the number of processes we're trying to simulate.
With fast-dlx, we've actually seen near linear decreases in
simulation time (we were running on a MP machine).
* As Robert pointed out, we have the GNU C library prebuilt.
This grew out of our frustration with the way that dlxsim
executed such functions as printf, fprintf, fopen, fclose, ...
The dlxsim solution was to create a "printf" trap instruction
which would be caught by the simulator. The simulator would
then perform the printf by decoding the format string and...
Ugh, you get the point. Anyway, you needed one of these hacks
for each library function you wanted. We decided the easiest
solution (in the long run!) was to compile up the GNU C library
and only support the lowest level library calls such as open,
close, read, write, isatty, access,... This made porting new
applications extremely easy.
An interesting side effect occurred while we were using the new
GNU C library. One of our code monkeys... err, ... I mean
undergraduate programmers found that the instruction counts
for several programs were changing for no apparent reason.
We finally tracked it down to the simulated GNU C library
was detecting when he was redirecting stdout and it switched
to block buffering which made us execute different code in
the printf library function!
: Clearly program linkage would be an issue for researchers.
Fast-dlx comes with an integrated assembler/linker/loader.
Anyone interested can contact us at email@example.com
[aka Aaron Sawdey, who's currently working at Cray now] and
firstname.lastname@example.org [aka me, I'm at IBM]. The source
is available, so everyone is welcome to hack it to their hearts
content. I will note, that we and others have had difficulty
getting the timing simulator to compile/run on Solaris!?!?
The problem has to do with the changes made to semaphore
usage on Solaris. I'll also note that Aaron and I have full
time jobs, so I can't guarantee we'll be able to spend much
time debugging problems that you encounter. Speaking only for
myself, I'll at least try helping.
I'll also note we have a fast-mips version which can read
ELF binaries directly. This is essentially the same simulator,
except that it is targeted to execute MIPS IV binaries.
It has it's own web page:
Peter Bergner | Peter Bergner
SLIC Optimizing Translator Development | Dept. of Electrical Engineering
IBM Rochester, MN | University of Minnesota
email@example.com | firstname.lastname@example.org
Return to the
Search the comp.compilers archives again.