abcasm: using direct opcodes does not work

NEW
Assigned to

Status

9 years ago
7 years ago

People

(Reporter: cpeyer, Assigned: tharwood)

Tracking

(Blocks: 2 bugs)

unspecified
Future
Dependency tree / graph
Bug Flags:
flashplayer-qrb +

Details

(Reporter)

Description

9 years ago
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'
(Reporter)

Updated

9 years ago
Blocks: 490682
(Assignee)

Comment 1

9 years ago
Problem is that the grammar expects to see an operands list for the instruction, and instructions like add don't have operands.
(Reporter)

Updated

9 years ago
Blocks: 490684

Updated

9 years ago
Target Milestone: --- → Future
(Reporter)

Updated

9 years ago
Duplicate of this bug: 559371
(Reporter)

Updated

9 years ago
Blocks: 555002
(Assignee)

Comment 3

9 years ago
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.
(Reporter)

Comment 4

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

Comment 5

9 years ago
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.
(Assignee)

Comment 6

9 years ago
(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

9 years ago
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.
(Assignee)

Comment 8

9 years ago
(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

9 years ago
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
}
(Assignee)

Comment 10

9 years ago
Workaround for the current grammar: 0xa0 1 // appease the grammar

Updated

7 years ago
Flags: flashplayer-qrb+
You need to log in before you can comment on or make changes to this bug.