490681 - abcasm: using direct opcodes does not work

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Tools, defect)

Description

[Chris Peyer]

Using direct opcodes instead of the instruction name produces an error:

working code with add instruction:
function main() {
    getlocal0
    pushscope
    findproperty print
    pushint 1
    pushint 1
    add
    callpropvoid print 1
    returnvoid
}

Substituting 0xa0 for add results in the following error:

Unable to assemble abcasm/test.abs due to syntax errors:
line 8:4 no viable alternative at input 'callpropvoid'

Comment 1

[Tom Harwood]

Problem is that the grammar expects to see an operands list for the instruction, and instructions like add don't have operands.

Comment 3

[Tom Harwood]

This problem bites both ways.  Consider the sequence:

    0x30 //  pushscope
    0x33 // li8

The assembler is whitespace-agnostic so it sees this as 0x33 with a single operand, 0x33.  The emitter knows pushscope doesn't take any operands, though, and so it emits 0x30 and 0x33 is lost.

Comment 4

[Chris Peyer]

QE Note: Fix abcasm/invalid_opcode*.abs when this bug has been fixed.

Comment 5

[Edwin Smith]

Suggested fix:  do not allow numeric literals as opcode mnemonics.  instead, add pseudo-ops:

 .u8   literal, ...   // value must be 0..255, emits 1 byte per literal
 .u30 literal, ...  // value must be 0..2^30-1, emits variable-length-encoded u30 value for each literal
 .s24 literal, ...  // value must be -2^15 .. 2^15-1, emits 3 byte signed int for each literal

Other possible ways to forumlate this are welcome too.  with .u8, we can get by.  the others are conveniences.

Comment 6

[Tom Harwood]

(In reply to comment #5)

No more .foo pseudo-ops.  Those things are a pestilence for me to regret at leisure.
Current thinking on syntax is instruction { opcode=0xab, operand=4, operand="foo", operand=q::name }

Comment 7

[Edwin Smith]

I'm intrigued, but I don't follow.  Can you give an example of how that would be used in bytecode?  The use case here is just sticking random sequences of random bytes in random places anywhere in the code body.

Comment 8

[Tom Harwood]

(In reply to comment #7)
> I'm intrigued, but I don't follow.  Can you give an example of how that would
> be used in bytecode? 

Suppose we have a new instruction that takes a string as its operand.  The ad-hoc sequence would be

instruction { opcode=0xab, operand="foo" }

Since the assembler can recognize an integer, string, or name based on syntax we can support a richer set of operand types than the current rule allows.

> The use case here is just sticking random sequences of
> random bytes in random places anywhere in the code body.

For that we can use bytes { 0xff, 0x00, 0x01 }

An alternative to all this is to make the ad-hoc rule recognize a single byte sequence, but that is prone to causing lexer/parser issues.

Comment 9

[Edwin Smith]

Here's a test from bug 555002 that is working around this abcasm bug:

function main() {
   getlocal0
   pushscope
   // Try to use the invalid opcode 0x5C
   // TODO: remove bogus 123 arg below when Bug 490681 has been fixed
   0x5C 123
   returnvoid
}

Sounds like it would be rewritten as:

function main() {
   getlocal0
   pushscope
   instruction { opcode=0x5c } 
   returnvoid
}

Correct?  or, the alternate proposal is

function main() {
   getlocal0
   pushscope
   { 0x5c }
   returnvoid
}

I like the second one better, but either sound workable.  The use case is testing invalid code, so if we add a new instruction, I am assuming we would add support in abcasm for it.  Does sticking a string literal automatcially generate a cpool-reference (U30) to it?  that'd be nice.  then this would work:

function main() {
   { 0xab "foo" }
   returnvoid
}

Comment 10

[Tom Harwood]

Workaround for the current grammar: 0xa0 1 // appease the grammar

Comment 11

[Sylvestre Ledru [:Sylvestre]]

Tamarin is a dead project now. Mass WONTFIX.

Comment 12

[Sylvestre Ledru [:Sylvestre]]

Tamarin isn't maintained anymore. WONTFIX remaining bugs.