At 04:57 PM 11/23/2001 +0100, Bart Lateur wrote:
>On Wed, 21 Nov 2001 13:46:09 -0500, 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 a
On Wed, 21 Nov 2001 13:46:09 -0500, 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 o
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*.
># > >
>#
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
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
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
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
> On Tue, 20 Nov 2001, Ken Fox wrote:
> > It sounds like you want portable byte code. Is that a goal?
> I do indeed want portable packfiles, and I thought that was more then a
> "goal", I thought that was a "requirement". In an ideal world, I want a
> PVM to be intergrated in a webbrowser the sam
On Tue, 20 Nov 2001, Ken Fox wrote:
> It sounds like you want portable byte code. Is that a goal?
I do indeed want portable packfiles, and I thought that was more then a
"goal", I thought that was a "requirement". In an ideal world, I want a
PVM to be intergrated in a webbrowser the same way a JV
On Tue, 2001-11-20 at 12:19, 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
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 can have either mmap'able byte code or portable byte co
On Mon, 2001-11-19 at 19:59, James Mastros wrote:
> Hey all.
> In parellel to splitting out features (yeah, I like that better then
> "platforms" too) (which is going well this time, I think (I'm being a lot
> better about checking against clean checkouts, but having problems
> thinking of a goo
Hey all.
In parellel to splitting out features (yeah, I like that better then
"platforms" too) (which is going well this time, I think (I'm being a lot
better about checking against clean checkouts, but having problems
thinking of a good generic interface for open() and friends), I'm thinking
ab
13 matches
Mail list logo
