[Top][All Lists]

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

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

From: Michael Matz
Subject: Re: [Tinycc-devel] Implementing .macro gas syntax
Date: Sun, 27 Jan 2019 01:43:30 +0100 (CET)
User-agent: Alpine 2.21 (LSU 202 2017-01-01)


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:


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 :) ).


reply via email to

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