[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 |
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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Tinycc-devel] RE: [C67] c67_asm(),
TK <=