spectool: add 64-bit test programs (GP-0.5.3) #238
Conversation
subotic
commented
Dec 6, 2024
•
subotic
commented
- added test programs for 64-bit instructions as per GP-0.5.3
- extended "polkavm-common/assembler" to support 64-bit instructions
- fixed some unit tests. Need pointers on how to fix them correctly.
|
@koute Could you maybe take a look if I'm on the right track? |
Yes, you're on the right track. (: |
|
@koute Also, is it possible to authorise me to run the workflows? I don't want to bother you all the time. |
|
@koute Is it correct, that |
|
@koute how to discern between |
Not entirely sure how to do that; I've added you as a read-only contributor - hopefully that will make the tests auto run.
If it's a negative number (i.e. the most significant bit is set) then yes, it should be sign extended (but the VM takes care of that automatically).
If a value can be encoded with a (And we could also have an override to force |
|
Great pointers thank you very much. This clears and answers a lot. |
|
@koute could you maybe take a look again? I had to change some unit tests, which should probably be done differently, but for this I would need your input. |
| if let Some(index) = rhs.find("i64 ") { | ||
| let rhs = rhs[index + 4..].trim(); | ||
| if let Some(imm) = parse_imm(rhs) { | ||
| let imm = cast(imm).to_i64_sign_extend(); | ||
| emit_and_continue!(Instruction::load_imm64(dst.into(), imm as u64)); | ||
| } | ||
| if let Some(imm64) = parse_imm64(rhs) { | ||
| emit_and_continue!(Instruction::load_imm64(dst.into(), imm64 as u64)); | ||
| } | ||
| } | ||
|
|
||
| if let Some(imm) = parse_imm(rhs) { | ||
| emit_and_continue!(Instruction::load_imm(dst.into(), imm as u32)); | ||
| } | ||
|
|
||
| if let Some(imm64) = parse_imm64(rhs) { | ||
| emit_and_continue!(Instruction::load_imm64(dst.into(), imm64 as u64)); | ||
| } |
There was a problem hiding this comment.
This is partially my fault because of how the load_imm instructions are currently printed out (I need to change it, or you could change it if you want), but here's how it should work:
a0 = $valuein the assembly/disassembly code should always result it exactly the $value being loaded into the register (what you see is what you get)- by default if the immediate can be represented with
load_immthen it always should useload_imm, and only should fall back toload_imm64when it cannot i64prefix should always forceload_imm64load_immcan be used to load immediates between0and0x7fffffff(inclusive), and also any immediates where all upper 33 bits are set (because it sign extends)
So, for example:
a0 = 0xffffffffshould result in0xffffffffbeing assigned, so this must useload_imm64(becauseload_immwill sign extend the value from 32-bits to 64-bits)a0 = 0xffffffff87654321should result in0xffffffff87654321being assigned and should useload_immby default (because all of the upper bits are1s soload_immwith argument0x87654321can be used)a0 = -2should result in0xfffffffffffffffebeing assigned and should useload_immby default (because all of the upper bits are1s soload_immwith argument0xfffffffecan be used)
There was a problem hiding this comment.
@koute Ok, I think I got it now. Can you take a look at the new parse_immediate function and see if it correctly captures the described behaviour?
subotic
changed the title
subotic
force-pushed
the
subotic_add_64_bit_test_programs
branch
from
fdd41f4 to
b631909
Compare
tools/spectool/spec/src/inst_shift_arithmetic_right_imm_alt_64.txt
Outdated
Show resolved
Hide resolved
subotic
force-pushed
the
subotic_add_64_bit_test_programs
branch
2 times, most recently
from
96eca0c to
02de4ef
Compare
fix(spectool): parsing immediates lint fix test
subotic
force-pushed
the
subotic_add_64_bit_test_programs
branch
from
182f559 to
455667b
Compare
