Dan Sugalski <[EMAIL PROTECTED]> wrote:
> On Sat, 25 Oct 2003, Leopold Toetsch wrote:
>> 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
> reason
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 assemb
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
At 10:10 AM +0200 10/25/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
"jsr " where is an immediate address rather than a register
generates bad code.
C takes an absolute bytecode address, which IMHO never can be an
immediate integer. The op should be defined as j
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Runtime code generation works mostly, but for some reason the sequence
Another note: jsr/ret are not prepared to do inter-segment branches. A
compiled code segments is currently an entirely new packfile (it should
be only a new packfile directory finally
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> "jsr " where is an immediate address rather than a register
> generates bad code.
C takes an absolute bytecode address, which IMHO never can be an
immediate integer. The op should be defined as jsr(invar INT).
leo
