Re: [Tinycc-devel] Implementing .macro gas syntax

[Michael Matz]

Hi,

On Sat, 26 Jan 2019, Giovanni Mascellani wrote:

> as part of my bootstrapping project that I have already mentioned a few 
> emails ago, I would like to be able to compile Linux with tcc, trying to 
> patch Linux as little as possible.

Btw, I still owe you an answer.  I've finally pushed my somewhat changed 
tcc-compatible linux 4.6 kernel to github:

  https://github.com/susematz/linux

branch tcc46.

See README.tcc therein for hints.  Should work out-of-box as is within 
qemu on x86-64 with the provided configs and initrd.  (Using the faster 
multi-boot hacks with qemu might require changes in qemu itself depending 
on the used version).

> Currently Linux uses the .macro syntax for the gas assembler, that I 
> would therefore like to implement in tcc.

16bit code gen, and certain other assembler constructs are still missing 
as well (e.g. the easier .incbin), but yes, .macro is a large part of 
what's still missing.

> migrated there. Is this correct? In particular, I suppose that all new
> state should go into TCCState, not into other globals.

If at all possible without going through hoops, yes.

> 2. C preprocessor macros are kept in the table_ident global array and
> manipulated with define_push and similar functions. Each of them has a
> type that can be MACRO_OBJ or MACRO_FUNC. I am undecided whether gas
> macros should be implemented as an additional macro type (e.g.,
> MACRO_GAS) and kept in the same array, or a new array should be created
> for them. The pro in the first case is that helper functions (like
> define_push and similar) are already there; however that would mean that
> the C preprocessor code must be modified so that it does not get
> confused by the appearance of a third macro type. What do you think
> about that?

Interesting idea.  There's a small complication: the assembler source 
might be preprocessed itself, so there might be both a preproc macro named 
foo, as well as an assembler macro named foo.  Requires chaining and 
associate changes in the preprocessor to ignore the new type, as you say, 
which might slow it down a tiny bit.  I'd say, implement that idea and see 
how it looks like in the end, it's especially worth it if you really can 
reuse some of the existing routines.

One other problem might be the handling of backspace to refer to macro 
args within macro bodies, which the tokenizer might act up on.  Haven't 
tried yet (supporting .macro was on my TODO somewhere down :) ).


Ciao,
Michael.