Am Montag, 23. Oktober 2006 18:31 schrieb Jonathan Worthington:
> > 1,5) same + range of indices
> >
>
> Will a dynamic character set or encoding library that we load not
> possibly contain more than one character set or encoding and therefore
> need a range of indices too? I have gone with thi
Hi,
Sorry for delay in getting to this - been working on-site with $JOB for
a while. Comments and questions below, but please see r15001.
Leopold Toetsch wrote:
2) How should we handle changes to the core Parrot library (mostly PMCs,
but also consider anything we promise is available)? Should
Leopold Toetsch wrote:
Indeed. But we probably want to have an UUID to identify
loaded .pasm/.pir/.pbc to avoid loading duplicates.
The UUID as proposed was intended for that; I just hashed up the
definition in the PDD. Er, no pun intended.
As a side note: distinct PBC segments for checksu
Bernhard Schmalhofer wrote:
One thing that I noticed is the naming of the new field UUID.
||| The UUID is |
||| computed by applying the hash function specified
in|
||| the UUID type field over the entire packfile
not |
||
Am Donnerstag, 5. Oktober 2006 23:04 schrieb Bernhard Schmalhofer:
> Shouldn't this field be renamed to something like 'checksum' ? The term
> 'UUID' already has a specific meaning, http://en.wikipedia.org/wiki/UUID.
Indeed. But we probably want to have an UUID to identify
loaded .pasm/.pir/.pbc
Jonathan Worthington schrieb:
Hi,
I've checked in the proposed bytecode PDD and also most of the changes
that I discussed with Allison earlier today. Feedback on it would be
greatly appreciated.
One thing that I noticed is the naming of the new field UUID.
||| The UUID is |
Am Freitag, 29. September 2006 01:39 schrieb Jonathan Worthington:
> Hi,
>
> I've checked in the proposed bytecode PDD and also most of the changes
> that I discussed with Allison earlier today. Feedback on it would be
> greatly appreciated.
Great work, thanks.
> A couple of open questions on thi
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
Hey, new guy here.
Welcome. :-)
I'm really interested in the parrot bytecode. What are the files/dirs I
should be looking at to understand everything about packfiles, including
layout, api to deal with it, extracting, writing, JIT compiling, et
At 1:33 PM +0200 5/21/04, Jens Rieks wrote:
The problem is how to actually load (byte)code without the help of these
functions. Thats why I've added Parrot_load_bytecode_direct. The "not direct"
version can use parrotlib code to locate the specified file by iterating
through a list of "directories"
Hi,
the code is now in. To use it, uncomment the #define _PARROTLIB in
src/dynext.c:23 (for load_bytecode) and
imcc/imcc.l:815 (for .include instructions)
and create the parrotlib.pbc file:
./parrot -o runtime/parrot/include/parrotlib.pbc \
runtime/parrot/library/parrotlib.imc
WARNIN
At 01:07 PM 11/23/2003 +0100, Leopold Toetsch wrote:
Melvin Smith <[EMAIL PROTECTED]> wrote:
> At 11:34 PM 11/22/2003 +0100, Leopold Toetsch wrote:
> Ix regs are for:
> 1) Fast integer stuff
> 2) Iteration (increment variables)
> 3) Conditional checks
> 4) Branching and holding addresses
> 5) Index
Melvin Smith <[EMAIL PROTECTED]> wrote:
> At 11:34 PM 11/22/2003 +0100, Leopold Toetsch wrote:
>>The concept of having INTVAL constants inside the opcodes is
>>wrong from a general POV. Please have a look at e.g jit/arm/ what
>>immediate constants are requiring as work arounds.
> I'm not aware of
At 10:14 PM 11/22/2003 -0500, Melvin Smith wrote:
At 11:34 PM 11/22/2003 +0100, Leopold Toetsch wrote:
Melvin Smith <[EMAIL PROTECTED]> wrote:
> to override it, it is not supported to choose INTVAL > OPCODE, though
> the inverse is. So storing it in the header is probably redundant, unless
> we cha
At 11:34 PM 11/22/2003 +0100, Leopold Toetsch wrote:
Melvin Smith <[EMAIL PROTECTED]> wrote:
> Parrot currently assumes INTVAL size == OPCODE size because
> both get configured as the same integral type, although you can choose
> to override it, it is not supported to choose INTVAL > OPCODE, thoug
Melvin Smith <[EMAIL PROTECTED]> wrote:
> Parrot currently assumes INTVAL size == OPCODE size because
> both get configured as the same integral type, although you can choose
> to override it, it is not supported to choose INTVAL > OPCODE, though
> the inverse is. So storing it in the header is pr
If memory serves me right, James Michael DuPont wrote:
> > JVM had a LineNumberTable and VarNameTable for debugging which were
> > declared as ``attributes'' to each method in the .class tree.
> >
> > I suppose VarNameTable is totally irrelevant for Parrot ...
>
> I dont know that, what is it? Va
--- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> James Michael DuPont wrote:
>
> > --- [EMAIL PROTECTED] wrote:
> >
> >>Mike --
> >>
> >>Thats a lot of metadata.
> >>
> >
> > OK that sounds fine. My current problems with the graphs of
> meta-data
> > are the speed of loading.
>
>
> When you
James Michael DuPont wrote:
--- [EMAIL PROTECTED] wrote:
Mike --
Thats a lot of metadata.
OK that sounds fine. My current problems with the graphs of meta-data
are the speed of loading.
When you arrange the meta-data as a single opcode stream, you have ~zero
load time for the mmap()ed c
Hey Gopal,
Nice to meet you here ;)
--- Gopal V <[EMAIL PROTECTED]> wrote:
> If memory serves me right, James Michael DuPont wrote:
> > I just want to know how where we can put it. The Microsoft IL
> > has a whole section on meta-data,
>
> AFAIK, that just holds the offset, line number and file
--- [EMAIL PROTECTED] wrote:
> Mike --
>
> Thats a lot of metadata. Sounds like maybe the metadata is primary
> and the bytecode is secondary, in which case perhaps what you
> really want is a (metadata) tree decorated with bytecode rather than
> a (bytecode) array decorated with metadata.
Fair
If memory serves me right, James Michael DuPont wrote:
> I just want to know how where we can put it. The Microsoft IL
> has a whole section on meta-data,
AFAIK, that just holds the offset, line number and filename. IIRC the
JVM had a LineNumberTable and VarNameTable for debugging which were
dec
Juergen,
I completly agree with you. For my needs, the meta-data does not have
to be loaded at the same time at all. I can be in a different file for
I care. I just want to know how where we can put it. The Microsoft IL
has a whole section on meta-data, and one wonders what Parrot might be
doing t
To: [EMAIL PROTECTED]
cc: Perl6 Internals <[EMAIL PROTECTED]>
Subject:Re: Bytecode metadata
[EMAIL PROTECTED] writes:
> Mike --
>
> Thats a lot of metadata. Sounds like maybe the metadata is primary
> and the bytecode is secondary, in
[EMAIL PROTECTED] writes:
> Mike --
>
> Thats a lot of metadata. Sounds like maybe the metadata is primary
> and the bytecode is secondary, in which case perhaps what you
> really want is a (metadata) tree decorated with bytecode rather than
> a (bytecode) array decorated with metadata.
The byte
ROTECTED]>, Dave Mitchell <[EMAIL PROTECTED]>
Subject:Re: Bytecode metadata
Dear All,
I just wanted to ask about a conclusion on the bytecode metadata.
Here are the things I would like to know about a given bytecode :
what line (maybe column) it comes from
Possibl
James Michael DuPont wrote:
Dear All,
I just wanted to ask about a conclusion on the bytecode metadata.
Here are the things I would like to know about a given bytecode :
what line (maybe column) it comes from
File/line information is already there (imcc -d -o...) and working.
If it is a me
Dear All,
I just wanted to ask about a conclusion on the bytecode metadata.
Here are the things I would like to know about a given bytecode :
what line (maybe column) it comes from
Possible comments about it.
If it is a method call, what is the method name,signature,locatoin
If it is a variable
If memory serves me right, James Michael DuPont wrote:
> > > Bah. That's "parrot -o foo.o foo.pmc" isn't it?
> >
> > And if we make C a parrot supported language we can even build parrot
> > with parrot?
Hmmm... bootstrapping
> 1. The gcc : I have %99 of the information about the function b
On Sun, 26 Jan 2003, James Mastros wrote:
> just define a new packfile section, SIGNATURE, that is defined to be a
> cryptographic signature of all sections previous to it in the file.
I'm battling with this in another file format at the moment; if possible can
we please *not* have it sensitive to
--- Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> Nicholas Clark <[EMAIL PROTECTED]> writes:
> > I guess in future once the normal JIT works, and we've got the pigs
> flying
> > nicely then it would be possible to write a Not Just In Time
> compiler that
> > saves out assembly code and relocation
Juergen Boemmels wrote:
Nicholas Clark <[EMAIL PROTECTED]> writes:
struct Chunk {
opcode_t type;
opcode_t version;
opcode_t size;
void data[];
};
will this ever compile?
It's similar to "opcode_t *data". If size == 0, no data follow in byte
stream. byte_code_{un,}pack is implem
On 27 Jan 2003, Juergen Boemmels wrote:
> Nicholas Clark <[EMAIL PROTECTED]> writes:
> > > struct Chunk {
> > > opcode_t type;
> > > opcode_t version;
> > > opcode_t size;
> > > void data[];
> > > };
> > I agree with the "roughly" bit, but I'd suggest
Nicholas Clark <[EMAIL PROTECTED]> writes:
[...]
> > struct Chunk {
> > opcode_t type;
> > opcode_t version;
> > opcode_t size;
> > void data[];
> > };
will this ever compile?
void data[] is not allowed, and even char data[] is an incomplet
On 01/26/2003 2:18 PM, Sean O'Rourke wrote:
Maybe a config option? The app I'm thinking of was pathological, in that
it mapped in thousands of 20-byte files. Now that I think about it,
unless someone implements something very strangely (or has absolutely
enormous numbers of threads) this shouldn
On 01/25/2003 4:26 AM, Leopold Toetsch wrote:
Nicholas Clark wrote:
Also some way of storing a cryptographic signature in the file, so
that you
could compile a parrot that automatically refuses to load code that isn't
signed by you.
The palladium parrot :)
Just because it's possible to use a te
On Sat, 25 Jan 2003, Leopold Toetsch wrote:
> Is one PBC file a small thing? Or in other words, should we have a low
> limit where we start again to malloc and copy PBC files?
> Configure option? Commandline switch?
Maybe a config option? The app I'm thinking of was pathological, in that
it mappe
On Sat, Jan 25, 2003 at 05:38:08PM -0800, Sean O'Rourke wrote:
> The problem's actually _virtual_ memory use/fragmentation, not physical
> memory or swap. Say you map in 10k small files -- that's 640M virtual
> memory, just over a fourth of what's available. Now let's say you're also
> using mmap
Sean O'Rourke wrote:
How true. On Solaris, for example, mmap's are aligned on 64k boundaries,
which leads to horrible virtual address space consumption when you map
lots of small things. If we're mmap()ing things, we want to be sure
they're fairly large.
Is one PBC file a small thing? Or in
On Sat, 25 Jan 2003, Dave Mitchell wrote:
> On Sat, Jan 25, 2003 at 06:18:47AM -0800, Sean O'Rourke wrote:
> > On Sat, 25 Jan 2003, Leopold Toetsch wrote:
> > > Dan Sugalski wrote:
> > >
> > > > At 5:32 PM + 1/24/03, Dave Mitchell wrote:
> > > >
> > > >> I just wrote a quick C program that succ
On Sun, Jan 26, 2003 at 12:40:19AM +, Nicholas Clark wrote:
> On Sat, Jan 25, 2003 at 11:43:40PM +, Dave Mitchell wrote:
> > Okay, I just ran a program on a a Solaris machines that mmaps in each
> > of 571 man files 20 times (a total of 11420 mmaps). The process size
> > was 181Mb, but the
On Sat, Jan 25, 2003 at 11:43:40PM +, Dave Mitchell wrote:
> On Sat, Jan 25, 2003 at 06:18:47AM -0800, Sean O'Rourke wrote:
> > On Sat, 25 Jan 2003, Leopold Toetsch wrote:
> > > Dan Sugalski wrote:
> > >
> > > > At 5:32 PM + 1/24/03, Dave Mitchell wrote:
> > > >
> > > >> I just wrote a quic
On Sat, Jan 25, 2003 at 10:04:37AM -0500, Jason Gloudon wrote:
> On Thu, Jan 23, 2003 at 08:39:21PM +, Dave Mitchell wrote:
>
> > This means that a Perl server that relies on a lot of modules, and which
> > forks for each connection (imagine a Perl-based web server), doesn't
> > consume acres
On Sat, Jan 25, 2003 at 06:18:47AM -0800, Sean O'Rourke wrote:
> On Sat, 25 Jan 2003, Leopold Toetsch wrote:
> > Dan Sugalski wrote:
> >
> > > At 5:32 PM + 1/24/03, Dave Mitchell wrote:
> > >
> > >> I just wrote a quick C program that successfully mmap-ed in all 1639
> > >> files in my Linux bo
On Thu, Jan 23, 2003 at 08:39:21PM +, Dave Mitchell wrote:
> This means that a Perl server that relies on a lot of modules, and which
> forks for each connection (imagine a Perl-based web server), doesn't
> consume acres of swap space just to have an in-memory image per Perl
> process, of all
On Sat, 25 Jan 2003, Leopold Toetsch wrote:
> Dan Sugalski wrote:
>
> > At 5:32 PM + 1/24/03, Dave Mitchell wrote:
> >
> >> I just wrote a quick C program that successfully mmap-ed in all 1639
> >> files in my Linux box's /usr/share/man/man1 directory.
> >
> >
> > Linux is not the universe, tho
Nicholas Clark wrote:
On Sat, Jan 25, 2003 at 10:26:22AM +0100, Leopold Toetsch wrote:
The palladium parrot :)
naa. I said "signed by you", not "signed by the RIAA^WMPAA^WMicrosoft"
Yes, of course. I would do this with a personalized version of
fingerprint.c and generate a separate exe
Dan Sugalski wrote:
At 5:32 PM + 1/24/03, Dave Mitchell wrote:
I just wrote a quick C program that successfully mmap-ed in all 1639
files in my Linux box's /usr/share/man/man1 directory.
Linux is not the universe, though.
I have it changed to use mmap() bytecode (other segments, with
On Sat, Jan 25, 2003 at 10:26:22AM +0100, Leopold Toetsch wrote:
> Nicholas Clark wrote:
> >Also some way of storing a cryptographic signature in the file, so that you
> >could compile a parrot that automatically refuses to load code that isn't
> >signed by you.
>
>
> The palladium parrot :)
na
Nicholas Clark wrote:
On Thu, Jan 23, 2003 at 02:48:38PM -0800, Brent Dax wrote:
struct Chunk {
opcode_t type;
opcode_t version;
opcode_t size;
void data[];
};
I agree with the "roughly" bit, but I'd suggest ensuring that you put
in enough bits to get data[] 64 bit aligned.
If t
On Thu, Jan 23, 2003 at 02:48:38PM -0800, Brent Dax wrote:
> Are you expecting to have chunk type determined by order? If so, what
> will you do if a future restructuring means you either don't need chunk
> type X or you need a new, highly incompatible version? Will you leave
> in an "empty" gho
At 5:32 PM + 1/24/03, Dave Mitchell wrote:
On Fri, Jan 24, 2003 at 07:23:04AM +0100, Leopold Toetsch wrote:
How many mmap's can $arch have for one program and for all?
Could we hit some limits here, if every module loaded gets (and stays)
mmap()ed.
I just wrote a quick C program that suc
On Fri, Jan 24, 2003 at 07:23:04AM +0100, Leopold Toetsch wrote:
> How many mmap's can $arch have for one program and for all?
> Could we hit some limits here, if every module loaded gets (and stays)
> mmap()ed.
I just wrote a quick C program that successfully mmap-ed in all 1639
files in my Linu
Leopold Toetsch wrote:
I'm currently simplifying the whole packfile routines. It still does
read the old format, but the compat code is centralized now in one place.
Registered types are consecutively numbered, unknown types still get
unpacked or dumped:
typedef enum {
PF_DIR_SEG,
P
Dan Sugalski wrote:
At 8:39 PM + 1/23/03, Dave Mitchell wrote:
in such a way that it (or most of it) can simply be mmap-ed in (RO),
analogously to executables.
This is the way the bytecode currently works, and we will *not* switch
to any bytecode format that doesn't at least allow the
Juergen Boemmels wrote:
Dan Sugalski <[EMAIL PROTECTED]> writes:
It might be even possible to dump the jitted code. This would increase
the startup. Then strip the bytecode to reduce the size of the file
and TADA: Yet another new binary format.
When you then are able to to get the same mem
At 7:23 AM +0100 1/24/03, Leopold Toetsch wrote:
Dave Mitchell wrote:
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
in such a way that it (
Dan Sugalski wrote:
Since it looks like it's time to extend the packfile format and the
in-memory bytecode layout, this would be the time to start discussing
metadata. What sorts of metadata do people think are useful to have in
either the packfile (on disk) or in the bytecode (in memory).
I'
Dave Mitchell wrote:
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
in such a way that it (or most of it) can simply be mmap-ed in (RO),
anal
--- Brent Dax <[EMAIL PROTECTED]> wrote:
> Dan Sugalski:
> # At 12:10 AM -0800 1/23/03, Brent Dax wrote:
> # >Dan Sugalski:
> # ># Since it looks like it's time to extend the packfile
> # format and the #
> # >in-memory bytecode layout, this would be the time to start
> # discussing #
> # >met
At 2:48 PM -0800 1/23/03, Brent Dax wrote:
Dan Sugalski:
# At 12:10 AM -0800 1/23/03, Brent Dax wrote:
# >Dan Sugalski:
# ># Since it looks like it's time to extend the packfile
# format and the #
# >in-memory bytecode layout, this would be the time to start
# discussing #
# >metadata. What sorts
--- Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> Hello,
>
> after quite a long time away from keyboard and fighting through a
> huge
> backlog of mail I'm (hopefully) back again.
>
> Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > Since it looks like it's time to extend the packfile format and
At 11:48 AM -0800 1/23/03, chromatic wrote:
On Wed, 22 Jan 2003 13:27:47 +, Dan Sugalski wrote:
Since it looks like it's time to extend the packfile format and the
in-memory bytecode layout, this would be the time to start discussing
metadata. What sorts of metadata do people think are us
At 8:39 PM + 1/23/03, Dave Mitchell wrote:
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
in such a way that it (or most of it) can simply
Dan Sugalski:
# At 12:10 AM -0800 1/23/03, Brent Dax wrote:
# >Dan Sugalski:
# ># Since it looks like it's time to extend the packfile
# format and the #
# >in-memory bytecode layout, this would be the time to start
# discussing #
# >metadata. What sorts of metadata do people think are useful
Dan Sugalski <[EMAIL PROTECTED]> writes:
> >This might be possible if the byteorder, wordsize, defaultencoding
> >etc. are the same in the file on disk and the host.
>
> Which will generally be the case, I expect. Tell a sysadmin that they
> can reduce the memory footprint of mod_parrot by 50% by
At 10:31 PM +0100 1/23/03, Juergen Boemmels wrote:
Dave Mitchell <[EMAIL PROTECTED]> writes:
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
> My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
Dave Mitchell <[EMAIL PROTECTED]> writes:
> On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
> > My current idea for the in memory format of the bytecode is this:
>
> I would strongly urge any file-based byte-code format to arranged
> in such a way that it (or most of it) can sim
At 12:10 AM -0800 1/23/03, Brent Dax wrote:
Dan Sugalski:
# Since it looks like it's time to extend the packfile format and the
# in-memory bytecode layout, this would be the time to start discussing
# metadata. What sorts of metadata do people think are useful to have
# in either the packfile (on
At 10:29 PM -0800 1/22/03, James Michael DuPont wrote:
You will probably think that this is overkill for parrot,
Why yes, yes I do. On the other hand, when we hand people bazookas to
deal with their fly problems, we often find they start in on the
elephant problems as well.
The proposal in ge
--- Dave Mitchell <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
> > My current idea for the in memory format of the bytecode is this:
>
> I would strongly urge any file-based byte-code format to arranged
> in such a way that it (or most of it) can
--- chromatic <[EMAIL PROTECTED]> wrote:
> On Wed, 22 Jan 2003 13:27:47 +, Dan Sugalski wrote:
>
> > Since it looks like it's time to extend the packfile format and the
>
> > in-memory bytecode layout, this would be the time to start
> discussing
> > metadata. What sorts of metadata do peop
On Thu, Jan 23, 2003 at 09:21:45PM +0100, Juergen Boemmels wrote:
> My current idea for the in memory format of the bytecode is this:
I would strongly urge any file-based byte-code format to arranged
in such a way that it (or most of it) can simply be mmap-ed in (RO),
analogously to executables.
Hello,
after quite a long time away from keyboard and fighting through a huge
backlog of mail I'm (hopefully) back again.
Dan Sugalski <[EMAIL PROTECTED]> writes:
> Since it looks like it's time to extend the packfile format and the
> in-memory bytecode layout, this would be the time to start d
On Wed, 22 Jan 2003 13:27:47 +, Dan Sugalski wrote:
> Since it looks like it's time to extend the packfile format and the
> in-memory bytecode layout, this would be the time to start discussing
> metadata. What sorts of metadata do people think are useful to have
> in either the packfile (o
Dan Sugalski:
# Since it looks like it's time to extend the packfile format and the
# in-memory bytecode layout, this would be the time to start discussing
# metadata. What sorts of metadata do people think are useful to have
# in either the packfile (on disk) or in the bytecode (in memory).
I
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Since it looks like it's time to extend the packfile format and the
> in-memory bytecode layout, this would be the time to start discussing
>
> metadata. What sorts of metadata do people think are useful to have
> in either the packfile (on disk) or
On Mon, 2002-05-13 at 07:07, Nicholas Clark wrote:
>
> Is this like the PNG file header?
Of course. I'm not that particularly clever.
> 0xCC is >128, designed to detect if the file has been stripped to 7 bit
Also, having the 8 bit set is often sufficient to trigger binary mode
for primitive
At 06:18 PM 5/11/2002 -0400, Bryan C. Warnock wrote:
>On Sat, 2002-05-04 at 01:52, Melvin Smith wrote:
> > Reposted to the list so people can comment.
> >
> > As per the IRC discussion with Dan.
> >
> > I've made some progress, not all there, but getting there.
> > I have the loader handling a
On Sat, 2002-05-04 at 01:52, Melvin Smith wrote:
> Reposted to the list so people can comment.
>
> As per the IRC discussion with Dan.
>
> I've made some progress, not all there, but getting there.
> I have the loader handling arbitrary byteordering, now I'm
> working on wordsize transforms.
On Wed, 2002-05-08 at 09:29, Melvin Smith wrote:
>
> Thanks for that, Bryan! I knew someone had posted some stuff claiming
> to have some float conversion stuff, but I couldn't remember who.
>
> This is a very good compilation of the issues we have to address.
>
> I implemented a byteordering s
On Sat, 4 May 2002, Brent Dax wrote:
> Melvin Smith:
> # I have a patch almost complete that makes Parrot handle
> # bytecode files across platforms (does endian and wordsize
> # transform), but there is one glaring non-portability, and
> # that is that we are storing floating point constants
At 2:30 AM -0400 5/5/02, Melvin Smith wrote:
>I have a patch almost complete that makes Parrot handle bytecode
>files across platforms (does endian and wordsize transform), but there is
>one glaring non-portability, and that is that we are storing floating point
>constants in native format.
>
>We
Melvin Smith:
# I have a patch almost complete that makes Parrot handle
# bytecode files across platforms (does endian and wordsize
# transform), but there is one glaring non-portability, and
# that is that we are storing floating point constants in native format.
#
# We need to discuss how we
On Sun, Dec 09, 2001 at 07:46:46PM -0500, Bryan C. Warnock wrote:
> Proposal:
>
> For background, revisit my proposed Bytecode Format (v2) at
> http:[EMAIL PROTECTED]/msg05640.html.
> Although it is outdated, is gives a general gist of the direction of my
> thinking. In particular, pay no heed t
At 08:33 AM 12/10/2001 -0500, Bryan C. Warnock wrote:
>On Monday 10 December 2001 03:06 am, Tom Hughes wrote:
> > In message <20011210011601$[EMAIL PROTECTED]>
> >
> > "Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> > > - Endianness. The three major types are Big, Little, and Vaxian.
>
In message <20011210133529.EYKY11472.femail13.sdc1.sfba.home.com@there>
Bryan C. Warnock <[EMAIL PROTECTED]> wrote:
> On Monday 10 December 2001 03:06 am, Tom Hughes wrote:
> > In message <20011210011601$[EMAIL PROTECTED]>
> >
> > Actually VAXes have perfectly ordinary endianness - it was
On Monday 10 December 2001 03:06 am, Tom Hughes wrote:
> In message <20011210011601$[EMAIL PROTECTED]>
>
> "Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> > - Endianness. The three major types are Big, Little, and Vaxian.
> > Supporting these three should handle the majority of cases.
>
In message <20011210011601$[EMAIL PROTECTED]>
"Bryan C. Warnock" <[EMAIL PROTECTED]> wrote:
> - Endianness. The three major types are Big, Little, and Vaxian.
> Supporting these three should handle the majority of cases.
Actually VAXes have perfectly ordinary endianness - it was PDPs
At 06:44 PM 9/18/2001 -0700, Hong Zhang wrote:
> > Proposed: Parrot should never crash due to malformed bytecode. When
> > choosing between execution speed and bytecode safety, safety should
> > always win. Careful op design and possibly a validation pass before
> > execution will hopefully keep
> Proposed: Parrot should never crash due to malformed bytecode. When
> choosing between execution speed and bytecode safety, safety should
> always win. Careful op design and possibly a validation pass before
> execution will hopefully keep the speed penalty to a minimum.
We can use similar mo
Russ Allbery:
# Simon Cozens <[EMAIL PROTECTED]> writes:
#
# > Yep, and the latest "pedantic" patch doesn't help. Also, I'm seeing
# > this, which is weird:
#
# > ld -ldbm -ldb -lm -liconv -o test_prog global_setup.o
# interpreter.o parrot.o register.o basic_opcodes.o memory.o
# bytecode.o s
Gibbs Tanton <- tgibbs <[EMAIL PROTECTED]>> writes:
> I would vote no. HOWEVER, I would think that the user should have the
> option to turn on checking for malformed bytecode (i.e. Safe mode). In
> the default case, I think the bytecode should be assumed well formed and
> no extra checking be
Simon Cozens <[EMAIL PROTECTED]> writes:
> Yep, and the latest "pedantic" patch doesn't help. Also, I'm seeing
> this, which is weird:
> ld -ldbm -ldb -lm -liconv -o test_prog global_setup.o interpreter.o parrot.o
>register.o basic_opcodes.o memory.o bytecode.o string.o strnative.o test_main.
On Tue, Sep 18, 2001 at 02:37:43PM -0700, Damien Neil wrote:
> Proposed: Parrot should never crash due to malformed bytecode.
Haven't we done this argument? :)
I'd vote no, FWIW.
--
Dames lie about anything - just for practice. -Raymond Chandler
I would vote no. HOWEVER, I would think that the user should have the
option to turn on checking for malformed bytecode (i.e. Safe mode). In the
default case, I think the bytecode should be assumed well formed and no
extra checking be performed.
-Original Message-
From: Damien Neil
To:
> Easy Makefile.in patch. I was worried that Win32 might need the linker
> (the change to $(LD) was submitted as part of a Win32 compatibility
> patch) but that doesn't seem to be the case. I don't have a MinGW
Fine here
Regards
Mattia
> OffsetLength Description
> 0 1 Magic Cookie (0x013155a1)
> 1 n Data
> n+1 m Directory Table
> m+n+1 1 Offset of beginning of directory table (i.e. n+1)
I think we need a version right after cookie for long term compatibility.
> The directory is after
97 matches
Mail list logo
