Re: [RfC] Testing for null
At 4:36 PM -0500 12/8/03, Gordon Henriksen wrote: On Monday, December 8, 2003, at 10:03 , Dan Sugalski wrote: At 1:21 PM -0500 12/3/03, Melvin Smith wrote: We should have 1 recommended way for testing NULL registers. If we support get_bool() then lets make sure it works for REAL NULL pmc registers as well as PMCNULL. If not, code will appear to work correctly on a safe core but will seg fault on some other. Also, I see no reason not to use PMCNULL in all cores now. Okay, lets do this: Add an isnull branch op: isnull Px, destination How about this to test if Px is really null? null Py eq_addr Px, Py That involves explicitly doing things with PMCs we've just decared are bogus. Seems a little backwards. :) I think I'd prefer the check for explicit bogusness be a separate opcode, that way it can also check for real NULLs. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Missing branch instructions?
At 9:12 PM + 12/8/03, Pete Lomax wrote: On Mon, 8 Dec 2003 11:35:59 -0500, Dan Sugalski [EMAIL PROTECTED] wrote: Unqualified eq/cmp/lt are OK for two PMC operations, I'm not convinced at all here. PMC comparison ops, afaict, are based solely on the pmc instance/address Well... no. Here's a snippet to play with: $P1 = new Array $P1 = 2 $P1[0] = 1 $P1[1] = 1 $P2 = new Array $P2 = 2 $P2[0] = 1 $P2[1] = 1 # eq $P1, $P2, _L3 eq fred, fred, _L3 print error \fred\!=\fred\ _L3: Is $P1=$P2? Well... maybe. And maybe not. Heck, even this: new P1, .Foo set P2, P1 eq P1, P2, OK may not branch to OK. (There's no requirement that high-level comparisons require a PMC to be equal to itself) That's why eq, eq_num, and eq_str for PMC comparisons should call the three versions of equality vtable functions, and the comparison ops should do the same depending on whether they're doing a numeric, string, or generic comparison. It's important not to confuse these high-level comparisons with lower-level things like PMC address comparisons. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Missing branch instructions?
At 11:52 AM 12/9/2003 -0500, Dan Sugalski wrote: may not branch to OK. (There's no requirement that high-level comparisons require a PMC to be equal to itself) Although committing such a confusing PMC to Parrot is certainly questionable. -Melvin
Re: Missing branch instructions?
At 12:40 PM -0500 12/9/03, Melvin Smith wrote: At 11:52 AM 12/9/2003 -0500, Dan Sugalski wrote: may not branch to OK. (There's no requirement that high-level comparisons require a PMC to be equal to itself) Although committing such a confusing PMC to Parrot is certainly questionable. I'm not arguing that one should be part of the base collection, by any means. However, consider the SQL NULL, or a numeric Infinity. NULL != NULL, and last I knew (and I may be horribly wrong here :) Inf != Inf. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Incorrect scoping of constants in IMCC
Just ran across a bug in IMCC. The .const directive is incorrectly available only within a .sub/.end block. Silly. (And wrong) That makes it very difficult to usefully use constants--generally they're defined at the top of a file (or in a file which is .included) and visible through the rest of the compilation unit. When someone gets a chance to patch this one up, I'd much appreciate it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [CVS ci] object stuff
At 5:46 PM +0100 12/5/03, Leopold Toetsch wrote: Melvin Smith [EMAIL PROTECTED] wrote: At 05:14 PM 12/5/2003 +0100, Leopold Toetsch wrote: set I2, P1[Foo\x00i] # I1 == I2 gets currently the attribute idx (0) of $Foo::i. Q: Should the assembler mangle the Foo::i to Foo\0i Something about this embedded \0 character bugs me. I know its what Dan has in the design doc but it just seems too cryptic. Yeah its ungly. OTOH it should be really transparent for all possible HLLs. And the NUL most certainly is. I don't like it either, but the alternative is to impose an external hierarchic structure. Which we certainly could do, though it may make some things more difficult. I'm more than willing to entertain arguments for and against the hierarchic structure, but we're closing in on the point where we fix the scheme and don't change it any more. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Incorrect scoping of constants in IMCC
At 04:20 PM 12/9/2003 -0500, Dan Sugalski wrote: Just ran across a bug in IMCC. The .const directive is incorrectly available only within a .sub/.end block. Silly. (And wrong) That makes it very difficult to usefully use constants--generally they're defined at the top of a file (or in a file which is .included) and visible through the rest of the compilation unit. When someone gets a chance to patch this one up, I'd much appreciate it. Fixed. Parser will not allow .const outside of a compilation unit and make it global to the compilation. .const inside a .sub will be local to the sub only (no change there). -Melvin
Re: Incorrect scoping of constants in IMCC
At 10:04 PM 12/9/2003 -0500, Melvin Smith wrote: AWhen someone gets a chance to patch this one up, I'd much appreciate it. Fixed. Parser will not allow .const outside of a compilation unit and make it global to the compilation. .const inside a .sub will be local to the sub only (no change there). Typo. not=now Parser will NOW allow .const outside of a compilation unit -Melvin
Re: Incorrect scoping of constants in IMCC
From: Melvin Smith [EMAIL PROTECTED] At 04:20 PM 12/9/2003 -0500, Dan Sugalski wrote: which is .included) and visible through the rest of the compilation unit. Parser will not allow .const outside of a compilation unit and make it global to the compilation. Hmm... What do you mean by a compilation unit? a file? Will it be global to all compilation units or rather to the one where the .const was defined? 0x4C56 Happy .~. /V\ // \\ /( )\ ^`~'^ 2004 keeps comin'
Re: Incorrect scoping of constants in IMCC
At 07:58 AM 12/10/2003 +0300, Vladimir Lipsky wrote: From: Melvin Smith [EMAIL PROTECTED] At 04:20 PM 12/9/2003 -0500, Dan Sugalski wrote: which is .included) and visible through the rest of the compilation unit. Parser will not allow .const outside of a compilation unit and make it global to the compilation. Hmm... What do you mean by a compilation unit? a file? Will it be global to all compilation units or rather to the one where the .const was defined? 0x4C56 Right now a unit is a subroutine. Eventually it might also mean class, package, etc. I used a confusing term there. For a single compile session, meaning all includes/imports, a global constant will be visible. -Melvin
Re: Another minor task for the interested
At 8:12 PM + 12/6/03, harry wrote: Dan Sugalski wrote: I was mostly thinking that some step or other in the Makefile has a dependency on that file, and some other step creates it, but the dependency's not explicit. I'd like to find the step(s) that require it and make it a dependency for them, then add in a dependency for the file for whatever step actually creates it, so things get ordered properly. It should (hopefully) be straightforward, but... I hope after this amount of time someone still wants this fixed. After much rummaging around I added the following to the makefile and it seems to be working up to 4 Jobs now. I think this may open up a few more problems though. I dug up where this is getting setup, and it seems to work out OK. Thanks! -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Incorrect scoping of constants in IMCC
On Tue, 9 Dec 2003 16:20:25 -0500, Dan Sugalski [EMAIL PROTECTED] wrote: Just ran across a bug in IMCC. The .const directive is incorrectly available only within a .sub/.end block. Silly. (And wrong) That makes it very difficult to usefully use constants--generally they're defined at the top of a file (or in a file which is .included) and visible through the rest of the compilation unit. When someone gets a chance to patch this one up, I'd much appreciate it. There's no file level locals yet either ;-) Can I ask a stupid question? Guess I'm going to anyway... Is there much benefit to .const, over sticking a value in a register and not modifying it? (which is what I've done to get round this) How much benefit for a heavily used 0/1 flag? What about a lightly used string? Pete
Re: Incorrect scoping of constants in IMCC
Pete Lomax writes: There's no file level locals yet either ;-) Can I ask a stupid question? Guess I'm going to anyway... Is there much benefit to .const, over sticking a value in a register and not modifying it? (which is what I've done to get round this) Yes. First, if you want more than 8 constants of some type, this isn't the way to go, as you'll starve your registers, and things will get quite a bit slower. And in general, registers are for things that change. The constant table is for constants. How much benefit for a heavily used 0/1 flag? If it never changes? None. It'll load it up from the constant table just as fast as it'll load it up from a register. This may be different in the presence of JIT and caching, two things which I know nothing about. But in the general case, no benefit at all. What about a lightly used string? Same deal. Except here I'm pretty sure there's no JIT benefit. Luke
