[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: TK
Subject: [Tinycc-devel] RE: [C67] c67_asm()
Date: Thu, 13 Mar 2003 19:30:19 -0800


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.



> -----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
> for handling stand-alone assembly?
> tcc uses a neat trick, in that all identifiers or keywords relevant to
> 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
> One of the startup functions split this string into separate keywords
> define them in the first-level symbol table together with their enums.
> There is a first-level symbol table that handles the translation from
> string to a token number (and vice versa) and a second-level symbol
> that contains the actual current definition of the symbols in each of
> 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
> about the textual values of those tokens (except for the lexer).
> The i386 assembler uses that to great advantage... for example, it can
> switch() for the mnemonics.  The mnemonics are also ordered in such a
> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]