At 08:43 PM 11/19/2001 -0500, brian wheeler wrote:
>On Mon, 2001-11-19 at 19:59, James Mastros wrote:
> > I propose that we make INTVAL and opcode_t the same size, and gaurrenteed
> > to be able to hold a void*.
> >
>
>Seems reasonable to me, since jsr and jump are slated to use an I
>register to
At 12:19 PM 11/20/2001 -0500, Ken Fox wrote:
>James Mastros wrote:
> > In byteswapping the bytecode ...
> >
> > I propose that we make INTVAL and opcode_t the same size, and gaurrenteed
> > to be able to hold a void*.
>
>It sounds like you want portable byte code. Is that a goal? It seems like
>we
'Kay, here's the list:
*) I'm adding a CHEATS_TO_BE_FIXED file that holds notes on all cheats that
need fixing. (Like the hand-rolling of faked PMCs in the newinterp opcode)
It's OK to cheat if it's noted here and the cheat can be replaced with
non-cheat code later. (If, for example, you need
Dan Sugalski:
# At 08:43 PM 11/19/2001 -0500, brian wheeler wrote:
# >On Mon, 2001-11-19 at 19:59, James Mastros wrote:
# > > I propose that we make INTVAL and opcode_t the same size,
# and gaurrenteed
# > > to be able to hold a void*.
# > >
# >
# >Seems reasonable to me, since jsr and jump are sl
On Wed, 21 Nov 2001, Dan Sugalski wrote:
> Nah, using an I register as a host-machine-address for jumps doesn't argue
> for sizeof(INTVAL) >= sizeof(void *). Instead, it argues that the design
> that uses an int as an absolute address is wrong.
>
> I'm going to rewrite the docs and ops to use a
Okay, we're going to start allowing opcode names to have underscores in
'em, and I think we should stomp out the specific opcodes. (I.e set_i goes,
but set stays)
Anyone care to take this on? The .ops parsing code's gotten rather more
complex since the last time I touched it... :)
At 11:35 AM 11/21/2001 -0800, Brent Dax wrote:
>Dan Sugalski:
># At 08:43 PM 11/19/2001 -0500, brian wheeler wrote:
># >On Mon, 2001-11-19 at 19:59, James Mastros wrote:
># > > I propose that we make INTVAL and opcode_t the same size,
># and gaurrenteed
># > > to be able to hold a void*.
># > >
>#
The attached file is a proposed PMC test suite.
Now, of course, PMCs aren't implemented yet, but this will give us a
test suite to validate PMCs against behavior once it's been fully
specified. The enclosed file tests set/get of PMC variables and the
basic operations in almost all combinations. F
Jeff G wrote:
Erps, forgot to attach file apparently. File now attached.
> The attached file is a proposed PMC test suite.
>
> Now, of course, PMCs aren't implemented yet, but this will give us a
> test suite to validate PMCs against behavior once it's been fully
> specified. The enclosed file t
Previous comments apply here. I'm also making the necessary
modifications to link in vtable_ops locally.
-Jeff
<[EMAIL PROTECTED]>
10 matches
Mail list logo