[imcc] objects speed, .include and file-scoped vars, and various stuff
Jerome Quelin
Since objects are closing in, I begin to work on the new version of
Befunge, that will be written in imcc.
Anyway, whatever the reason, I'm playing with imcc and have some
questions about it:
- will objects introduce a speed overhead? I'm asking this question
because the Lahey space can be modelized by an object, with attributes
(min and max x, min and max y, content) and methods (set_max, set_min,
get_value_at, etc.). But since there will be only one Lahey space, an
object may be overkill (especially if there are speed issues), and I'd
better create a regular module with file-scoped vars and global
subroutines.
- if I implement the Lahey space module as a regular module, how can I
declare file-scoped vars that will be accessible by the subroutines of
the file and only them? Since imcc parses compilation units first, I
don't see how to do this... Maybe with the ".namespace" keyword?
- if I can't use file-scoped lexical vars, maybe the solution is to
declare some global var with the "global" keyword (in some sort of
init_module function). The question is once again if this comes with a
speed overhead? And if yes, which will be faster: a Lahey space
full-blown object or a regular module with globals (that one need to
retrieve)?
- can you think of another solution that will be imcc-friendly?
On a side note:
- the global does not seem to be available:
$ cat foo.imc
sub _main
.local int width
width = 0
global "lhs_width" = width
end
.end
$ imcc foo.imc
error:imcc:iANY file foo.imc line 5: op not found 'store_global_sc_i'
(store_global<2>)
$
Will the feature be implemented soon?
- when using the global keyword, can the string where one stores the
value be anything? For example, can I use "foo::bar" as a global name?
- when including a file with .include, the line numbering continues to
increase without being zeroed, and it's quite difficult to track errors
because of this behavior
- when including a file, if it isn't properly newline terminated, you
get an error even if the line is a comment...
$ imcc main.imc
(error) line 26: parse error, unexpected $undefined, expecting '\n'
Didn't create output asm.
Thanx for your answers,
Jerome
--
jqu...@mongueurs.net
Melvin Smith
>Anyway, whatever the reason, I'm playing with imcc and have some
>questions about it:
I think its officially time to put together a nice set of documentation
for IMCC (like web based). I'll try to start, right after I catch up with the
year of progress Leo has made since I last touched it.
Leo, Dan, prepare for a barrage of offline email. :)
-Melvin
Leopold Toetsch
> - will objects introduce a speed overhead?
For sure, but not a big one. You can AFAIK obtain an integer index for
an attribute or method so its basically an array lookup.
> - if I implement the Lahey space module as a regular module, how can I
> declare file-scoped vars that will be accessible by the subroutines of
> the file and only them? Since imcc parses compilation units first, I
> don't see how to do this... Maybe with the ".namespace" keyword?
Just put a ".local" or ".sym" declaration outside/in front of your subs.
This declares a file-scoped variable.
> - the global does not seem to be available:
> $ cat foo.imc
> sub _main
> .local int width
> width = 0
> global "lhs_width" = width
The *global opcodes are PMC variables only.
> Will the feature be implemented soon?
As the global stash is a PerlHash, it could be done. OTOH all the
lexical opcodes are PMC-only too and these can only store PMCs in their
array slot.
> - when using the global keyword, can the string where one stores the
> value be anything? For example, can I use "foo::bar" as a global name?
Yes.
> - when including a file with .include, the line numbering continues to
> increase without being zeroed, and it's quite difficult to track errors
> because of this behavior
This needs work - Or its a bug, if line numbers are messed up by
including a file.
> - when including a file, if it isn't properly newline terminated, you
> get an error even if the line is a comment...
> $ imcc main.imc
> (error) line 26: parse error, unexpected $undefined, expecting '\n'
> Didn't create output asm.
That's fine for me and the error message is stating the problem.
> Thanx for your answers,
> Jerome
Welcome,
leo
Jerome Quelin
> Jerome Quelin <jqu...@mongueurs.net> wrote:
> > - will objects introduce a speed overhead?
> For sure, but not a big one. You can AFAIK obtain an integer index
> for an attribute or method so its basically an array lookup.
Nice. So maybe I'll go for an object...
> > - if I implement the Lahey space module as a regular module, how
> > can I declare file-scoped vars that will be accessible by the
> > subroutines of the file and only them? Since imcc parses
> > compilation units first, I don't see how to do this... Maybe with
> > the ".namespace" keyword?
> Just put a ".local" or ".sym" declaration outside/in front of your
> subs. This declares a file-scoped variable.
It does not seem to be file-scoped:
$ cat main.imc
.sub __START__
call _main
.end
.include "lahey_space.imc"
.sub _main
call _lhs_init
print "main.imc: "
print width
print "\n"
end
.end
$ cat lahey_space.imc
.local int width
.sub _lhs_init
width = 42
print "lahey_space.imc: "
print width
print "\n"
ret
.end
$ imcc main.imc
lahey_space.imc: 42
main.imc: 42
$
It looks like a global variable to me.
> > - the global does not seem to be available:
> > $ cat foo.imc
> > sub _main
> > .local int width
> > width = 0
> > global "lhs_width" = width
> The *global opcodes are PMC variables only.
> > Will the feature be implemented soon?
> As the global stash is a PerlHash, it could be done. OTOH all the
> lexical opcodes are PMC-only too and these can only store PMCs in
> their array slot.
Okay.
> > - when including a file with .include, the line numbering
> > continues to increase without being zeroed, and it's quite
> > difficult to track errors because of this behavior
> This needs work - Or its a bug, if line numbers are messed up by
> including a file.
Not messed, but it would be nice to have the real file and line number
of the error.
Jerome
--
jqu...@mongueurs.net
Leopold Toetsch
> Leopold Toetsch wrote:
>> Just put a ".local" or ".sym" declaration outside/in front of your
>> subs. This declares a file-scoped variable.
> It does not seem to be file-scoped:
.include gets pulled in inside the lexer, so its the same, as it were in
that file.
And is we currently have one bytecode segment (or file to compile) only
the file scope looks like a global.
> Not messed, but it would be nice to have the real file and line number
> of the error.
Yep. We need a similar thing, as with the macros.
> Jerome
leo