Re: INTEGER's destiny

left a écrit :
> Guillaume Lemaître wrote:
> 
>> Paolo Redaelli a écrit :
>>
>>> The message of revision 7102 (Fri Mar 31 08:31:43 2006 UTC by colnet),
>>> expecially regarding file smarteiffel/trunk/sys/runtime/c/base.h says:
>>>
>>> "No more `xxx.to_integer' or `xxx.is_integer' calls.
>>> Only size-numbered calls as for example `xxx.to_integer_32'
>>> or `xxx.is_integer_16'."
>>>
>>> Does it means that INTEGER is going to fade away and that we shall use
>>> only  INTEGER_[8|16|32|64] in newly written code? Or is your plan more
>>> elaborate?
>>>
>>> As usual thanks in advance for your attention
>>>     Paolo Redaelli
>>>
>>>
>>
>> I put my comments here to all the thread, for convenience, in order 
>> not to answer to a specific point of view.
>>
>> 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 (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.
>>
>> 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
>>
> I thought  on 64 bits plateform, the C 'int' type was still 32 bits 
> sized, while 'long int' was 64 bits. Am i wrong ? So C coders who wants 
> to use the largest native representation always should use the 'long 
> int' type instead of the 'int' type.
> 

you are right, on x86_64, int is still 32 bits long. But I was speaking 
of the widespread behavior, considering only 32 bits architecture.

Even this C code should be patched in order to switch to long int 
wherever appropriate.