How to implement a 'context stack' in Sleigh?

[hippietrail]

The instruction set I'm working with has different interpretations of most opcodes after FMT and before FEND which I was able to implement by using a context register:

define register offset=0x40 size=4 contextreg;

define context contextreg
    in_fmt = (0,4)
;

:FMT is in_fmt=0 & op=0x08 [ in_fmt=in_fmt+1; globalset(inst_next,in_fmt); ] { }

:FEND is in_fmt>0 & op=0xFB [ in_fmt=in_fmt-1; globalset(inst_next,in_fmt); ] { }

But it turns out the FEND opcode 0xFB also ends a context created with a FOR instruction and FEND takes an operand when closing FOR but not when closing FMT.

This means I need a context stack rather than just depth. But I'm stuck trying to implement it.

Can I actually use structs/objects or only integers for these context registers? I can't find any evidence that anything other than integers can be used but haven't fully internalized the docs despite several readings.

So assuming the alternative is a shift register where a 0 represents a FMT scope and a 1 represents a FOR scope I'm still getting stuck.

How can I check the low bit of my stk context register? In the constraints & is logical and. The docs say there is &and for bitwise and but this gives me errors.

:FEND is in_fmt>0 & op=0xFB & stk $and 0x1 = 0 [

GPL.slaspec line 753: expecting RPAREN, unexpected token: '$and':

I've tried with various combinations of parentheses around the logic.

I've also tried to add a second context variable representing just the bit at the top of the stack.

But stk is always 0 inside FEND even though I can verify it's getting changed in FOR:

:FOR(f,c) >lo5plus is in_fmt>0 & ophi3=0x6 & lo5plus [
                 stk=stk<<1;
                 stk=stk|1;
                 globalset(inst_next,stk);
                 in_fmt=in_fmt+1;
                 globalset(inst_next,in_fmt);

                 f = stk;
                 c = stktopc;
                 ] { }

:FEND(f,c) is in_fmt>0 & op=0xFB [
            f = stk;
            c = stktopc;
            stk=stk>>1;
            globalset(inst_next,stk);
            in_fmt=in_fmt-1;
            globalset(inst_next,in_fmt);
            ] { }

I added the (f,c) for debugging and the listing shows it's set to 1 in FOR but 0 in FEND.

What am I doing wrong? Or am I missing an easier way to achieve this?

[GhidorahRex]

You can definitely only use integers for context. The trouble isn't the opcode overlap as much as the nested FOR loops, although you can't really solve the overlap without solving the nested loops. The good news is that you won't ever have a FMT nested in a FOR loop, AND you'll never have a FMT nested in a FMT - so you still only need a depth counter.

So I would make FENDlike :FEND is fmt>0 & op=0xFB. Then for LOOP we have :LOOP LoopAddr is (fmt < 1) & op=0xFB & LoopAddr

That should at least get you through some of the parsing issues, but the next challenge is properly representing the loop counts. Also I'm unsure of the difference between LOOP and NEXT - how does the parser know whether there is an operand following?

But if you wanted to reference the a specific bit of a context field, you need to make a sub-variable such as:

define context contextreg
    in_fmt = (0,4)
   fmt0=(0,0)
;

I know the doc mentions $and and $or but I've never had to use them.

[hippietrail]

... you won't ever have a FMT nested in a FOR loop, AND you'll never have a FMT nested in a FMT - so you still only need a depth counter.

Great observation! I can use a flag for in_fmt and a depth counter for in_for.

That should at least get you through some of the parsing issues, but the next challenge is properly representing the loop counts. Also I'm unsure of the difference between LOOP and NEXT - how does the parser know whether there is an operand following?

FOR takes a 5-bit operand and FEND (next) takes a 16-bit operand while FEND (fmt end) takes no operand. The parser can only know whether there's an operand following based on the context, which was the problem at hand. This is what I went with:

:FMT is in_fmt=0 & in_for=0 & op=0x08 [ in_fmt=in_fmt+1; globalset(inst_next,in_fmt); ] { }

:FOR lo5plus is in_fmt>0 & ophi3=0x6 & lo5plus [ in_for=in_for+1; globalset(inst_next,in_for); ] { }

:FEND.fmt is in_fmt>0 & in_for=0 & op=0xFB [ in_fmt=in_fmt-1; globalset(inst_next,in_fmt); ] { }

:FEND.for p1d is in_fmt>0 & in_for>0 & op=0xFB; p1d [ in_for=in_for-1; globalset(inst_next,in_for); ] { }

which produces output like this

                       
         601d 07 20                        ALL.07      0x20                                     all   >20
         601f 87 7e                        DCLR.87     @0x837e                                  dclr  @ypt
         6021 08                           FMT                                                  fmt
         6022 cb                           FOR         0xc                                      for   >0c
         6023 ff 1a                        COL.FF      0x1a                                     col   >1a
         6025 04 48 45 4c 4c 4f            HTEX        'H''E''L''L''O'                          htext 'HELLO'
         602b a1                           ROW+        0x2                                      row+  >02
         602c fb 60 23                     FEND.for    0x6023                                   fend
         602f fb                           FEND.fmt                                             fend
         6030 86 4a                        CLR.86      @0x834a                                  clr   @>834a
         6032 be 4b 20                     ST.BE       0x20,@0x834b                             st    >20, @>834b

(There's some suffixes for debugging purposes. The right column is one of the reference disassemblers' output.)

I know the doc mentions $and and $or but I've never had to use them.

I have now used $and in test code inside [] sections to do quick math on fields that I'm not extracting the proper way. I guess they only work inside [].

[GhidorahRex]

I was reading the documentation wrong, and thinking that sometimes loop/next could have an address, and sometimes it didn't. It appears that when writing the code, you can omit the address and the LOOP instruction will loop to the address immediately after the RPTB instruction, but the actual assembly code will always have an address.

But you shouldn't need two counters. You just need 1. If the counter is at 0, you're not in afmt block. If the count is 1 you're in a fmt block with nofor loop, and if the counter is greater than 1 you're in a for loop.

[hippietrail]

I was reading the documentation wrong, and thinking that sometimes loop/next could have an address, and sometimes it didn't. It appears that when writing the code, you can omit the address and the LOOP instruction will loop to the address immediately after the RPTB instruction, but the actual assembly code will always have an address.

Oh you actually have the docs for TI-99/4A GPL? It seems to me though I haven't asked the community yet that there are at least two syntaxes. I've been going by the 2016 R. A. Green book mainly because that was the first reference I had. It's also a bit easier to read and is copy-pasteable whereas the official 1979 book I only have in OCR and found it later. The first disassembler I found, and the one whose output I've been using as a guide is xdg99.py though a few days ago I found there's also disgpl. I've started cross-checking against it when I'm unclear on anything.

But you shouldn't need two counters. You just need 1. If the counter is at 0, you're not in afmt block. If the count is 1 you're in a fmt block with nofor loop, and if the counter is greater than 1 you're in a for loop.

Yes I'll change the fmt counter to a boolean flag. I just went for the minimal change for testing to make sure I didn't accidentally break something else.

[GhidorahRex]

Not the official docs, just whatever I could google on short notice to answer this question