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 mak
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
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 i
Benjamin Stuhl:
# --- 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 prop
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, r
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 Ta
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 clo
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 formats with well-defined
> > transformations between them.
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
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:01 PM 9/14/2001 -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?
That, generally
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 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?
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?
Re: IFF. Being an old Amiga user, I find it appealing. Is the lack
I might try tonight doing *very* simple code to portably write and
read the bytecode header since I have access to 32/64 little/big
endian boxes and to the resident gremlin of a platform, UNICOS.
(Well, it's really UNICOS/mk, so it's LE, not BE, as real UNICOS,
but it still has the funky integer s
> 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.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'.
> 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 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
--- 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 o
> 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 p
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
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 i
--- 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
> 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
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
> > 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 t
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 i
> 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
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 (ch
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 lon
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:
>What do you guys think?
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'. --
32 matches
Mail list logo
