64bit Euphoria
- Posted by jimcbrown (admin) Apr 17, 2010
- 1879 views
In 2028, we won't be able to schedule anything 10 yrs in advance. Since i'll be in my 70's (and Jiri will be even older!), i might like to document my appointments.
It's like, even if win7 etc are now 2038-safe, Eu can't report the date with it's 32bit integers, rather like seek()ing into a file over 4294967296 bytes long. The mandated harddrive sectors over 512bytes (next yr) may cure the 32bit sector problem by accident, but not the byte count.
How do you tell your Ai that things do exist after 2038 if it cannot compute the condition of things after 2038?
<me> what will X look like in 30 yrs?
<Ai> X's condition is NIL in 30 years
If i start the hype over the 2038 rollover on 32bit systems now, will it get us 64bit Euphoria integers any faster?
No. Absolutely not. It won't make the slightest difference.
What I mean is, I was already working on this. My plan was to create a version of Euphoria that uses quadruple precision floating point types (128bit floats) for atoms, this way the relationship between atoms and the 63bit integers will be unchanged and atoms can be reliably used to hold pointer addresses, etc.
I had looked at using extended precision floating point types (80bit floats or GCC's "long double" type) but it turns out that neither MSVC or Watcom C support it.
I realize that this leads to the obvious problem of a 64bit Euphoria only being supported on the Unix ports. I figure that between now and 2028, someone will release a 64bit version of Watcom or at least a Watcom library that adds support for quadruple or extended precision float point types, which will make a 64bit Windows port possible...
