[Top][All Lists]

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

Re: [Tinycc-devel] asm labels

From: grischka
Subject: Re: [Tinycc-devel] asm labels
Date: Mon, 13 Sep 2010 18:04:11 +0200
User-agent: Thunderbird (Windows/20090812)

Thomas Preud'homme wrote:
I don't know why it has been invented for (you could take a look at git log on glibc to find the commit which introduced this) but in (e)glibc the way they use it bypass the type checker. That is they declare functions cosl to be cos and there is no warning if cos is used with an argument long double instead of double. As preprocessing is done before type checking there is a difference. As to why it is called asm label it's that it's suppose to change the name used in the generated asm. Macro substitute at source level whereas asm label change the name at asm level. I agree it's not what I did in the patch but it was simpler (and thus much smaller) that way. I don't know how gcc guys did it.

Sigh, what can we do when gcc decided to have it ;)

Anyway, as to tinycc, I noticed that it fails to compile with NOTALLINONE
defined.  So if this is not an "asm-feature" really I'd suggest to move
the two functions "parse_asm_str" and "asm_label_instr" elsewhere (e.g.
to libtcc.c or tccgen.c) and remove CONFIG_TCC_ASM from tccasm.c again.
The idea is that tccasm.c can stay out from compilation on platforms
without asm support.
Do you have a regression test to detect this kind of regression or you just felt this patch would break compilation with NOTALLIONE ? If you have some kind of automated test I'm very interested to use it to produce better patches.

Well, I'm using NOTALLIONE personally (of course, since I've put some
effort to make it work).  So I saw it broke and I felt that it could
break on platforms without asm support (e.g. arm) even without NOTALLIONE
because "tccasm.c" wouldn't be included at all.

Maybe we should make "NOTALLIONE" (= compilation from single objects) the
default on the native platform now.  ("Makefile" does not yet support it
it for cross compilers).

I don't think it does matter whether it is an asm feature or not. The fact is it's independant from the asm language so yes it could be moved. And more other, I don't think CONFIG_TCC_ASM_LABEL is really useful after all as this code is platform independant. I'll move asm_label_instr and parse_asm_str out of tccasm.c to put tccasm.c as it was previously. By the way, should I rename the two functions above to avoid confusion ?

Name new function as you see fit, rename existing function only for
strong reasons ;)

--- grischka

reply via email to

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