At 11:57 AM -0500 11/14/03, Gordon Henriksen wrote:
Melvin Smith <[EMAIL PROTECTED]> wrote:
The easy situation is when argument counts change, but the
hard situation is
when semantics have changed. In that case we have to have some
sort of version requirement in the bytecode.
Best practice I'v
ant load. It can
be checked by the callee with a single string compare instruction (if
the vararg list is actually static). It's easy to reflect, too.
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
> -Original Message-
> From: Dan Sugalski [mailto:[E
Melvin Smith <[EMAIL PROTECTED]> wrote:
> The easy situation is when argument counts change, but the
> hard situation is
> when semantics have changed. In that case we have to have some
> sort of version requirement in the bytecode.
Best practice I've seen for this is to have a library advertise
Does C++ style 'name mangling' have any relevance here?
I also had some half-baked thought that a HLL could generate
two entry points for a prototyped sub...
one with the mangled name encoding the expected arguments and types
(p/s/i) for high-speed no-questions-asked-nothing-checked use, and...
All~
This might have already been suggested, or their might be a good reason
why not to do this but here is my idea.
Why not have unprotyped calls pass an array in P5 and a hash in P6? The
array can hold the first n positional arguments (possibly 0, for which
Null could be passed to avoid cre
At 05:23 PM 11/14/2003 +0100, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... It happens, in some cases a *lot*. This is perl,
> python, and ruby we're talking about, where changing the definition of a
> sub is as trivial as a reference assignment into a global hash. It's easy,
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> ... It happens, in some cases a *lot*. This is perl,
> python, and ruby we're talking about, where changing the definition of a
> sub is as trivial as a reference assignment into a global hash. It's easy,
> people do it. Often, in some cases. (Heck, I've do
On Fri, 14 Nov 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > I've seen it with some depressing regularity over the years. It generally
> > takes the form of an upgrade to a library that breaks existing
> > executables, something we're going to have to deal with as we
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I've seen it with some depressing regularity over the years. It generally
> takes the form of an upgrade to a library that breaks existing
> executables, something we're going to have to deal with as we're looking
> to encourage long-term use of bytecode-c
On Thu, 13 Nov 2003, Pete Lomax wrote:
> I'd be interested to see what sort of signature changes between
> compile and runtime you think are likely to happen, as I have to admit
> I have never encountered such a beast. Doesn't that force
> non-prototyped calls?
I've seen it with some depressing r
Pete Lomax <[EMAIL PROTECTED]> wrote:
> On Fri, 14 Nov 2003 08:12:26 +0100, Leopold Toetsch <[EMAIL PROTECTED]>
> wrote:
>>> _u_fred:
>>> I5=P3[1]
>>> S5=P3[2]
>>> _fred:
>>
>>There is no P3[] involved. "_fred" just starts with whatever is in
>>regis
On Fri, 14 Nov 2003 08:12:26 +0100, Leopold Toetsch <[EMAIL PROTECTED]>
wrote:
>> _u_fred:
>> I5=P3[1]
>> S5=P3[2]
>> _fred:
>
>There is no P3[] involved. "_fred" just starts with whatever is in
>registers I5/S5.
Yes, "_fred" wades straight in, e
Pete Lomax <[EMAIL PROTECTED]> wrote:
> Hi,
> New to this list, so please excuse any glaring stupidity.
Welcome here.
> I'd be interested to see what sort of signature changes between
> compile and runtime you think are likely to happen, as I have to admit
> I have never encountered such a beast.
Hi,
New to this list, so please excuse any glaring stupidity.
I've been thinking about porting a small language to run on parrot,
and the call/return conventions. This is what I plan to do, at least
for my local routines. I'll follow the rules a bit more closely for
globals and external calls (bu
On Thu, 13 Nov 2003, Steve Fink wrote:
> I'm getting a little confused about what we're arguing about. I will
> take a stab at describing the playing field, so people can correct me
> where I'm wrong:
The current big issue is whether non-PMC parameter types get counts.
There's not really anything
Steve Fink wrote:
Prototyped functions: there are a range of possibilities.
2. Everything gets PMC-ized and passed in P5..P15+P3. Ix is an arg
count for the number of args passed in P5..P15. P3 is empty if
argcount <= 11 (so you have to completely fill P5..P15 before
putting stuff in
I'm getting a little confused about what we're arguing about. I will
take a stab at describing the playing field, so people can correct me
where I'm wrong:
Nonprototyped functions: these are simpler. The only point of
contention here is whether args should be passed in P5..P15,
overflowing into P3
"overflow array" of PMCs ought to be the general case,
not just the exceptional case.
_
From: Leopold Toetsch
Subject: Re: Calling conventions. Again
Date: 2003-11-12 09:48:35 PST
Dan Sugalski <[EMAIL PROTECTED]> wrote:
[ I,N,S counts ]
> 6) Note that
On Wed, 12 Nov 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> [ I,N,S counts ]
>
> > 6) Note that non-PMC counts only need to be filled in if we're marked
> > "prototyped"
>
> Again, this is IMHO unneeded or at least suboptimal. The caller has 3
> more instructions. And
Dan Sugalski <[EMAIL PROTECTED]> wrote:
[ I,N,S counts ]
> 6) Note that non-PMC counts only need to be filled in if we're marked
> "prototyped"
Again, this is IMHO unneeded or at least suboptimal. The caller has 3
more instructions. And what should the assembler generate for the
callee?
if I
'Kay, here's the proposed changes:
1) Return conventions die. Chopped entirely out of the list
2) The hash for the sub/method name goes, though we may later regret that.
3) The return type info that was in I3 is gone. It's really "calling
context" and I think we may need a better way for things in
21 matches
Mail list logo
