bug-mes
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-mes] mescc and Load/Store architectures


From: Danny Milosavljevic
Subject: [bug-mes] mescc and Load/Store architectures
Date: Thu, 7 Feb 2019 14:14:44 +0100

Hi,

most of the RISC architectures (ARM, MIPS and PowerPC) are a load/store 
architecture where the RAM is a distant slow peripheral which you need extra 
instructions to access (ARM: LDR to load from memory into register and STR to 
store from register to memory).

Mes seems to assume CISC architecture at least partially and I'm having a hard 
time emulating all the CISC-specific instructions.

Therefore, I wanted to ask whether it's possible to change the compiler not to 
use the most annoying instructions.

The most annoying instructions are:

(1) MOV, ADD or CMP with one op immediate and one op memory.  It would be 
better to have only immediate -> register, register <-> memory transfers (as 
extra instructions).
    Annoying example: add____$i8,0x32
(2) PUSH from immediate directly to stack.  It would be better to have only 
immediate -> register, register <-> memory transfers (as extra instructions).
    Annoying example: push___$i32

Currently I implement (1) in arm.M1 via scratch registers whose value I save 
beforehand and restore afterwards.
But (2) is really ugly because I have to push to the stack to save my scratch 
registers and then push to the stack to save the immediate - which is supposed 
to stay on.  Oops?

Workarounds are possible, but easiest would be to get rid of the need to "save 
the scratch registers in arm.M1".
The best way to do that would be to move the decision which scratch registers 
to use into the compiler - it probably already does similar things anyway.

What do you think?

(1)

# e92d0005        push    {r0, r2}
# e5910000        ldr     r0, [r1]
# e59f200c        ldr     r2, [pc, #12]   ; 1c <X2>
# e0800002        add     r0, r0, r2
# e5810000        str     r0, [r1]
# e8bd0005        pop     {r0, r2}
# ea000000        b       20 <Y2>
# X2: data
# Y2:
DEFINE add____$i32,(%r1) 
e92d0005e5910000e59f200ce0800002e5810000e8bd0005ea000000

Attachment: pgphvkto6Zhw7.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]