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.
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel