tinycc-devel
[Top][All Lists]
Advanced

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

Re: [Tinycc-devel] TinyCC for bootstrapping (with patches)


From: Giovanni Mascellani
Subject: Re: [Tinycc-devel] TinyCC for bootstrapping (with patches)
Date: Sun, 27 Jan 2019 17:07:56 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

Hi,

Il 21/01/19 19:24, Michael Matz ha scritto:
> I would support changing tcc such that it's possible to use it as 
> external(!) optional dependency.  You could also make the constant folding 
> for float types conditional on ifdefs.  That would leave only the 
> load/stores of float types and the dreaded string-to-float conversions.

Fair compromise. I created a patch for tcc that moves all FP operations
in a dedicated file, which by default calls built-in operators. That
file can be replaced with another one to use another FP implementation,
either because FP is not available on the compiler, or because a more
correct software FP implementation is preferred while cross-compiling.

The file target_fp.h is expected to typedef three types (tfloat, tdouble
and tldouble), that are meant to contain target floats, doubles and long
doubles. It is also expect to provide, either by mean of macros or by
mean of functions, all the arithmetic and conversion operators for such
types.

I actually wrote two different patches. The first one[1] defines tfloat,
tdouble and tldouble as structs with exactly one member of the
corresponding native type. FP operations are implemented as functions.
Pros: since target types are structs (as opposed to native FP types),
for which no arithmetic operators and implicit conversions are defined
by C, the generic tcc code is guaranteed to always call target_fp.h
functions to perform operations. Cons: slower. Also, a miscompilation is
somehow introduced, and for the moment I could not understand why.

$ make tcc
$ ./tcc -B. -I./include -I. -I. -DCONFIG_TRIPLET="\"x86_64-linux-gnu\""
-DTCC_TARGET_X86_64 ./tcc.c -ldl -o tcc-tcc
$ ./tcc -B. -I./include -I. -I. -run tests/tcctest.c > /dev/null
$ ./tcc-tcc -B. -I./include -I. -I. -run tests/tcctest.c > /dev/null
tests/tcctest.c:2227: error: initializer element is not constant

The last error message is wrong, and it does not appear with the first
stage anyway (even if the first stage is compiled with ONE_SOURCE=yes).

 [1] https://gitlab.com/giomasce/tinycc/tree/softfloat2

The second patch[2] defines tfloat, tdouble and tldouble directly as
float, double and long double (without the struct), and it use macros
(and not functions) to expose operations and conversions. Pros: quicker,
probably more or less as quick as before; cons: no help from type
checking for future development of the tcc generic code. Also, it does
not seem to have the miscompilation bug and make test works properly.

 [2] https://gitlab.com/giomasce/tinycc/tree/softfloat3

BTW, in both cases not all operations exposed by target_fp.h are
actually used by tcc. If you want, I can trim the list in order to
implement and expose only the operations that are actually used.

Also, I have written a copyright line with my name if the two files I
have introduced, although I do not know if copyright assignments are
actually maintained. They seem to be rather old, on average! I can
remove my name, thus, also because my creative contribution is not that
big, after all.

In the end, I do not really understand the reasons for all the cases in
tldouble_store(), which are of course taken from the code already in
tcc. I am under the impression that some of them could be squashed
together and that less #ifs could be used without reducing the number of
supported contexts, but since there is probably something that I am not
understanding, I just copied the code over.

Please let me know what you think of my proposals and which of the two
you prefer, if any.

Thanks, Giovanni.
-- 
Giovanni Mascellani <address@hidden>
Postdoc researcher - Université Libre de Bruxelles

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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