Re: INTEGER's destiny

José Bollo <[email protected]> Fri, 8 Dec 2006 22:02:06 +0100
Newsgroups gmane.comp.lang.eiffel.smalleiffel
Message-ID <[email protected]>
Le Vendredi 08 D=E9cembre 2006 18:01, Guillaume Lema=EEtre a =E9crit=A0:

> I'm also concerned with INTEGER bit representation. Now that I have an
> x86_64 based CPU, I want to use preferably 64bit-long integers, as it is
> supposed to be the fastest integer representation on this architecture

I don't think that 64 bits integers are faster on 64 bits architecture.
In fact i am sure that for applications that can use 32 bits integers, usin=
g=20
it is much more faster and less memory consumer.
Here is an extract of "Software Optimization Guide for AMD64 Processors", p=
age=20
68.

Optimization
	Use the 32-bit legacy general-purpose registers (EAX through ESI) instead =
of=20
	their 64-bit extensions to store unsigned integer values whose range never=
=20
	requires more than 32 bits, even if subsequent statements use the 32-bit
	value in a 64-bit operation. (For example, use ECX instead of RCX until you
	need to perform a 64-bit operation; then use RCX.)

Rationale
	In 64-bit mode, the machine-language representation of many instructions t=
hat
	operate on 64-bit register operands requires a REX prefix byte, which=20
	increases the size of the code. However, instructions that operate on a
	32-bit legacy register operand do not require the prefix and have the
	desirable side-effect of clearing the upper 32 bits of the extended regist=
er
	to zero. For example, using the AND instruction on ECX clears the upper ha=
lf
	of RCX.

> (the same way C coders intensively use 32bit-long integers on x86
> architecture). And this, I simply cannot : it would require both to
> patch all my code, but also all the SE libraries I use.
> I tried to lurk along SE code to find where correspondence between
> INTEGER and int is made during compilation; I have to say that it is not
> as isolated as I supposed, maybe because noone was paying interest on
> this very specific topic, and I can understand that.

Many people have been interested to that feature even into SE team.

> I'm ready to try to isolate this part, if some of the SE team are ready
> to help me and explain a bit of the compiler architecture.
>
> I think Raphael proposal is good : INTEGER configuration through an ACE
> file. Or at least at compiler installation time.
> Daniel's proposal is also very good for interfacing with legacy C code
> or C libraries.
>
> Guillaume

The position of SE team was to not change that.
But you can try to change the position of the seteam.

regards
jos=E9