You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that html docs specify loadsp/storesp as 0b011x_xxxx/0b010x_xxxx, but while disassembling hello_world's elf file with objdump (precompiled one from zylin/zpugcc), instruction 0x70 (0b0111_0000) decodes to loadsp 0, when I expected to see loadsp 64 (16 << 2). Clarification on what's happening would be very helpful.
The text was updated successfully, but these errors were encountered:
Bit 4 is inverted for loadsp/storesp index. The documentation is wrong, I'll try to update it.
Meanwhile I have another instruction set reference you might take a look at: http://alvie.com/zpuino/zpu_instructions.html#LOADSP
Reference you gave seem much nicer, I have just 2 remarks/nitpicks. In IM, when idim = 0, pushed value should be sign-extended. And in EMULATE, address of next instruction is pushed on stack, so IMO it should say Push( PC + 1 );
Do you happen to know, why loadsp/storesp flip the upper bit? Can't think of a reason how it would be useful.
The reason is quite simple: it is due to the ADDSP encoding. The ADDSP instruction has bit 4 set to '1'. In order to generate a common offset from LOADSP/STORESP/ADDSP the simplest way (in hardware) is to negate this bit for all SP-relative operations, independenly of the opcode. This saves implementation resources.
I noticed that html docs specify loadsp/storesp as
0b011x_xxxx
/0b010x_xxxx
, but while disassembling hello_world's elf file with objdump (precompiled one from zylin/zpugcc), instruction0x70
(0b0111_0000
) decodes toloadsp 0
, when I expected to seeloadsp 64
(16 << 2). Clarification on what's happening would be very helpful.The text was updated successfully, but these errors were encountered: