Re: INTEGER's destiny

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