[9fans] ken-cc, 64 bits machine, and 32 bits integers

[9fans] ken-cc, 64 bits machine, and 32 bits integers

[tlaronde]

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

Re: [9fans] ken-cc, 64 bits machine, and 32 bits integers

[erik quanstrom]

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

with kenc, long === 32 bits even on 64 bit machines; there is no
difference in storage size between long and int.

- erik

Re: [9fans] ken-cc, 64 bits machine, and 32 bits integers

[EBo]

> with kenc, long === 32 bits even on 64 bit machines; there is no
> difference in storage size between long and int.

out of curiosity, does kenc implement long long's?

Re: [9fans] ken-cc, 64 bits machine, and 32 bits integers

[Devon H. O'Dell]

vlong

2010/3/30 EBo <ebo@sandien.com>:
>
>> with kenc, long === 32 bits even on 64 bit machines; there is no
>> difference in storage size between long and int.
>
> out of curiosity, does kenc implement long long's?
>
>
>

Re: [9fans] ken-cc, 64 bits machine, and 32 bits integers

[Charles Forsyth]

on 64-bit machines, int and long are 32 bits,
long long (vlong) is 64 bits, just as on 32-bit machines,
but pointers are 64 bits.  <u.h> defines uintptr
as the integer type that will hold a pointer.
u8int, u16int, u32int and u64int are used in device drivers
and elsewhere to declare values (eg, in memory-mapped
structures or protocol buffers) that must be a precise length.

Re: [9fans] ken-cc, 64 bits machine, and 32 bits integers

[Patrick Kelly]

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

Useful reading:
	http://plan9.bell-labs.com/sys/doc/comp.html
	http://plan9.bell-labs.com/sys/doc/compiler.html

> /* shame */ I have only ia32 machines---and single core... and I
> haven't
> wandered in the sources either...

You should at least look at u.h

Re: [9fans] ken-cc, 64 bits machine, and 32 bits integers

[tlaronde]

On Tue, Mar 30, 2010 at 09:11:07PM +0100, Charles Forsyth wrote:
> on 64-bit machines, int and long are 32 bits,
> long long (vlong) is 64 bits, just as on 32-bit machines,
> but pointers are 64 bits.  <u.h> defines uintptr
> as the integer type that will hold a pointer.
> u8int, u16int, u32int and u64int are used in device drivers
> and elsewhere to declare values (eg, in memory-mapped
> structures or protocol buffers) that must be a precise length.

Thanks. As suggested by many, I will read u.h.

Since I wanted to keep the code pure C89, going with "long" will do
without trying to be smarter. Second option, goes POSIX/APE and use
uint32_t/u32int incarnations. I think I will go the former.
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] ken-cc, 64 bits machine, and 32 bits integers

[tlaronde]

On Tue, Mar 30, 2010 at 04:54:59PM -0400, Patrick Kelly wrote:
> >"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).
>
> Useful reading:
> 	http://plan9.bell-labs.com/sys/doc/comp.html
> 	http://plan9.bell-labs.com/sys/doc/compiler.html

I have the printed docs (from Vita Nuova), have read them (some times
ago), but probably missed the bits because I was not focused on these
details then ;)
--
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C