Conference turris::languages

173.0. "How to make object code (.OBJ format!)" by MJG::GRIER (In search of a real name...) Wed Mar 16 1988 17:22

    
       This is a VAX-specific question, more than a languages in general
    question, but I'm interested in how one generates VAX object code.
    
       What kind of standard means and methods are used?  I've glanced
    through the section of the linker manual on the subject, but I found it
    distressingly uneducational.
    
       For instance, say I'm taking a compiler which generates code
    line-by-line (obviously a un*x port...) and I want to have it generate
    .OBJ.  Do I generate a .OBJ record for each instruction?  Do I generate
    a "data record" which has a string of bytes which happen to represent a
    stream of code?  How often should that stream be broken?  Does it have
    to be broken?
    
       In this instance I'm considering a C compiler I'm having to work
    with in a compiler design course I'm taking.  It's a terrible hack, but
    I've got to work with it.  It generates assembly code after each
    statement, and has to do the nasty "wait 'til the end of a procedure
    before you can allocate stack space" thing with the jumps/etc.  The way
    this compiler is organized now assumes that labels can exist in the
    output and I can blindly jump to a label.  Is this consistant with the
    VAX .OBJ format?  (note: this is strictly academic.  I'm not going to
    bother doing this.  It's only a sleazy C compiler.)
    
       On a second note, what's the normal practice for doing the code
    generation when you have the entire intermediate representation done
    beforehand?  In this case, I'm considering the DECWRL Modula-2 compiler
    which someday I'd like to hack to make .OBJ directly.  From my
    understanding, it generates an entire internal tree before doing any
    code generation.  Do I start blindly walking the tree like the
    line-by-line C compiler does, or is it more beneficial to approach the
    problem more from a whole-tree viewpoint?
    
    (I could've added this to my old "how code generation" topic which has
    gotten a lot of activity of late, but I think it deserves its own
    topic.)
    
    						-mjg
    

  A good way to get started is to take some random source file, compile it
  and do an $ ANALYZE/OBJECT on the resulting .OBJ just to see how the various
  linker commands are used together.  Also get the compiler to produce a
  machine code listing.

  In general, when your compiler is outputting a forward jump and it doesn't
  yet know the destination, it should keep track of the location of the jump
  operand, so that when it gets around to emitting the instruction that goes
  at the destination, it can generate object code that essentially tells the
  linker to go back and patch the jump with the correct PC-relative offset.
  (This is usually called generating "fix-ups".)

  A multi-pass code generator that does long/short optimization will know in
  advance the relative offsets of all forward jumps and so has enough
  information to generate smaller .OBJ files -- but even if it doesn't take
  advantage of this information and generates fix-ups anyway, the resulting
  executable images will be the same size.

  -- Bill B.

    Use an existing backend.
    
    Writing your own code generator is exactly akin to writing your
    own version of all the RTL routines - its already been done, its
    not easy, and anything one person can do is no longer technically
    anything more than "boring".
    
    It is simply not worth doing.
              
    Producing the right IL for an existing backend is just as much of
    a challenge, and the resulting code quality much better.
    
    /Bevin
    

>    Use an existing backend.
>    
>    Writing your own code generator is ... simply not worth doing.
              
     I agree.  But if you absolutely insist on doing this, the .OBJ format 
is defined in the Linker manual.  Good luck.

	Perhaps it would be possible to use the VCG (Vax Code Generator)?
Is this possible for DEC internal non-product compilers? If it is a
possiblity, and somebody wanted to use it, how might they get a hold of it
(I already have some documentation on it)?

Chuck