Re: Incorrect scoping of constants in IMCC
At 4:40 AM + 12/10/03, Pete Lomax wrote: 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) These are the equivalent of C's #define constants, so there's quite a lot of benefit, but it's all in source code abstraction. Not that useful if you're writing a compiler, though, as you can spit out the expanded constant then. -- 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: 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
