Re: C compiler for DLX

Robert Rayhawk wrote:


: There is plenty of DLX material at
:
: http://www-mount.ee.umn.edu/mcerg/gcc-dlx.html
:
: 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.
[snip]
: 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:


    http://www-mount.ee.umn.edu/mcerg/fast-dlx/


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 gcc-dlx@mountains.ee.umn.edu
[aka Aaron Sawdey, who's currently working at Cray now] and
fast-dlx@mountains.ee.umn.edu [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:


    http://www-mount.ee.umn.edu/mcerg/fast-mips/


--


Peter




------------------------------------------------------------------------------
Peter Bergner | Peter Bergner
SLIC Optimizing Translator Development | Dept. of Electrical Engineering
IBM Rochester, MN | University of Minnesota
bergner@vnet.ibm.com | bergner@lcse.umn.edu
                                                                                    | www-mount.ee.umn.edu/~bergner

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