[Patch] function pointer handling

This patch removes unnecessary function pointer conversions (which have undefined behavior in ANSI C). This gets rid of several warnings encountered with the lcc compiler and isolates our function pointer misbehavior to only the jit code. --Josh Index: core.ops =

more cleanups

This gets it very close to building on tcc, with just key.c causing problems due to some KEY_PAIR* / KEY_PAIR** mixups. My brain can't quite wrap around what's going on there :) This patch fixes a few places where duplicate variable names and invalid return values were occurring in the pmc's

Re: [Patch] Some de-linting [APPLIED]

At 12:21 AM -0500 2/13/02, Josh Wilmes wrote: >I've tweaked the "lint" target somewhat and fixed a few of the things it >finds. Attaching the patch as well as the current lint output. Applied, thanks. -- Dan --"it's l

Your mission...

If you choose to accept it, is to dig out the computed goto and switch runops cores from the archives, dust 'em off and get them up to snuff with the current sources. Takers, anone? -- Dan --"it's like this"-

Interpreter memory allocation

Okay, I've checked in the final bits needed to do memory allocations and such within Parrot. Here's the scoop. For memory you need to allocate from the system, use mem_sys_allocate. Takes a size, returns a void pointer to the allocated memory. Free it up with mem_sys_free, or it leaks. To res

Should I post stuff like this?

Is this annoying, or helpful? This is one thing that turned up in a google search for "librep forth engine". http://www.technomagi.com/links/design.html> -- mailto: (Karl M. Hegbloom) [EMAIL PROTECTED] Free the Software http://www.debian.org/social_contract http://www.microsharp.com ph

Forth engine techniques for faster byte code interpreter. (indirect threaded interpreter)

The "librep" virtual machine uses a technique taken from Forth engines called "indirect threading". That's not threading as in "multithreading" or "pthreads"... You'll have to read about it for yourselves, since I've not the knowledge, time, or the inclination to write a long essay on the s

Re: [PATCH] Fix calculation of byte code end

On Wed, Feb 13, 2002 at 10:43:38PM -0500, Jason Gloudon wrote: > The type changes in struct Packfile break the pointer math used in a few places > to calculate the address of the end of the loaded byte code. This causes > segfaults in build_asm in jit.c when using -j. It also breaks the bounds > c

Re: PMCs, setting, and suchlike things

Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 3:53 PM + 2/14/02, Dave Mitchell wrote: > >My outstanding niggle is when a typed variable is undef. I guess we > >need a generic Perl_Undef_But_Typed vtable type, which behaves mostly > >like the PerlUndef type, but saves a pointer to its 'real' vta

Re: PMCs, setting, and suchlike things

At 3:53 PM + 2/14/02, Dave Mitchell wrote: >My outstanding niggle is when a typed variable is undef. I guess we >need a generic Perl_Undef_But_Typed vtable type, which behaves mostly >like the PerlUndef type, but saves a pointer to its 'real' vtable in >self->data or whatever. When it's assign

Re: PMCs, setting, and suchlike things

Alex Gough

Re: PMCs, setting, and suchlike things

At 3:48 PM + 2/14/02, Alex Gough wrote: >On Thu, 14 Feb 2002, Melvin Smith wrote: > >> >my Dog $spot = Dog.new("waggly tail"); >> >$spot = Cat.new(); >> >> In this case all types are known at compile time. Why would >> we relegate this to a runtime vtable check or bit flag? > >There's no r

Re: PMCs, setting, and suchlike things

Dan Sugalski <[EMAIL PROTECTED]> wrote: > There's a flag in the flags field to mark the PMC as a permanent type > or not. It's insufficient for "Type X or child of X" things, though. > > >Or to put it another way, is the type of a PMC determined purely by > >it's current vtable pointer, and if s

Re: PMCs, setting, and suchlike things

On Thu, 14 Feb 2002, Melvin Smith wrote: > >my Dog $spot = Dog.new("waggly tail"); > >$spot = Cat.new(); > > In this case all types are known at compile time. Why would > we relegate this to a runtime vtable check or bit flag? There's no reason to suspect that Dog::new will actually return a Dog

Re: PMCs, setting, and suchlike things

Dan Sugalski <[EMAIL PROTECTE

Re: PMCs, setting, and suchlike things

At 11:46 AM + 2/14/02, Dave Mitchell wrote: >Dan Sugalski <[EMAIL PROTECTED]> wrote: >> Right, for typed variables. Most variables (i.e. anything you >> declared with a plain "my $foo" or "our @bar") are untyped and can >> change their types as needed. >> >> If you did: >> >> my $foo;

Re: PMCs, setting, and suchlike things

On Thu, Feb 14, 2002 at 02:10:20PM +, Dave Mitchell wrote: > 2. If so, how do we distinguish between two PMCs, both of whose > vtable pointers currently point to the 'Dog' vtable, but one of whom has > been delared as type Dog and so should never have it's vatble pointer > updated, and the oth

Re: PMCs, setting, and suchlike things

Alex Gough <[EMAIL PROTECTED]> wrote: > On Thu, 14 Feb 2002, Dave Mitchell wrote: > > > $foo would first be a Dog, then a FireHydrant. When it changed to a > > > FireHydrant the previous contents would get blown away. > > > > Hmmm - how do we distinguish between a plain scalar that is temporarily

Re: PMCs, setting, and suchlike things

On Thu, 14 Feb 2002, Dave Mitchell wrote: > > $foo would first be a Dog, then a FireHydrant. When it changed to a > > FireHydrant the previous contents would get blown away. > > Hmmm - how do we distinguish between a plain scalar that is temporarily > typed, and a 'proper' permanently-typed scala

Re: PMCs, setting, and suchlike things

Dan Sugalski <[EMAIL PROTECTED]> wrote: > Right, for typed variables. Most variables (i.e. anything you > declared with a plain "my $foo" or "our @bar") are untyped and can > change their types as needed. > > If you did: > > my $foo; > $foo = Dog.new(); > $foo = FireHydrant.new();