On Sat, 25 Oct 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 10:10 AM +0200 10/25/03, Leopold Toetsch wrote:
>
> > Oh, it certainly can be an absolute address, if you know what the
> > address is when you're generating the code.
>
> Did you ever try, what the assembler considers needing fixup: a
> _non_local label. I don't know, if that's the problem. But local labels
> (w/o underscores) are considered to be fixed up immediately, while global
> labels are fixed up later.
Right, bit this wasn't a label at all, unless the assembler's considering
everything a label. (Which isn't unreasonable, certainly) The code looked
something like:
jsr 123325412
Give or take a couple digits.
> > 2drop, for example, drops the two words on the top of the stack and
> > is really just "drop drop", and can be build from existing words.
> > (drop, in this case) The generated code for the word *should* look
> > like:
>
> > jsr .drop
> > jsr .drop
> > ret
>
> Yep, that's right. It would be slightly simpler, if there were one or
> two tests in the forth directory, anyway, after sneaking into "info
> gforth", I figured out that ": bla 2 + ; 1 bla ." would compile the
> "bla" opcode and print 3 :)
Good point. I've been testing interactively, but as soon as I rejig it to
use PMCs I'll add in some tests.
> I didn't look at that immediate thing yet, but it would be fine if you
> could extract some PASM lines, that exhibit this inconsistency. But IIRC
> gets the integer argument fixed up, while the constant isn't. This is
> due to the fact, that opcodes don't have any information, which argument
> is a branch offset or address. There is only one assumption, that, when
> there is a branch, the last argument of one opcode is the branch offset.
>
> So during label fixup there are some hardwired "is this a set_addr" or
> such, and then when yes, fixup the second argument.
Ah, that makes sense. The assembler expects a real label since it can't
reasonably get an integer constant, and I'm providing an integer constant.
:)
> > I'm OK both with different bytecode
> > segments sharing a constant table, as well as mandating that new
> > segments may, if given the appropriate flags at creation time, can
> > share the existing constant segment.
>
> That's the way to go. The compile stuff was a joke in the first place to
> get Jerome's bfc compiler running. The first implementation just used the
> (one and only) constant table and generated a new bytecode segment. But
> generally, an eval()ed piece of code could produce constants en mass,
> never going away and exhausting memory finally.
While the *implementation* might've been for a joke, and what I did for
forth was definitely a nasty hack, the actual semantics and facility's
darned useful. (Though, arguably, not 100% essential)
> So the plans (tm) are, to make such (compiled) code segments PMCs, which
> can go out of scope like any other closure or such, and that get cleaned
> up by DOD.
Right, I've been thinking about that. For this to work right, code
segments really need to be contained in something DOD-able and traceable,
which would make things a bit more robust. Code segments wouldn't be
moveable, of course, but it would be nice to be able to trace them and
free the chunks up when we're done with them.
> Coming back to your forth case. You didn't have constants in the
> compiled code, so your hacks are working. But for general usage we need
> some flags, what the compiled code should share with the calling
> bytecode. This is not only the constant table but concerning all
> segments like debug (currently line numbers only).
Sharing the constant table amongst segments seems straightforward, and I
can't think of a good reason to not do so, though I can see potential
issues with safe mode code changing constants in shared segments, but
that's more an issue of preventing the change (or sharing) in a safe
environment.
It may be reasonable to have an appendable bytecode segment that can be
passed along to the compilation modules. The compiler modules can create a
new segment if one's not passed in, or append to an existing one if it is,
to save on segments. I can see allowing 'raw' bytecode with no segments at
all (I almost went that route) but I think that'll make things too much of
a pain in other places.
> This also means, that there will be some restructuring of
> interpreter->code (and ->constants), the former is now the packfile, and
> will be a directory segment finally, the shortcuts like constants or jit_code
> will probably die, they make a mess out of code segment switching ...
:) If it doesn't lose us speed, I'm fine with things being rearranged.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
