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

[Giovanni Mascellani]

Hi,

Il 27/01/19 01:43, Michael Matz ha scritto:
> 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).

That is very interesting, thanks! I had in the meantime reworked some of
your patches, but some others will be very helpful. Also, some of your
changes look better than mine!

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

For my project I might be in a slightly easier situation: I already have
tcc running at ring 0 in protected mode (without pagination), and what I
want to do is to compile and load Linux directly (using tcc_relocate()).
So I do not have to mess around with 16 bit code and linker scripts
tricks, and possibly even with .incbin, because I do not have to
generate a bzImage. Of course I will need to understand Linux 32 bits
boot protocol and fill appropriately boot_params when jumping in Linux,
but that still seems to be easier than generate the whole bzImage and
perform the 16 bits boot protocol.

With these assumptions, it seems that the big missing thing in tcc is
.macro, and that's why I directed my attention on it at once. Also
because, on the other hand, using gcc is a compromise I cannot afford: I
wish I was already able to build gcc at that level of bootstrap...

I already managed to boot a not-too-patched version of iPXE compiled
with tcc in the same way. Again, the 16 bits part of iPXE is completely
crippled because tcc does not support 16 bits code. This of course means
that iPXE isn't actually able to do PXE or chainboot most image types,
but I don't care, because the thing I wanted from iPXE are its network
drivers, which work just nice purely in protected mode.

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

I guess my idea was to error out when preproc and gas defined two macros
with the same name... However, it seems that all accesses to table_ident
happen consistently via define_push, define_find and similar calls. So
it should be not too difficult to do chaining and fix those while
keeping the abstraction that processor and gas macros do not mix.

I will try, and see what I can do.

As usual, thanks and all the best, Giovanni.
-- 
Giovanni Mascellani <address@hidden>
Postdoc researcher - Université Libre de Bruxelles

signature.asc
Description: OpenPGP digital signature