[RFC] IMCC pending changes request for comments
Melvin Smith
maintainability,
I'm considering the following changes; well number (1) is already decided,
but I need feedback from compiler maintainers before doing so.
1) Currently typenames are not checked except with 'new <classname>'
C<.local <type> identifier> and C<.param <type> identifier> both assume
that anything for type other than (int|float|string) is a PMC. This was
not intended to be permanent behaviour, but I never added the proper
checking.
Patching my local copy has uncovered a few places where people have
used the undocumented "feature". The downside to the "feature" is lazy
error
checking and confusing messages from IMCC that have nothing to do with
the error.
New hackers write ".local integer i" and then waste time wondering why
IMCC keeps saying "unknown parrot op foo_p_p" because integer really
isn't a type, what they meant was (int).
I see in a lot of tests the use of C<var> and C<object> as types in
IMC code.
I believe Jako and Perl6 compilers use C<object> as well.
I'm ok with just adding those 2 as aliases for C<pmc> register, but I only
want to add aliases that are appropriate. The feature of defaulting to PMC
is going away, so get your requests in now. I also want to keep the
aliases to a minimum.
From now on any declarations in IMCC will require either an IMC
register type
or a predefined classname or PMC. Else, just use C<pmc> to mean generic.
Comments from the compiler maintainers (especially the Perl, Forth &
Jako guys)?
2) In the absence of some sort of return instruction, subs currently just
run off the end of their code and continue merrily. This feature really
isn't useful as far as I can see because it is not supported to assume
any ordering between compilation unit, which a sub _is_.
It is easier to just assume a sub returns by the active convention.
I'd like to just be able to write void subs as:
.sub _foo
print "hello\n"
.end
3) Strict prototyping mode shortcut (backwards compatible of course):
As usual, shortcuts are for hand-hackers, but its easier to debug
either way.
.sub _baz (pmc p, int i)
...
.end
Same as:
.sub _baz protoyped
.param pmc p
.param int i
...
.end
4) No implicit global labels with the label :== IDENTIFIER COLON syntax.
Currently labels beginning in _ are global. I'd like to remove the implicit
aspect of it.
sub definitions will create global labels, as might other directives, but
there will no longer be
a requirement that subs start with _ in order to get the correct behaviour.
We might still want global labels declarable, somehow, so I'm open to
suggestions, but
I don't see the need, really.
A couple of these suggestions might seem uncalled for. Honestly I am trying to
tighten up things and officialize IMCC behaviour so expect more soon.
Some changes might cause minor breakage to existing compilers but that is just
growing pain.
-Melvin
Steve Fink
>
> 1) Currently typenames are not checked except with 'new <classname>'
I would vote for no aliases at all. I propagated the existing uses of
".local object" in the Perl6 compiler and introduced several more
uses, but that was only because I wasn't sure at the time whether it
was intended to (now or in the future) have slightly different
semantics. It wasn't, I'm pretty sure. So I'll switch Perl to using
'pmc' if you make the change.
> 2) In the absence of some sort of return instruction, subs
> currently just
> run off the end of their code and continue merrily. This
> feature really
> isn't useful as far as I can see because it is not supported to
> assume
> any ordering between compilation unit, which a sub _is_.
>
> It is easier to just assume a sub returns by the active
> convention.
>
> I'd like to just be able to write void subs as:
>
> .sub _foo
> print "hello\n"
> .end
Do you really want to generate the extra unused code at the end of all
the subroutines? I don't think you want to autodetect whether the code
is guaranteed to return.
How about adding a return value specification if you want this
generated automatically:
.sub _gorble () returns (int r)
r = 5
.end
.sub _foo () returns void
print "hello\n"
.end
(This assumes you're creating implicit locals for return values as
well as parameters, as you described in #3.)
> 3) Strict prototyping mode shortcut (backwards compatible of
> course):
> As usual, shortcuts are for hand-hackers, but its easier to
> debug either way.
>
> .sub _baz (pmc p, int i)
> ...
> .end
>
> Same as:
>
> .sub _baz protoyped
> .param pmc p
> .param int i
> ...
> .end
Sounds good to me; debugging the Perl6 sub calling stuff would have
been easier if I didn't have to read so much code to figure out what
was going on.
Melvin Smith
>On Dec-02, Melvin Smith wrote:
> >
> > 1) Currently typenames are not checked except with 'new <classname>'
>
>I would vote for no aliases at all. I propagated the existing uses of
>".local object" in the Perl6 compiler and introduced several more
>uses, but that was only because I wasn't sure at the time whether it
>was intended to (now or in the future) have slightly different
That would be my fault for not providing documentation with the compiler.
>Do you really want to generate the extra unused code at the end of all
>the subroutines? I don't think you want to autodetect whether the code
>is guaranteed to return.
Good point. Its easy to detect returns if the code uses high level IMC
directives, but in cases where it is all low-level PASM, it could get
a little troublesome. It would also add a few dead instructions here and there.
Nix that idea.
> .sub _gorble () returns (int r)
> r = 5
> .end
We may need something like this anyway for prototyped subs.
Currently we are only prototyping the parameters, not the returns;
not quite orthogonal.
Thanks for the comments,
-Melvin
Leopold Toetsch
> 1) Currently typenames are not checked except with 'new <classname>'
As Dan layed out WRT PMC enums, we might have to defer type checking to
runtime. That is for core PMCs we do strict type checking, other types
get resolved at runtime.
> C<.local <type> identifier> and C<.param <type> identifier> both assume
> that anything for type other than (int|float|string) is a PMC.
Yep. Some remarks:
.local <type> ident
collides with the macro syntax for local labels. So when doing something
here I'd resolve that conflict too and allow only:
.sym <type> ident # <type> ::= int|float|string|pmc
I'm not sure but:
.newsym <type> ident
could be handy too, compiling to new Px, <.Type>
And while at it, imcc should know of lexicals. E.g. when the register
allocator is out of regs, spilling lexicals to an array isn't necessary
- they already have a permanent store in the lexical pad.
> 2) In the absence of some sort of return instruction, subs currently just
> run off the end of their code and continue merrily.
Steve already did propose to use return decls for this. Done that, we
can toss half of pcc.c and use the symmetry of call and return.
> 3) Strict prototyping mode shortcut (backwards compatible of course):
> .sub _baz (pmc p, int i)
Fine.
> 4) No implicit global labels with the label :== IDENTIFIER COLON syntax.
That's not easy. While its clear that a .sub is global there are more.
PASM mode comes to my mind and some nasty one: imcc/t/syn/eval_3 ff.
> -Melvin
leo
Melvin Smith
>Melvin Smith <mrjol...@mindspring.com> wrote:
>
> > 1) Currently typenames are not checked except with 'new <classname>'
>
>As Dan layed out WRT PMC enums, we might have to defer type checking to
>runtime. That is for core PMCs we do strict type checking, other types
>get resolved at runtime.
All I care is that IMCC checks that it is a valid class if the class is named,
otherwise use 'pmc' to defer checking but at least use the correct register
set.
Even given what Steve said about no aliases, I'm considering keeping an
"object" alias to "pmc" for potential future cases where semantics may
diverge.
> > C<.local <type> identifier> and C<.param <type> identifier> both
> assume
> > that anything for type other than (int|float|string) is a PMC.
>
>Yep. Some remarks:
>
> .local <type> ident
>
>collides with the macro syntax for local labels. So when doing something
>here I'd resolve that conflict too and allow only:
>
> .sym <type> ident # <type> ::= int|float|string|pmc
Since macros are the less common case I'll have a look to see which
needs to change to resolve the conflict, macros or IMC.
>I'm not sure but:
>
> .newsym <type> ident
>
>could be handy too, compiling to new Px, <.Type>
Ok.
>And while at it, imcc should know of lexicals. E.g. when the register
>allocator is out of regs, spilling lexicals to an array isn't necessary
>- they already have a permanent store in the lexical pad.
The same thing goes for globals. I've been trying to get my head around
both lately.
> > 4) No implicit global labels with the label :== IDENTIFIER COLON syntax.
>
>That's not easy. While its clear that a .sub is global there are more.
>PASM mode comes to my mind and some nasty one: imcc/t/syn/eval_3 ff.
I need to think on this one some more as well.
Thanks for the comments.
-Melvin
Gordon Henriksen
> At 07:59 PM 12/2/2003 -0800, Steve Fink wrote:
>
>> Do you really want to generate the extra unused code at the end of all
>> the subroutines? I don't think you want to autodetect whether the code
>> is guaranteed to return.
>
> Good point. Its easy to detect returns if the code uses high level IMC
> directives, but in cases where it is all low-level PASM, it could get a
> little troublesome. It would also add a few dead instructions here and
> there. Nix that idea.
Maybe just pad the end of the compilation unit with the opcode
equivalent of PMCNULL, to fire an exception rather than having undefined
behavior?
—
Gordon Henriksen
mali...@mac.com
Jeff Clites
> At 07:59 PM 12/2/2003 -0800, Steve Fink wrote:
>> On Dec-02, Melvin Smith wrote:
>
>> Do you really want to generate the extra unused code at the end of all
>> the subroutines? I don't think you want to autodetect whether the code
>> is guaranteed to return.
>
> Good point. Its easy to detect returns if the code uses high level IMC
> directives, but in cases where it is all low-level PASM, it could get
> a little troublesome. It would also add a few dead instructions here
> and there.
> Nix that idea.
You could take the approach of putting in the return code unless you
can tell for certain that it couldn't be reached, the idea being that
this would lead to some unreachable code at first but as the compiler
(or optimizer) becomes more sophisticated in its flow analysis this
would gradually improve over time.
JEff