[CVS ci] exit opcode
Leopold Toetsch
- B<exit>(in INT) throws an exception with severity C<EXCEPT_exit> and
the given exit status.
- the system itself doesn't through such an exception on runloop exit
yet, this would need classifying exception handlers, so that not
arbitrary user handlers would catch this exception, and some rework to
print profiling/debug code.
I'd like to change the startup parameters too: move the ARGV array from
P0 to P5. This would allow main to be:
.pcc_sub _main prototyped
.param SArray ARGV
.local int ARGC
ARGC = ARGV
...
leo
Jos Visser
> I'd like to change the startup parameters too: move the ARGV array from
> P0 to P5. This would allow main to be:
>
> .pcc_sub _main prototyped
> .param SArray ARGV
> .local int ARGC
> ARGC = ARGV
> ...
This seems a quite logical thing to do (to me)...
++Jos.nl
--
ek is so lug jy vlieg deur my
sonder jou is ek sonder patroon
"Breyten Breytenbach"
Brent Dax
# I'd like to change the startup parameters too: move the ARGV array
from
# P0 to P5.
Agreed on my end, at least--though I suspect the approval you really
need is Dan's. I'll let you apply this when he does.
--Brent Dax <br...@brentdax.com>
Perl and Parrot hacker
"Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna
set myself on fire to prove it."
Index: embed.c
===================================================================
RCS file: /cvs/public/parrot/embed.c,v
retrieving revision 1.86
diff -u -r1.86 embed.c
--- embed.c 28 Aug 2003 15:26:21 -0000 1.86
+++ embed.c 29 Aug 2003 15:17:38 -0000
@@ -269,7 +269,7 @@
userargv = pmc_new_noinit(interpreter, enum_class_SArray);
/* immediately anchor pmc to root set */
- interpreter->pmc_reg.registers[0] = userargv;
+ interpreter->pmc_reg.registers[5] = userargv;
VTABLE_set_pmc_keyed_int(interpreter, interpreter->iglobals,
(INTVAL)IGLOBALS_ARGV_LIST, userargv);
VTABLE_init(interpreter, userargv);
Dan Sugalski
> I have checked in a small change:
> - B<exit>(in INT) throws an exception with severity C<EXCEPT_exit> and
> the given exit status.
I think we might want to go a little further than this, but it's fine for
now. We can extend it with B<exit>(in PMC) later.
> - the system itself doesn't through such an exception on runloop exit
> yet, this would need classifying exception handlers, so that not
> arbitrary user handlers would catch this exception, and some rework to
> print profiling/debug code.
>
> I'd like to change the startup parameters too: move the ARGV array from
> P0 to P5. This would allow main to be:
Sure, go for it. We can revisit which things go where as well, sinc ewe
may have to pass in other htings, like IO handles and such.
Dan
Leopold Toetsch
> Leopold Toetsch:
> # I'd like to change the startup parameters too: move the ARGV array
> from
> # P0 to P5.
>
> Agreed on my end, at least--though I suspect the approval you really
> need is Dan's. I'll let you apply this when he does.
Thanks.
> - interpreter->pmc_reg.registers[0] = userargv;
> + interpreter->pmc_reg.registers[5] = userargv;
Plus all usage of P0 at program start in examples and P6C ;-)
leo
Leopold Toetsch
> yOn Fri, 29 Aug 2003, Leopold Toetsch wrote:
>> I have checked in a small change:
>> - B<exit>(in INT) throws an exception with severity C<EXCEPT_exit> and
>> the given exit status.
> I think we might want to go a little further than this, but it's fine for
> now. We can extend it with B<exit>(in PMC) later.
,--[ core.ops ]----------------------------------------------------------
| =item B<exit>(in INT)
|
| Exit the interpreter with exit_status $1. If you want to communicate an
| extended exit status, create an exception with severity B<EXCEPT_exit>
| and throw it.
`------------------------------------------------------------------------
For the rare? cases, that more then a single "int exit_status" is needed,
you need a PMC anyway for your proposed opcode. This should work already
now: create the exception PMC as above, set "_message" property and
"_type" (exit status) -> message gets printed before exiting.
>> I'd like to change the startup parameters too: move the ARGV array from
>> P0 to P5. This would allow main to be:
> Sure, go for it. We can revisit which things go where as well, sinc ewe
> may have to pass in other htings, like IO handles and such.
I think most of that stuff should be done by the (new) interpreter->clone()
vtable. "man 2 clone /CLONE_FILES" and such.
> Dan
leo
K Stol
----- Original Message -----
From: "Jos Visser" <jo...@osp.nl>
To: "Leopold Toetsch" <l.to...@nextra.at>
Cc: "P6I" <perl6-i...@perl.org>
Sent: Friday, August 29, 2003 4:35 AM
Subject: Re: [CVS ci] exit opcode
> On Fri, Aug 29, 2003 at 01:29:18PM +0200 it came to pass that Leopold
Toetsch wrote:
> > I'd like to change the startup parameters too: move the ARGV array from
> > P0 to P5. This would allow main to be:
> >
> > .pcc_sub _main prototyped
> > .param SArray ARGV
> > .local int ARGC
> > ARGC = ARGV
> > ...
>
> This seems a quite logical thing to do (to me)...
>
Also, this way a Parrot program is somewhat like a subroutine call from the
shell (just like in C : main() ). I occurred to me that one could do the
exact same thing when returning to the shell (which means the Parrot program
exits: "end" ). (does anyone agree?)
It *then* occurred to me that this returning to the shell (or exiting the
program, whatever name you'd call it) could be written as:
.pcc_sub _main prototyped # something like
.param SArray ARGV # int main(int argc, char *argv[])
.local int ARGC # {
ARGC = ARGV #
#
# do your stuff here
#
#
$I0 = 0 #
.pcc_begin_return #
.return $I0; # return 0; /* return to
shell */
.pcc_end_return # }
.end
(I don't know for sure if I got the syntax right)
Just an idea.
Klaas-Jan
Leopold Toetsch
> $I0 = 0 #
> .pcc_begin_return #
> .return $I0; # return 0; /* return to
> shell */
> .pcc_end_return # }
> .end
> Just an idea.
Good one. So in "main" the return statement can translate to "exit_ic?"
then. How do we tell, what is "main"? Just the entry label is "_main:":
.pcc_sub _main prototyped # only one "_main" allowed like in C
> Klaas-Jan
leo
K Stol
----- Original Message -----
From: "Leopold Toetsch" <l...@toetsch.at>
To: "K Stol" <k...@home.nl>
Cc: <perl6-i...@perl.org>
Sent: Sunday, August 31, 2003 4:52 AM
Subject: Re: [CVS ci] exit opcode
good point. Generally, I don't like exceptions or special cases in code, or
implicit
rules, but because most compilers will emit a "main" sub first, one could
say this should be
the ".pcc_sub _main prototyped" sub.
This is not *that* ugly, just look at C, for example. Any C program should
have a "main", so
it's not that strange to have a special 'purpose sub'.
Also, (I just realize while typing this), how does IMCC decide where to
start executing? Is it just at the first sub it sees?
Another thought: (I assume "exit_ic" is a special op for exiting the
interpreter?)
isn't it possible to *not* use an "exit_ic" op, but just do a "return"?
I know a PASM file should end with "end", but somehow it would be nice to
just do a "return", and this return op will return to the calling procedure,
which happens to be the Parrot interpreter.
Klaas-Jan
Leopold Toetsch
> From: "Leopold Toetsch" <l...@toetsch.at>
>> .pcc_sub _main prototyped # only one "_main" allowed like in C
> This is not *that* ugly, just look at C, for example. Any C program should
> have a "main", so
> it's not that strange to have a special 'purpose sub'.
I think as C can live with that we can too ;-)
> Also, (I just realize while typing this), how does IMCC decide where to
> start executing? Is it just at the first sub it sees?
Currently imcc doesn't do anything special: It just emits the code one
compilation unit after the other. Execution starts at the first
statement of the first unit.
But with the constant Sub PMC in the packfile execution could start
at "_main" then.
> Another thought: (I assume "exit_ic" is a special op for exiting the
> interpreter?)
Its the internal notation of the C<exit> opcode taking an INT argument.
> isn't it possible to *not* use an "exit_ic" op, but just do a "return"?
> I know a PASM file should end with "end", but somehow it would be nice to
> just do a "return", and this return op will return to the calling procedure,
> which happens to be the Parrot interpreter.
Sure. An empty return block (one without the explicit ".return 0"
directive would boil down to just C<end>. I'm not sure yet, if the
interpreter itself should through a SystemExit exception. Its probably
not necessary. Languages like Python that need it, can emit C<exit 0> to
get the desired behavior.
> Klaas-Jan
leo
K Stol
----- Original Message -----
From: "Leopold Toetsch" <l...@toetsch.at>
To: "K Stol" <k...@home.nl>
Cc: <perl6-i...@perl.org>
Sent: Sunday, August 31, 2003 7:43 AM
Subject: Re: [CVS ci] exit opcode
> K Stol <k...@home.nl> wrote:
>
> > From: "Leopold Toetsch" <l...@toetsch.at>
> >> .pcc_sub _main prototyped # only one "_main" allowed like in C
>
> > This is not *that* ugly, just look at C, for example. Any C program
should
> > have a "main", so
> > it's not that strange to have a special 'purpose sub'.
>
> I think as C can live with that we can too ;-)
>
:-) IMHO, yes
> > Also, (I just realize while typing this), how does IMCC decide where to
> > start executing? Is it just at the first sub it sees?
>
> Currently imcc doesn't do anything special: It just emits the code one
> compilation unit after the other. Execution starts at the first
> statement of the first unit.
> But with the constant Sub PMC in the packfile execution could start
> at "_main" then.
I couldn't follow the constant Sub PMC thread (didn't understand, maybe a
WTHI subject?).
>
> > Another thought: (I assume "exit_ic" is a special op for exiting the
> > interpreter?)
>
> Its the internal notation of the C<exit> opcode taking an INT argument.
Oh yaa, I forgot: exit_integer-constant, ic
>
> > isn't it possible to *not* use an "exit_ic" op, but just do a "return"?
> > I know a PASM file should end with "end", but somehow it would be nice
to
> > just do a "return", and this return op will return to the calling
procedure,
> > which happens to be the Parrot interpreter.
>
> Sure. An empty return block (one without the explicit ".return 0"
> directive would boil down to just C<end>. I'm not sure yet, if the
> interpreter itself should through a SystemExit exception. Its probably
> not necessary. Languages like Python that need it, can emit C<exit 0> to
> get the desired behavior.
It sounds kinda odd to have an exception while exiting is quite a normal
action. It's just an op being executed with expected behaviour. Kinda weird
to call it an exception (or throw one for that matter).
>
> > Klaas-Jan
>
> leo
>
Leopold Toetsch
> From: "Leopold Toetsch" <l...@toetsch.at>
>> But with the constant Sub PMC in the packfile execution could start
>> at "_main" then.
> I couldn't follow the constant Sub PMC thread (didn't understand, maybe a
> WTHI subject?).
The PIR assembler inside Parrot generates one entry per ".pcc_sub" in
the constant packfile segment. As we have strings, numbers, and keys in
the constant table, now there are PMCs too.
A constant Sub PMC has label, sub entry offset, and end offset as
information. When the constant table gets constructed at packfile load
time, a Sub PMC is created and finally the offset converted to the
absolute address, where the Sub happened to be loaded in memory.
Also the name of the Sub (the label) is put into the interpreter's
global stash with the Sub as value.
find_global P1, "_sub"
I0 = P1
is the same as
I0 = addr "_sub" # set_addr
for subroutines known at compile time. The former works for subroutines
too, that got loaded later with the C<load_bytecode> opcode.
> It sounds kinda odd to have an exception while exiting is quite a normal
> action. It's just an op being executed with expected behaviour. Kinda weird
> to call it an exception (or throw one for that matter).
The C<exit> can happen deeply inside some called subs. The exception
can be caught e.g. in main, to do some cleanup before really shutting
down. Makes sense to me.
leo
K Stol
----- Original Message -----
From: "Leopold Toetsch" <l...@toetsch.at>
To: "K Stol" <k...@home.nl>
Cc: <perl6-i...@perl.org>
Sent: Sunday, August 31, 2003 5:27 PM
Subject: Re: [CVS ci] exit opcode
> K Stol <k...@home.nl> wrote:
>
> > From: "Leopold Toetsch" <l...@toetsch.at>
> >> But with the constant Sub PMC in the packfile execution could start
> >> at "_main" then.
>
> > I couldn't follow the constant Sub PMC thread (didn't understand, maybe
a
> > WTHI subject?).
>
> The PIR assembler inside Parrot generates one entry per ".pcc_sub" in
> the constant packfile segment. As we have strings, numbers, and keys in
> the constant table, now there are PMCs too.
>
> A constant Sub PMC has label, sub entry offset, and end offset as
> information. When the constant table gets constructed at packfile load
> time, a Sub PMC is created and finally the offset converted to the
> absolute address, where the Sub happened to be loaded in memory.
> Also the name of the Sub (the label) is put into the interpreter's
> global stash with the Sub as value.
>
> find_global P1, "_sub"
> I0 = P1
>
> is the same as
>
> I0 = addr "_sub" # set_addr
>
> for subroutines known at compile time. The former works for subroutines
> too, that got loaded later with the C<load_bytecode> opcode.
Ok, thanks for your explanation.
>
> > It sounds kinda odd to have an exception while exiting is quite a normal
> > action. It's just an op being executed with expected behaviour. Kinda
weird
> > to call it an exception (or throw one for that matter).
>
> The C<exit> can happen deeply inside some called subs. The exception
> can be caught e.g. in main, to do some cleanup before really shutting
> down. Makes sense to me.
You've got a point there. But it's a bit a matter of taste I think. I seems
a bit odd to me that an exception is thrown while nothing unexpected is
done. Cleaning up is ok, of course. But IMHO an exception is an error in the
program after which the program can exit in a nice way (handle these
exceptions nicely).
So, popping an integer from the stack into a N-register, for example is an
exception (well, in that particular case it's a bug, probably), or when a
stack underflow occurs. Those thinks sound like exceptions to me. But
exiting the program is quite a normal thing.
Oh well, it's not *that* important. :-)
Klaas-Jan
Luke Palmer
> From: "Leopold Toetsch" <l...@toetsch.at>
> > The C<exit> can happen deeply inside some called subs. The exception
> > can be caught e.g. in main, to do some cleanup before really shutting
> > down. Makes sense to me.
>
> You've got a point there. But it's a bit a matter of taste I think. I seems
> a bit odd to me that an exception is thrown while nothing unexpected is
> done. Cleaning up is ok, of course. But IMHO an exception is an error in the
> program after which the program can exit in a nice way (handle these
> exceptions nicely).
> So, popping an integer from the stack into a N-register, for example is an
> exception (well, in that particular case it's a bug, probably), or when a
> stack underflow occurs. Those thinks sound like exceptions to me. But
> exiting the program is quite a normal thing.
Those things are interpreter exceptions -- the program did something the
interpreter didn't expect. But I think the idea is to make C<exit> a
control exception, much like Perl 6's C<leave> or C<next>. Those aren't
erroneous conditions, they're just things that the behavior of
exceptions are useful for implementing. And the same goes for C<exit>.
Luke
Leopold Toetsch
> From: "Leopold Toetsch" <l...@toetsch.at>
>> The C<exit> can happen deeply inside some called subs. The exception
>> can be caught e.g. in main, to do some cleanup before really shutting
>> down. Makes sense to me.
> You've got a point there. But it's a bit a matter of taste I think. I seems
> a bit odd to me that an exception is thrown while nothing unexpected is
> done. Cleaning up is ok, of course. But IMHO an exception is an error in the
> program after which the program can exit in a nice way (handle these
> exceptions nicely).
Pie-thon has more of that. Some iterators are throwing an StopIteration
exception when they are finished. It makes sense though. You can't
return a single retval that is the loop test variable too.
while (item in next_item()) ...
doesn't work it a "false" item is a valid return value. An exception is
just an handy way for a non local (loop) exit or branch. Perl6 will have
"undef but true" for such cases.
An exception isn't an error.
> So, popping an integer from the stack into a N-register, for example is an
> exception (well, in that particular case it's a bug, probably), or when a
> stack underflow occurs. Those thinks sound like exceptions to me. But
> exiting the program is quite a normal thing.
We have many such C<internal_exception>s like above in code. Probably
only a few of these will become C<real_exception>.
> Oh well, it's not *that* important. :-)
Its important to sort out, what'll be a real exception though.
> Klaas-Jan
leo
Leopold Toetsch
> Those things are interpreter exceptions -- the program did something the
> interpreter didn't expect. But I think the idea is to make C<exit> a
> control exception, much like Perl 6's C<leave> or C<next>.
Yep & yep. C<exit> already is a (control) exception.
> Luke
leo