Re: Calling conventions -- easier way?

On Friday 19 October 2001 01:46 pm, Dan Sugalski wrote: > I'm currently leaning either towards returning values in registers > [PSIN][0-4] with the total number of each type in register I0 somehow Order determination of the return values. (Yes, I was the one asking for register windows. Sh

A new language targeted to the parrot assembler...

For a -very- primitive Scheme -> Parrot compiler, see http://216.254.0.2/~jgoff/Files/scheme.tar.gz This is purely proof-of-concept for a much more sophisticated implementation. The current tarball has support for only integer math operators and predicates, although there is minimal support for

Re: chd and ord, v0.2

On Fri, Oct 19, 2001 at 07:21:45PM -0400, James Mastros wrote: > On Sat, 20 Oct 2001, Jarkko Hietaniemi wrote: > > Characters beyond the BMP (aka Plane 0, 0x...0x) were > > introduced in Unicode 3.1 (March 2001), so you are 1.1 versions > > and 2 years late. The current maximum code point

Re: chd and ord, v0.2

On Sat, 20 Oct 2001, Jarkko Hietaniemi wrote: > Characters beyond the BMP (aka Plane 0, 0x...0x) were > introduced in Unicode 3.1 (March 2001), so you are 1.1 versions > and 2 years late. The current maximum code point is 0x10, > so the planes 0..16 are in use (http://www.unicode.org/

[PATCH] Register Window Base Macros

Here is the patch (again) to use the appropriate bitmask determined by Configure for the different register chunks. -- Jason Index: Configure.pl === RCS file: /home/perlcvs/parrot/Configure.pl,v retrieving revision 1.29 diff -u -

Re: chd and ord, v0.2

> both ord and chr only work for characters that fit in the Basic > Multilingual Plane (this shouldn't be a problem until around 2003, when > Unicode 2.0 starts introducing characters above this) Huh? Characters beyond the BMP (aka Plane 0, 0x...0x) were introduced in Unicode 3.1 (Ma

Re: Calling conventions -- easier way?

Dan -- > Ah, but I'd rather do it right the first time than have to redo it later, > especially if the redoing is incompatible with what was done first. ;) I would, too. But I view Jako is being a sort of test bed for what our choices at the Parrot level do to language implementers. So, Jako is

Re: Calling conventions -- easier way?

At 01:55 PM 10/19/2001 -0400, Gregor N. Purdy wrote: >Dan -- > > > >Should we have bsr(i|ic, i|ic), that jumps to $1, with the return > > >address below the $2 arguments? Similarly, should we have ret(i|ic), > > >that rotates the return address out from under $1 arguments and then > >

Re: Calling conventions -- easier way?

On Fri, 19 Oct 2001, Gregor N. Purdy wrote: > Dan -- > FWIW, I'd rather not dedicate registers to special uses at the Parrot > level. Jako reserves [INPS]0 for temporaries, but that is at its > discretion, not dictated by Parrot (and I like it that way :). I was > wishing for separate data and ad

Re: Calling conventions -- easier way?

Dan -- > >Should we have bsr(i|ic, i|ic), that jumps to $1, with the return > >address below the $2 arguments? Similarly, should we have ret(i|ic), > >that rotates the return address out from under $1 arguments and then > >returns to it? > > Nope. For a number of reasons, the big

Re: Calling conventions -- easier way?

On Fri, 19 Oct 2001, Dan Sugalski wrote: > At 01:24 PM 10/19/2001 -0400, Gregor N. Purdy wrote: > >James -- > > > >Should we have bsr(i|ic, i|ic), that jumps to $1, with the return > >address below the $2 arguments? Similarly, should we have ret(i|ic), > >that rotates the return addre

Re: Calling conventions -- easier way?

At 01:24 PM 10/19/2001 -0400, Gregor N. Purdy wrote: >James -- > > > Hey all. I just looked through the changes to jakoc, and I think the > > calling convention is mostly good... except for the return address. > > > > Originaly, I thought that perhaps it'd be good to put the return address > > af

Re: Calling conventions -- easier way?

James -- > Hey all. I just looked through the changes to jakoc, and I think the > calling convention is mostly good... except for the return address. > > Originaly, I thought that perhaps it'd be good to put the return address > after the args on the stack, so that once you've eaten the args, i

cvs commit: parrot/languages/jako jakoc (fwd)

All -- Dan asked me to remove the swap op, since what he really wants is rotate. So, I implemented an initial version of rotate. Here's the log entry: * core.ops: Replaced 'swap()' by 'rotate(i|ic)'. * stacks.c and stacks.h: Removed swap-related functions from my prior commit,

Re: Have I given the big "The Way Strings Should Work" talk?

On Fri, Oct 19, 2001 at 11:52:34AM -0400, Dan Sugalski wrote: > I've given it a few places, but I don't know that I've sent it to > perl6-internals. No, but I can pretty much grasp it by telepathy. Why not write some documentation about it, and then we'll implement it? :) -- Henry, I'm a Regen

Calling conventions -- easier way?

Hey all. I just looked through the changes to jakoc, and I think the calling convention is mostly good... except for the return address. Originaly, I thought that perhaps it'd be good to put the return address after the args on the stack, so that once you've eaten the args, it's in the right pos

Have I given the big "The Way Strings Should Work" talk?

I've given it a few places, but I don't know that I've sent it to perl6-internals. If not, or if I should do it again, let me know. I want to make sure we're all on the same page here. Dan --"it's like this"---

Re: [PATCH] Chr and ord, v0.2

At 11:14 AM 10/19/2001 -0400, James Mastros wrote: >This is a first run at a patch to support the ord and chr opcodes. It >mainly, I'm afraid, serves as an example to show that we need to be able to >transcode out of the native encoding; I have to special-case it several ways >otherwise. >Limita

Re: chr and ord, v0.2

At 09:38 PM 10/18/2001 -0400, James Mastros wrote: >Hey all. > This is my first working version of chr(i, s|sc) and ord(s, i|ic). It's >not nearly as clean as I'd like it. It's a lot more complicated and >low-level then I'd like. It is tested only on my system with INTVAL being a >long. I th

[PATCH] Chr and ord, v0.2

This is a first run at a patch to support the ord and chr opcodes. It mainly, I'm afraid, serves as an example to show that we need to be able to transcode out of the native encoding; I have to special-case it several ways otherwise. Limitations - Ord only works on native strings if they have 8

chr and ord, v0.2

Hey all. This is my first working version of chr(i, s|sc) and ord(s, i|ic). It's not nearly as clean as I'd like it. It's a lot more complicated and low-level then I'd like. It is tested only on my system with INTVAL being a long. I'd be very interested in better tests, or ideas for a better

Re: the handiness of undef becoming NaN (when you want that)

At 03:42 PM 10/17/2001 -0500, David Nicol wrote: >I am implementing a textbook algo in Perl (the textbook has >it written in C++) and have realized that if undef was to >numericize to NaN instead of 0, there are a lot of uninitialization >errors that would get caught. Yup, and it generically bre

[COMMIT] Jako gets real subroutines

All -- I Just committed the following changes. Enjoy. * New stack functions push_entry(), pop_entry() and swap_entry(). The first two exist for the support of the last one. These functions don't care what is in the stack entries. These exist to support the new 'swap' op (se

Re: the handiness of undef becoming NaN (when you want that)

On Wed, Oct 17, 2001 at 03:42:30PM -0500, David Nicol wrote: > > I am implementing a textbook algo in Perl (the textbook has > it written in C++) and have realized that if undef was to > numericize to NaN instead of 0, there are a lot of uninitialization > errors that would get caught. > >

Re: MIPSPro non happy bunny (IRIX64, IP30)

On Thu, 18 Oct 2001, Gregor N. Purdy wrote: > > I believe this will resolve the problem. Too bad the GNU tools didn't > complain at me here when I missed the 'extern'. Oh, well. > This is healthy again. Alex Gough -- That one never has to vary G or introduce any fudge factors in order to fit