1. unix epoch rollover
- Posted by useless Apr 17, 2010
- 1820 views
If i start the hype over the 2038 rollover on 32bit systems now, will it get us 64bit Euphoria integers any faster? 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
useless
2. 64bit Euphoria
- Posted by jimcbrown (admin) Apr 17, 2010
- 1877 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...
3. Re: 64bit Euphoria
- Posted by mattlewis (admin) Apr 19, 2010
- 1820 views
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...
Although 63 bit integers (actually, much smaller) may be sufficient even so, given that MS restricts you to 16 terabytes of virtual memory, far less than a full 64-bit pointer could address.
Matt
4. Re: 64bit Euphoria
- Posted by jimcbrown (admin) Apr 19, 2010
- 1867 views
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...
Although 63 bit integers (actually, much smaller) may be sufficient even so, given that MS restricts you to 16 terabytes of virtual memory, far less than a full 64-bit pointer could address.
Matt
The problem here is is whether or not 16 terabytes will fit into a 53bit integer (the largest integer values that can be represented by a 64bit floating point number). If 64bit float points can't hold those addresses, then the issue of having atoms used to hold memory addresses from legacy code can't be address. (Although some backhand envelop math suggests that 16 terabytes will easily fit into a 64bit floating point number...)
In any case, being stuck with 64bit floats and 63bit integers still breaks the assumption that an atom can hold any value that an integer can.
5. Re: 64bit Euphoria
- Posted by mattlewis (admin) Apr 19, 2010
- 1821 views
The problem here is is whether or not 16 terabytes will fit into a 53bit integer (the largest integer values that can be represented by a 64bit floating point number). If 64bit float points can't hold those addresses, then the issue of having atoms used to hold memory addresses from legacy code can't be address. (Although some backhand envelop math suggests that 16 terabytes will easily fit into a 64bit floating point number...)
Easily. 16TB is only 244 bytes. 64 bits gives you a full exabyte. With 53 bits, we're limited to a mere petabyte.
In any case, being stuck with 64bit floats and 63bit integers still breaks the assumption that an atom can hold any value that an integer can.
I've always thought of that as more of an implementation detail than a design constraint. With 63-bit integers and regular double precision floating point numbers, we end up with a lot more precision, albeit through better integers. And at least we lose nothing with doubles, though they become more of a specialized data type, because you need a floating point number, rather than integer overflow.
The real question with 64-bit is whether we make the jump to additional data types. /ducks
Matt
6. Re: 64bit Euphoria
- Posted by jimcbrown (admin) Apr 19, 2010
- 1760 views
- Last edited Apr 20, 2010
In any case, being stuck with 64bit floats and 63bit integers still breaks the assumption that an atom can hold any value that an integer can.
I've always thought of that as more of an implementation detail than a design constraint.
Well, trying to get the interpreter to work this way caused me to see all kinds of strange memory faults.... memory addresses would get corrupted and I couldn't figure out why.
We could probably figure this out but I suspect it'd require a lot of rewriting of not only the source code of the interpreter and translator (and C code written by the translator) but also a bit of rewriting of the standard library. And likely in a way that's not going to be backwards compatible with the 32bit version (one will need to use integers for memory addresses and the other will need to use atoms).
