So more changes in packfile and related files, including:
- all packfile segments share a common header which is effectively the format of a byte_code segment - all packfile segments conforming to this format are unpacked with the default_unpack routine, which just sets up a pointer to the data if they are mmap()ed (and are in native format) or makes a copy of the data, which means: - byte_code doesn't get copied anymore, when the PBC is mmap()ed - and: self modifying code is a nono - but we don't ;-) - segments with more or differing data have their own pack/unpack functions - The segments are aligned on 4 op boundarys, as well as bytecode - when mmap()ing the PBC fails, it gets read by IO - the pdump utility got two new switches -t (terse), -d (disassemble)
Imcc changes:
- adapted for above packfile - more tests - "perl t/harness -c" runs via new format PBC files (and shows 4 errors due to fixup quirks with evaled code in PBC :)
Some TODOs or leftovers:
- still (or more) wordsize issues with unpacking: to solve these IMHO the fetch_xxx should look like xxx PackFile_fetch_xxx(struct PackFile *pf, ptr_t **stream); advancing the stream ptr by one packfile wordsize, or doing whatever is necessary on CRAY or such - BTW does some has a spare CRAY for testing at home, just send it over - small one with less then 5kW heat emission prefered. Similar changes for the other packfile fetch functions + fetch_sv(). Or: Create external conversion program?
- 8/12 byte float issues are still the same - are these formats really portable, or should we try to store ASCII equivalents?
- The directory based approach now should be fully recursive allowing for nested dirs - of course untested, but ...
C99 and Modula 3 provide the "recommended" IEEE 754 bindings. Java requires it.
A nice quote from William Kahan father of IEEE 754: "Programmers seem unaware that IEEE 754 is a standard for their programming environment, not just for hardware."
On Wed, Jan 29, 2003 at 06:53:25AM +0100, Leopold Toetsch wrote: > Garrett Goebel wrote: > Many thanks for the links (searching for this stuff is a pain, there are > too many results ;-)
> Anyway: > - are there platforms with quad precision floats out there?
sparc Solaris and Irix both have 16 byte doubles. I think that they are both done in software, and I don't think either is to any IEEE standard.
> - or should 12 byte long doubles get converted to 8 byte IEEE doubles.
This doesn't feel like a good idea. It may be the only practical solution, but I doesn't mean that I have to like it.
Actually, Quads aren't standard. 'long doubles' and the ilk are double extended, and require at least 10 bytes. (Which, coincidentally, is the size of the x86 fp registers.)
In memory, they're padded to 12 or 16 bytes to preserve word boundaries.
-- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
On Wed, 2003-01-29 at 04:56, Nicholas Clark wrote: > On Wed, Jan 29, 2003 at 06:53:25AM +0100, Leopold Toetsch wrote: > > Garrett Goebel wrote:
> > Many thanks for the links (searching for this stuff is a pain, there are > > too many results ;-)
> > Anyway: > > - are there platforms with quad precision floats out there?
> sparc Solaris and Irix both have 16 byte doubles. I think that they are > both done in software, and I don't think either is to any IEEE standard.
Actually, Sparc and MIPS are pretty good about adherence. (There may be some breakdown in the specialized representation cases, as well as underflow representation.) In fact, most hardware these days use IEEE (or EEEI) representation. VAXen and CRU-based Crays are a brash exception.
> > - or should 12 byte long doubles get converted to 8 byte IEEE doubles.
> This doesn't feel like a good idea. It may be the only practical solution, > but I doesn't mean that I have to like it.
Let me dig through my notes.
-- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)
> Anyway: > - are there platforms with quad precision floats out there?
Several documents refer to quad precision hardware, but I can't find direct references to any.
> - or should 12 byte long doubles get converted to 8 byte IEEE doubles.
Perhaps the following quote from William Kahan would be appropriate:
> What Good are Extended Floating-Point Formats?
> This is more of a marketing question than mathematical, > and although the reasoning entails some mathematics beyond > the acquaintance of most marketing personnel, they will > all appreciate the conclusions, namely that ...
> o Were the wages of sin collected only by the sinners, > extended formats could be optional > o Extended formats are required more to support a mass > market than for numerical experts
