[Tinycc-devel] RE: [C67] c67_asm()

[TK]

Peter,

No it was more to make a readable assembly listing, but didn't really
pan out.

I kind of saw how TCC was doing the token stuff, but I couldn't see a
way to apply it.

It would be great to have an assembler!  But it looked like a big job to
me.  Just to enter all the mnemonics, allowed registers, constraints...

Regarding the C67_asm() function:  As you probably noticed it is pretty
lame.  Right now for example someplace in the code generator it decided
it wants to output an ADD instruction.  It then calls a C67_ADD()
function which builds a string basically "ADD", then calls C67_asm()
which then must do many string compares just to re-figure out it needs
to do an ADD instruction. This all just evolved, but hey it works!  One
thing I considered was to make macros to generate the instructions as
you suggested, but then just put the macro right in the individual
C67_ADD() functions, and eliminate the C67_asm() function altogether.

TK

  



> -----Original Message-----
> From: Peter "Firefly" Lund [mailto:address@hidden
> Sent: Thursday, March 13, 2003 4:26 PM
> To: Tom Kerekes; Tiny C Compiler mailing list
> Subject: [C67] c67_asm()
> 
> was the idea to use c67_asm() as the basis for doing inline assembly
and
> for handling stand-alone assembly?
> 
> tcc uses a neat trick, in that all identifiers or keywords relevant to
any
> part of the compiler or assembler is defined as a token.
> 
> The file tcctok.h is included a couple of times (so is i386-asm.h) and
> contains some macro invocations with the strings for the
> keywords/identifiers and their desired symbolic name (really an int)
> inside tcc.
> 
> The way they get included defines a huge enum + a very long string
> consisting of the keywords' names with a '\0' NUL character in
between.
> One of the startup functions split this string into separate keywords
and
> define them in the first-level symbol table together with their enums.
> 
> There is a first-level symbol table that handles the translation from
a
> string to a token number (and vice versa) and a second-level symbol
table
> that contains the actual current definition of the symbols in each of
the
> namespaces that C has (including the preprocessor namespaces for the
> macros).  Each token entry in the first level symbol-table contains a
> pointer to the current second-level symbol entry for each of the name
> spaces.
> 
> (these pointers get updated as new symbols get defined -- or
undefined, in
> the case of macros -- and when nested scopes end)
> 
> This means that the rest of the compiler/assembler doesn't have to
care
> about the textual values of those tokens (except for the lexer).
> 
> The i386 assembler uses that to great advantage... for example, it can
use
> switch() for the mnemonics.  The mnemonics are also ordered in such a
way
> that their relative position in a group of similar mnemonics "just
> happens" to give the right bit patterns for their opcodes.  A similar
> thing is done with the order in which the registers are defined.
> 
> -Peter
> 
> "Of course, I'm not unbiased, but in my humble opinion, I've
>  gotten close to something that I can be really proud of."
>  -- Knuth on The Art of Computer Programming.