On Sat, Sep 15, 2001 at 08:16:36PM +0100, Simon Cozens wrote:
> On Sat, Sep 15, 2001 at 08:43:19PM +0300, Jarkko Hietaniemi wrote:
> > Never mind 'portable' for now, currently it's not even *working* on
> > 64-bit platforms
>
> That as may be, I'd like to make sure we start fixing it in the
>
On Sat, Sep 15, 2001 at 02:28:25PM -0500, Gibbs Tanton - tgibbs wrote:
> > Never mind 'portable' for now, currently it's not even *working* on
> > 64-bit platforms
>
> You might try putting an ! after the l in the assembler pack type and see if
> that fixes things.
'q' did the trick a few ve
> Never mind 'portable' for now, currently it's not even *working* on
> 64-bit platforms
You might try putting an ! after the l in the assembler pack type and see if
that fixes things. Right now, it is going to be putting opcodes out in 32
bits. Since Tru64 is 64 bits, a long is going to be
On Sat, Sep 15, 2001 at 08:43:19PM +0300, Jarkko Hietaniemi wrote:
> Never mind 'portable' for now, currently it's not even *working* on
> 64-bit platforms
That as may be, I'd like to make sure we start fixing it in the
right direction rather than the wrong one. :)
Simon
On Sat, 15 Sep 2001, Philip Kendall wrote:
> My personal view would be that the gains due to portable bytecode would
> be outweighed by the amount of cruft we'd have to put into the
> interpreter to get them. As Nicholas Clark and someone else who's name
> I've forgotten[1] mentioned, there are p
On Sat, Sep 15, 2001 at 06:33:18PM +0100, Simon Cozens wrote:
>
> We also need to think about endianness. Urgh.
>
> This is something I ought to seek consensus on. (And possibly a ruling from
> Dan.)
>
> Do we *expect* Parrot bytecode to be portable? My gut reaction would be to
> say no, but I
On Sat, Sep 15, 2001 at 06:33:18PM +0100, Simon Cozens wrote:
> On Sat, Sep 15, 2001 at 06:32:57PM +0100, Philip Kendall wrote:
> > I posted a couple of bodge fixes from this, but I haven't done much in
> > the past couple of days... do we want to use a 32 bit type for reading
> > in bytecode or c
On Sat, Sep 15, 2001 at 06:32:57PM +0100, Philip Kendall wrote:
> I posted a couple of bodge fixes from this, but I haven't done much in
> the past couple of days... do we want to use a 32 bit type for reading
> in bytecode or convert the 32 bit on-disc format into a 64 bit format in
> memory befo
On Sat, Sep 15, 2001 at 04:44:47PM +0100, Simon Cozens wrote:
>
> And segfaults here:
>
> (gdb) run test.pbc
> Starting program: /var/tmp/parrot/test_prog test.pbc
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x120007388 in read_constants_table (program_code=0x11b48) at byteco
On Sat, Sep 15, 2001 at 04:44:47PM +0100, Simon Cozens wrote:
> On Sat, Sep 15, 2001 at 06:44:38PM +0300, Jarkko Hietaniemi wrote:
> > The question is why was it wrong after a fresh checkout? (also in Linux)
>
> No idea. Is make_op_header.pl run? Does op.h contain the #define's?
>
> > Another ob
On Sat, Sep 15, 2001 at 04:44:47PM +0100, Simon Cozens wrote:
> On Sat, Sep 15, 2001 at 06:44:38PM +0300, Jarkko Hietaniemi wrote:
> > The question is why was it wrong after a fresh checkout? (also in Linux)
>
> No idea. Is make_op_header.pl run? Does op.h contain the #define's?
This is eerie--
On Sat, Sep 15, 2001 at 04:44:47PM +0100, Simon Cozens wrote:
> On Sat, Sep 15, 2001 at 06:44:38PM +0300, Jarkko Hietaniemi wrote:
> > The question is why was it wrong after a fresh checkout? (also in Linux)
>
> No idea. Is make_op_header.pl run? Does op.h contain the #define's?
I'll try a new c
On Sat, Sep 15, 2001 at 06:44:38PM +0300, Jarkko Hietaniemi wrote:
> The question is why was it wrong after a fresh checkout? (also in Linux)
No idea. Is make_op_header.pl run? Does op.h contain the #define's?
> Another observation is that after 'rm op.h; make op.h' the thing
> builds but with s
On Sat, Sep 15, 2001 at 06:44:38PM +0300, Jarkko Hietaniemi wrote:
> On Sat, Sep 15, 2001 at 04:35:49PM +0100, Simon Cozens wrote:
> > On Sat, Sep 15, 2001 at 06:18:38PM +0300, Jarkko Hietaniemi wrote:
> > > do { foo [ 0 ] = end ; foo [ 1 ] = set_i_ic ; foo [ 2 ] = set_i ; foo [ 3 ]
>= add_i
On Sat, Sep 15, 2001 at 04:35:49PM +0100, Simon Cozens wrote:
> On Sat, Sep 15, 2001 at 06:18:38PM +0300, Jarkko Hietaniemi wrote:
> > do { foo [ 0 ] = end ; foo [ 1 ] = set_i_ic ; foo [ 2 ] = set_i ; foo [ 3 ] =
>add_i ; foo [ 4 ] = sub_i ; foo [ 5 ] = mul_i ; foo [ 6 ] = div_i ; foo [ 7 ]
Well, I must have checked out at a bad moment since Linux+gcc 2.95.2
is not faring much better:
make test_prog|&head
cc -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I..-c -o interpreter.o interpreter.c
interpreter.c: In function `make_interpreter':
in
On Sat, Sep 15, 2001 at 06:18:38PM +0300, Jarkko Hietaniemi wrote:
> do { foo [ 0 ] = end ; foo [ 1 ] = set_i_ic ; foo [ 2 ] = set_i ; foo [ 3 ] =
>add_i ; foo [ 4 ] = sub_i ; foo [ 5 ] = mul_i ; foo [ 6 ] = div_i ; foo [ 7 ] = ...
Your op.h needs rebuilding. It builds fine on Tru64 here.
17 matches
Mail list logo
