Still for TeX and al., the computation is done with tetras (32 bits),
and one of the variable thing to set is the C name for this tetra
(the identifier "integer" is used and is defined afterwards in the C
code).
"long" is guaranteed to be at least 32 bits by C89. So this could do,
but could be a little overkill:
1) If a compiler set on a 32 bits machine, "long" to be 64 bits? (I
haven't looked at the sources, but I guess it is not the case for ken-cc
suite).
2) On a 64 bits (since Charles Forsyth has done work for amd64 at least
on ken-cc, this exists), I imagine "long" is an octa (64 bits).
64 bits seems to me a bit wastefull since this won't increase TeX
precision, but will take more space. The only "plus", on 64 bits, is
that this is---I guess---the "word", the natural size, so it should be
more efficient for access.
Furthermore, in the memory_word data structure, the integer ("at
least" tetra) comes along with a glueratio (that is not a crucial
value) that should be the same size for more efficient access. IEEE
single precision is C float, and is a tetra too so does the trick on 32
bits architectures.
If "integer" is an octa (64 bits), glueratio should be a "double".
So the questions:
1) Is there any rule, at least for ken-cc, identifying C "int" with the
machine "word"? (It seems natural, but nothing is mandatory.)
2) Are tetra only _data_ programs---I don't speak about the
instructions that can be 64 bits: I speak about the data structures---
as efficient as 64 bits ones on 64 bits architectures?
/* shame */ I have only ia32 machines---and single core... and I haven't
wandered in the sources either...
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
