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