On Fri, 14 Sep 2001 16:42:21 -0400, Dan Sugalski wrote:
Nope. At the very least, a bytecode file needs to start with:
8-byte word:endianness (magic value 0x123456789abcdef0)
byte: word size
byte[7]:empty
word: major version
word: minor version
Where
At 12:24 PM 9/24/2001 +0200, Bart Lateur wrote:
On Fri, 14 Sep 2001 16:42:21 -0400, Dan Sugalski wrote:
Nope. At the very least, a bytecode file needs to start with:
8-byte word:endianness (magic value 0x123456789abcdef0)
byte: word size
byte[7]:empty
word:
After reading various posts about the bytcode file format it occurred to
me that we need to determine what we need :)
Meta-information:
* Magic cookie
* version
* endian/size markers
* index of all chunks for fast lookup
Things we need to store:
* bytecode
* external symbols/list of
Simon Cozens sent the following bits through the ether:
If you don't know what Python's CodeObjects look like, I suggest
you go see it now.
I've been spendind a lot of time recently looking at the Java
classfile specification. Yes, they were trying to optimise for space,
but there are some
On Fri, Sep 14, 2001 at 04:42:21PM -0400, Dan Sugalski wrote:
At 03:10 PM 9/14/2001 -0500, Brian Wheeler wrote:
I've been thinking alot about the bytecode file format lately. Its
going to get really gross really fast when we start adding other
(optional) sections to the code.
So, with
On Sat, Sep 15, 2001 at 04:17:34PM +0100, Nicholas Clark wrote:
On Fri, Sep 14, 2001 at 06:11:35PM -0400, Dan Sugalski wrote:
What we're doing is making sure the common case, the bytecode on disk being
used by the platform that owns the drive, is as fast as possible. We're
also making
I've been thinking alot about the bytecode file format lately. Its
going to get really gross really fast when we start adding other
(optional) sections to the code.
So, with that in mind, here's what I propose:
* All data sizes are in longwords (4 bytes) because that's just the way
things are
Just a quick note (since I have no time for more commentary...):
for inspiration on the data storage you might want to look at how
Storable has chosen to do things.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. --
At 03:10 PM 09-14-2001 -0500, Brian Wheeler wrote:
I've been thinking alot about the bytecode file format lately. Its
going to get really gross really fast when we start adding other
(optional) sections to the code.
So, with that in mind, here's what I propose:
snip
What do you guys think?
At 03:10 PM 9/14/2001 -0500, Brian Wheeler wrote:
I've been thinking alot about the bytecode file format lately. Its
going to get really gross really fast when we start adding other
(optional) sections to the code.
So, with that in mind, here's what I propose:
* All data sizes are in longwords
At 04:44 PM 9/14/2001 -0400, Buddha Buck wrote:
What do you guys think?
Have you taken a look at the old Amiga IFF format? It consisted mainly of
chunks identified by a 32-bit type code and a chunk-length code. While
most implementations were for specific multi-media applications (chunks
Have you taken a look at the old Amiga IFF format? It consisted mainly of
chunks identified by a 32-bit type code and a chunk-length code. While
most implementations were for specific multi-media applications (chunks
defining sound formats, chunks defining image formats, etc), the
On Fri, 2001-09-14 at 15:44, Buddha Buck wrote:
At 03:10 PM 09-14-2001 -0500, Brian Wheeler wrote:
I've been thinking alot about the bytecode file format lately. Its
going to get really gross really fast when we start adding other
(optional) sections to the code.
So, with that in mind,
I believe that Microsoft is using a derivative of that format for some of
its files, and I think that TIFF files are another instantiation.
To avoid using Redmondian references :-) I think IFF was one
of the strongest inspirations for the PNG .
...and here's a link that explains the
Brian --
I've been thinking alot about the bytecode file format lately. Its
going to get really gross really fast when we start adding other
(optional) sections to the code.
So, with that in mind, here's what I propose:
This may be too crazy, but if we take seriously the notion that we
8-byte word:endianness (magic value 0x123456789abcdef0)
byte: word size
byte[7]:empty
word: major version
word: minor version
Where all word values are as big as the word size says they are.
The magic value can be something else, but it should
--- Brian Wheeler [EMAIL PROTECTED] wrote:
I've been thinking alot about the bytecode file format
lately. Its
going to get really gross really fast when we start
adding other
(optional) sections to the code.
So, with that in mind, here's what I propose:
* All data sizes are in
On Fri, 2001-09-14 at 15:42, Dan Sugalski wrote:
At 03:10 PM 9/14/2001 -0500, Brian Wheeler wrote:
I've been thinking alot about the bytecode file format lately. Its
going to get really gross really fast when we start adding other
(optional) sections to the code.
So, with that in mind,
At 01:56 PM 9/14/2001 -0700, Hong Zhang wrote:
8-byte word:endianness (magic value 0x123456789abcdef0)
byte: word size
byte[7]:empty
word: major version
word: minor version
Where all word values are as big as the word size says they are.
We can't do that. There are platforms on both ends that
have _no_ native 32-bit data formats (Crays, some 16-bit
CPUs?). They still need to be able to load and generate
bytecode without ridiculuous CPU penalties (your Palm III
is not running on a 700MHz Pentium III, after all!)
If the
--- Brian Wheeler [EMAIL PROTECTED] wrote:
Ok, what if we did IFF with these caveats:
* all chunks must be padded to 4 bytes (instead of IFF's
2)
* no nesting of FORMs
Chunks we'd need are:
Name: 'PINF' - Parrot Information
Size: 28 bytes + size of
On Fri, Sep 14, 2001 at 02:26:37PM -0700, Hong Zhang wrote:
We can't do that. There are platforms on both ends that
have _no_ native 32-bit data formats (Crays, some 16-bit
CPUs?). They still need to be able to load and generate
bytecode without ridiculuous CPU penalties (your Palm III
There's a one-off conversion penalty at bytecode load time, and I don't
consider that excessive. I want the bytecode to potentially be in platform
native format (4/8 byte ints, big or little endian) with a simple and
well-defined set of conversion semantics. That way the bytecode loader
On Fri, Sep 14, 2001 at 03:01:11PM -0700, Damien Neil wrote:
On Fri, Sep 14, 2001 at 04:42:21PM -0400, Dan Sugalski wrote:
Where all word values are as big as the word size says they are.
What should the byteloader do when it encounters data in a word that
cannot fit in a native word?
It
On Sat, Sep 15, 2001 at 01:03:51AM +0300, Jarkko Hietaniemi wrote:
Re: IFF. Being an old Amiga user, I find it appealing. Is the lack
of a dictionary likely to be a significant problem?
Please elaborate.
IFF stores a linear series of chunks. Each chunk has a header containing
the
On Sat, Sep 15, 2001 at 12:39:39AM +0300, Jarkko Hietaniemi wrote:
It will be hard to use one format for both native and portable.
Not one format, but a set of closely related formats with well-defined
transformations between them.
After thinking about implementing this for a bit, I'm
At 03:18 PM 9/14/2001 -0700, Damien Neil wrote:
On Sat, Sep 15, 2001 at 01:03:51AM +0300, Jarkko Hietaniemi wrote:
Re: IFF. Being an old Amiga user, I find it appealing. Is the lack
of a dictionary likely to be a significant problem?
Please elaborate.
IFF stores a linear series of
On Fri, Sep 14, 2001 at 06:37:33PM -0400, Dan Sugalski wrote:
At 03:29 PM 9/14/2001 -0700, Damien Neil wrote:
On Sat, Sep 15, 2001 at 12:39:39AM +0300, Jarkko Hietaniemi wrote:
It will be hard to use one format for both native and portable.
Not one format, but a set of closely related
On Fri, Sep 14, 2001 at 02:35:33PM -0700, Benjamin Stuhl wrote:
Chunks we'd need are:
Name: 'PINF' - Parrot Information
Name: 'PBYT' - Parrot Bytecode
Name: 'PSTR' - Parrot String Table
Name: 'PFIX' - Parrot Fixup Table
Name:
Attached a simple bytecode header reader/writes that writes out the
natively correct output, and can read in recognize the output of any
(for small enough values of any) other platform. Tried on x86 (32LE),
sparc (32BE), alpha (64LE), mips (32BE/64BE, compiler-switchable), and
unicosmk (64BE,
30 matches
Mail list logo
