Incorrect scoping of constants in IMCC
Dan Sugalski
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
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Melvin Smith
>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
Melvin Smith
>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
Vladimir Lipsky
> 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'
Melvin Smith
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
Pete Lomax
>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
Luke Palmer
> 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
Dan Sugalski
>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.