On Mon, Sep 10, 2001 at 08:56:52PM -0400, Dan Sugalski wrote:
Nothing should read out of interp_guts.h. That's autogenerated from
opcode_table. Or it was yesterday, but things might've changed. :)
Sorry, but things have changed. This is now where the op number assignments
are stored.
Simon
On Mon, Sep 10, 2001 at 04:04:20PM -0700, Damien Neil wrote:
The following quick-and-dirty patch appears to work. This prefixes
all opcode functions with Parrot_op_. I'd have made the prefix
configurable, but the opcode generation is spread across three
different files.
Oops--that breaks
Damien Neil:
# On Mon, Sep 10, 2001 at 06:58:23PM -0400, Dan Sugalski wrote:
# At 03:52 PM 9/10/2001 -0700, Damien Neil wrote:
# Parrot fails to work in very obscure ways on FreeBSD. After some
# poking around, I tracked the problem to the end op--this appears
# to conflict with something
On Mon, Sep 10, 2001 at 08:48:48PM -0400, Dan Sugalski wrote:
At 04:56 PM 9/10/2001 -0700, Brent Dax wrote:
This patch seems to work on the FreeBSD box I have access to. Now to
figure out what's causing all those 'use of uninitialized value at
assembler.pl line 81' messages...
It's the
On Mon, Sep 10, 2001 at 08:56:52PM -0400, Dan Sugalski wrote:
I'm thinking of writing something to generate a Parrot::Opcode.pm
module, so code doesn't need to parse opcode_table and interp_guts.h.
Sound reasonable?
Yes, please do. I knew we needed one the second time I needed to parse
At 06:02 PM 9/10/2001 -0700, Damien Neil wrote:
On Mon, Sep 10, 2001 at 08:56:52PM -0400, Dan Sugalski wrote:
I'm thinking of writing something to generate a Parrot::Opcode.pm
module, so code doesn't need to parse opcode_table and interp_guts.h.
Sound reasonable?
Yes, please do. I knew
On Monday 10 September 2001 09:27 pm, Dan Sugalski wrote:
Parse opcode_table. Sync up your source first, there have been some
changes to the format in the last few hours.
I'll wait on those changes before delving back into the assembler for the
simplified instruction handling.
--
Bryan C.
