Re: [RFC] IMCC pending changes request for comments
On Dec 2, 2003, at 8:49 PM, Melvin Smith wrote: 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
Re: [RFC] IMCC pending changes request for comments
On Tuesday, December 2, 2003, at 11:49 , Melvin Smith wrote: 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 [EMAIL PROTECTED]
Re: [RFC] IMCC pending changes request for comments
At 10:37 AM 12/3/2003 +0100, Leopold Toetsch wrote: Melvin Smith <[EMAIL PROTECTED]> wrote: > 1) Currently typenames are not checked except with 'new ' 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 identifier> and C<.param identifier> both assume > that anything for type other than (int|float|string) is a PMC. Yep. Some remarks: .local ident collides with the macro syntax for local labels. So when doing something here I'd resolve that conflict too and allow only: .sym ident # ::= 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 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
Re: [RFC] IMCC pending changes request for comments
Melvin Smith <[EMAIL PROTECTED]> wrote: > 1) Currently typenames are not checked except with 'new ' 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 identifier> and C<.param identifier> both assume > that anything for type other than (int|float|string) is a PMC. Yep. Some remarks: .local ident collides with the macro syntax for local labels. So when doing something here I'd resolve that conflict too and allow only: .sym ident # ::= int|float|string|pmc I'm not sure but: .newsym 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
Re: [RFC] IMCC pending changes request for comments
At 07:59 PM 12/2/2003 -0800, Steve Fink wrote: On Dec-02, Melvin Smith wrote: > > 1) Currently typenames are not checked except with 'new ' 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
Re: [RFC] IMCC pending changes request for comments
On Dec-02, Melvin Smith wrote: > > 1) Currently typenames are not checked except with 'new ' 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.
[RFC] IMCC pending changes request for comments
In an effort to improve its error reporting ability and internal 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 ' C<.local identifier> and C<.param 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 and C as types in IMC code. I believe Jako and Perl6 compilers use C as well. I'm ok with just adding those 2 as aliases for C 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 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
Re: Request for comments
--- Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 08:03 PM 12/18/2001 -0800, Benjamin Stuhl wrote: > >--- Melvin Smith <[EMAIL PROTECTED]> wrote: > > > 3) Perl IO has conditional compilation for using > stdio. > > > Dan has said no > > > STDIO > > > but are we going to abandon conditional support > for > > > Parrot? > > > (I vote for ditching conditional STDIO support > > > because then its easier > > > to stop thinking in STDIO terms...) > > > >Unfortunately, I don't think we can completely do > without > >stdio in parrot for one reason: miniparrot. Without > doing a > >full configure.pl run, the _only_ I/O API we're > guarranteed > >is a basic stdio. > > Ah, but we can abandon stdio completely, unless you file > read/write in with > stdio. Which is reasonable, but I don't generally count > them. I was going to argue that unix-ish open()/read()/write()/close() aren't portable, but even Win32's runtime provides an emulation of that much (as does VMS's). Are there any platforms that don't provide this API? (I argued for stdio because it's in the ANSI spec, and so _must_ be there, as opposed to us simply assuming it'll be there.) > > > I want comments now or else I threaten to post > replies to > > > myself in a > > > creepy third > > > person way. > > > >No! Anything but that. BKS hates things like that! > > Suckered into those freshmen "harmless Psych 101 > experiments", I see :) Way too many friends in Prof. Moss's cult^Hclass... ;-) -- BKS __ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com
Re: Request for comments
>> Burp, more spam from me... >> >> As I see it there are several immediate questions to be answered for Parrot >> IO. >> Feel free to answer with Y/N or Maybe. >> >> 1) Nick Ing-Simmons' Perl IO for Perl5 >> c) Is there a copyright issue? > >Nick's intent all along has been that his work be useful and used in >perl6. Yes, This makes sense just from the amount of time he spent on Perl5 and I intend to to just that. Any work we do will have Nick's credits there, I think after talking to Dan, Simon and a couple of others the best route would be to start with a clean slate and then reuse what we can when it makes sense rather than a bottom up port from perl5 source code. It also helps me get a better handle on the system as it grows, especially since Nick isn't currently active here. Maybe he will return to help. :) One thing we should accomplish will be an API for people to pop in their own IO layer by implementing a table of calls. This seems to be where Perl5 was headed and I want to make that a priority. (Then of course the whole STDIO argument will be moot, if someone wants to glue in their STDIO mapper they can, we are just gonna ditch all the #ifdef and not support it by default.) -Melvin Smith IBM :: Atlanta Innovation Center [EMAIL PROTECTED] :: 770-835-6984
Re: Request for comments
On Tue, 18 Dec 2001, Melvin Smith wrote: > Burp, more spam from me... > > As I see it there are several immediate questions to be answered for Parrot > IO. > Feel free to answer with Y/N or Maybe. > > 1) Nick Ing-Simmons' Perl IO for Perl5 > c) Is there a copyright issue? Nick's intent all along has been that his work be useful and used in perl6. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Request for comments
At 08:03 PM 12/18/2001 -0800, Benjamin Stuhl wrote: >--- Melvin Smith <[EMAIL PROTECTED]> wrote: > > 3) Perl IO has conditional compilation for using stdio. > > Dan has said no > > STDIO > > but are we going to abandon conditional support for > > Parrot? > > (I vote for ditching conditional STDIO support > > because then its easier > > to stop thinking in STDIO terms...) > >Unfortunately, I don't think we can completely do without >stdio in parrot for one reason: miniparrot. Without doing a >full configure.pl run, the _only_ I/O API we're guarranteed >is a basic stdio. Ah, but we can abandon stdio completely, unless you file read/write in with stdio. Which is reasonable, but I don't generally count them. > > I want comments now or else I threaten to post replies to > > myself in a > > creepy third > > person way. > >No! Anything but that. BKS hates things like that! Suckered into those freshmen "harmless Psych 101 experiments", I see :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Request for comments
--- Melvin Smith <[EMAIL PROTECTED]> wrote: > Burp, more spam from me... And there was much rejoicing... (rah! yay!) > As I see it there are several immediate questions to be > answered for Parrot > IO. > Feel free to answer with Y/N or Maybe. All of the above? > 1) Nick Ing-Simmons' Perl IO for Perl5 > a) Could it easily support the features that Dan > wants in Parrot IO > such > as async stuff? Not really - its API is derived from ANSI stdio, which is not in the least bit useful as an async API. > b) Does it represent as an abstraction what we want > as an API for > Parrot? No. (See above.) Nevertheless, the basic concept of I/O layers _is_ one we want and need. > c) Is there a copyright issue? > d) If (a&b&c) has anyone approached Nick about > porting? > e) If not then goto (2) > > 2) What architecture about Perl IO does not fit what Dan > wants for Parrot > (if there are any). Perl(5)IO is not an async API - it has no way of passing in completion routines, for instance. > 3) Perl IO has conditional compilation for using stdio. > Dan has said no > STDIO > but are we going to abandon conditional support for > Parrot? > (I vote for ditching conditional STDIO support > because then its easier > to stop thinking in STDIO terms...) Unfortunately, I don't think we can completely do without stdio in parrot for one reason: miniparrot. Without doing a full configure.pl run, the _only_ I/O API we're guarranteed is a basic stdio. However, that being said, what we'll likely want to do is have a statically linked Miniparrot::IO module that provides wrappers over C stdio and we'll use _that_ in configure.pl. That way, we don't have to clutter up ParrotIO with stdio cruft. > 4) For platforms out there with broken or no async IO > support, do we > emulate > async (background thread or something) or just say, > "tough!?" Emulate as best we can. Nevertheless, if you're running MS-DOS or some equivalently-brain-damaged OS, there's not much we can do. But then, if you're writing serious event loops on DOS, you've probably got other problems to solve as well. > > I want comments now or else I threaten to post replies to > myself in a > creepy third > person way. No! Anything but that. BKS hates things like that! -- BKS __ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com
Re: Request for comments
On Tue, Dec 18, 2001 at 02:42:29PM -0500, Melvin Smith wrote: These are my opinions. If Dan contradicts me, he wins. > 1) Nick Ing-Simmons' Perl IO for Perl5 > a) Could it easily support the features that Dan wants in Parrot IO > such > as async stuff? Yes. > b) Does it represent as an abstraction what we want as an API for > Parrot? Yes. > c) Is there a copyright issue? Yes. Maybe. No. IANAL. > d) If (a&b&c) has anyone approached Nick about porting? NAFAIK. > 3) Perl IO has conditional compilation for using stdio. Dan has said no > STDIO > but are we going to abandon conditional support for Parrot? I say we ditch STDIO. > 4) For platforms out there with broken or no async IO support, do we > emulate > async (background thread or something) or just say, "tough!?" Emulate. -- fga is frequently given answers... the best are "Date::Calc", "use a hash", and "yes, it's in CPAN" or Data::Dumper or mySQL or "check your permissions" or NO Fmh THAT'S WRONG or "You can't. crypt is one-way" or "yes, i'm single" or "I think that's a faq." or substr! or "use split" or "man perlre" - #perl
Re: Request for comments
At 03:55 PM 12/18/2001 -0500, Melvin Smith wrote: > >> async (background thread or something) or just say, "tough!?" > > > >Emulate. And then I get to send out lots of cranky "Not async safe!" > >messages when things break places with real async IO systems. :) > >*cough* These VMS bigots... :) Damn straight! :) On the other hand, given the throughput the VMS I/O system delivers... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Request for comments
>> async (background thread or something) or just say, "tough!?" > >Emulate. And then I get to send out lots of cranky "Not async safe!" >messages when things break places with real async IO systems. :) *cough* These VMS bigots... :) -Melvin Smith IBM :: Atlanta Innovation Center [EMAIL PROTECTED] :: 770-835-6984
Re: Request for comments
At 02:42 PM 12/18/2001 -0500, Melvin Smith wrote: >Burp, more spam from me... M, spam! With mustard and cheddar, on a toasted bagel! :) >As I see it there are several immediate questions to be answered for Parrot >IO. >Feel free to answer with Y/N or Maybe. > >1) Nick Ing-Simmons' Perl IO for Perl5 > a) Could it easily support the features that Dan wants in Parrot IO >such > as async stuff? I'm not sure, I've not looked too closely at it. (I know, Bad Dan!) > b) Does it represent as an abstraction what we want as an API for >Parrot? Good question. > c) Is there a copyright issue? Nope, not any more. I need to update the license files for the repository, but we're GPL/AL, same as perl 5. > d) If (a&b&c) has anyone approached Nick about porting? He was originally going to dive into it when he got side-tracked with a new employer. (Along with the obligatory three month fight with their legal department over IP issues) >2) What architecture about Perl IO does not fit what Dan wants for Parrot > (if there are any). Good question. If I was to hazard a guess, I'd say the problem is that it's meant to support the IO model perl 5 has, warts and all. (It's been moving away from stdio, but that's where it started) >3) Perl IO has conditional compilation for using stdio. Dan has said no >STDIO > but are we going to abandon conditional support for Parrot? Yes, we are. >4) For platforms out there with broken or no async IO support, do we >emulate > async (background thread or something) or just say, "tough!?" Emulate. And then I get to send out lots of cranky "Not async safe!" messages when things break places with real async IO systems. :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Request for comments
Burp, more spam from me... As I see it there are several immediate questions to be answered for Parrot IO. Feel free to answer with Y/N or Maybe. 1) Nick Ing-Simmons' Perl IO for Perl5 a) Could it easily support the features that Dan wants in Parrot IO such as async stuff? b) Does it represent as an abstraction what we want as an API for Parrot? c) Is there a copyright issue? d) If (a&b&c) has anyone approached Nick about porting? e) If not then goto (2) 2) What architecture about Perl IO does not fit what Dan wants for Parrot (if there are any). 3) Perl IO has conditional compilation for using stdio. Dan has said no STDIO but are we going to abandon conditional support for Parrot? (I vote for ditching conditional STDIO support because then its easier to stop thinking in STDIO terms...) 4) For platforms out there with broken or no async IO support, do we emulate async (background thread or something) or just say, "tough!?" I want comments now or else I threaten to post replies to myself in a creepy third person way. -Melvin Smith IBM :: Atlanta Innovation Center [EMAIL PROTECTED] :: 770-835-6984
