[CVS ci] packfile #2
Leopold Toetsch
- 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 ...
leo
Garrett Goebel
>
> - 8/12 byte float issues are still the same - are these
> formats really portable, or should we try to store
> ASCII equivalents?
No?
? Because my knowledge here approaches zero, so I'm just aping information
back at you from google searches and scanning documents.
There are 3 standard binary IEEE 754 derived formats:
Single Precision: 4 bytes
Double Precision: 8 bytes
Quadruple Precision: 16 bytes
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."
Portable Encoding of Floating-Point Values
http://research.microsoft.com/~hollasch/cgindex/coding/portfloat.html
What hardware supports IEEE 754:
http://www.mscs.mu.edu/~georgec/IFAQ/casares1.html
IEEE 754 Binary Floating Point
William Kahan's documents:
http://http.cs.berkeley.edu/~wkahan/ieee754status/
IEE 754 Homepage:
http://grouper.ieee.org/groups/754/
Designing Language Support for IEEE 754:
http://grouper.ieee.org/groups/754/meeting-materials/2001-10-18-langdesign.p
df
IEEE 754 Support in C99
http://grouper.ieee.org/groups/754/meeting-materials/2001-07-18-c99.pdf
Nice Overview:
http://research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html
Nice Links:
http://cch.loria.fr/documentation/IEEE754/
IEEE 854 Decimal Floating Point
IBM's decNumber Library (non-free ANSI C impl of IEEE 854):
http://www2.hursley.ibm.com/decimal/decnumber.html
IBM's BigDecimal (open-source impl for Java of IEEE 854):
http://www2.hursley.ibm.com/decimalj/
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com gar...@scriptpro.com
Leopold Toetsch
> Leopold Toetsch wrote:
> >
> > - 8/12 byte float issues are still the same - are these
> > formats really portable, or should we try to store
> > ASCII equivalents?
>
> No?
>
> ? Because my knowledge here approaches zero, so I'm just aping
> information back at you from google searches and scanning documents.
>
> There are 3 standard binary IEEE 754 derived formats:
>
> Single Precision: 4 bytes
> Double Precision: 8 bytes
> Quadruple Precision: 16 bytes
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?
- or should 12 byte long doubles get converted to 8 byte IEEE doubles.
leo
Nicholas Clark
> 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.
Nicholas Clark
Bryan C. Warnock
> Leopold Toetsch wrote:
> >
> > - 8/12 byte float issues are still the same - are these
> > formats really portable, or should we try to store
> > ASCII equivalents?
>
> No?
>
> ? Because my knowledge here approaches zero, so I'm just aping information
> back at you from google searches and scanning documents.
>
> There are 3 standard binary IEEE 754 derived formats:
>
> Single Precision: 4 bytes
> Double Precision: 8 bytes
> Quadruple Precision: 16 bytes
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)
Bryan C. Warnock
> 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.
Garrett Goebel
>
> 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
The best single resource I've found yet is:
http://www.validlab.com/754R/
It has faithful representations of all the relevant IEEE standards, meeting
minutes, and proposals.