Binary to binary translators won't like it. E.g. translating
RISC-V binaries to x86.
--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAMU%2BEkyBCMxV8NSFjucMFrkneV2vFffk-QZc%2Brz-091bArh-ew%40mail.gmail.com.
Binary to binary translators won't like it. E.g. translating RISC-V binaries to x86.
On 26-Dec-17 12:32, Bruce Hoult wrote:
If you are compiling an IF/THEN/ELSE and it happens that the ELSE part can be done with a single 16-bit instruction, instead of ending the THEN part with a branch around the ELSE, you could instead emit 0x0037.
This creates an "lui x0,#imm20" instruction (which is a no-op) that includes the single RVC instruction in the ELSE part inside the imm20.
Useful? Too dirty to live? Will it break and/or slow down any likely microarchitecture?
--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAMU%2BEkyBCMxV8NSFjucMFrkneV2vFffk-QZc%2Brz-091bArh-ew%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/10d531ca-94c9-f4a1-0c62-c7740dcae626%40gmail.com.
On Tue, Dec 26, 2017 at 2:16 PM, Cesar Eduardo Barros
<ces...@cesarb.eti.br> wrote:
> I'd expect simpler cores which decode one instruction at a time to not have
> any slowdown, and little if any speedup (unconditional jumps can be
Without defending the idea, historically, the point for this trick is
to save space, not to make things faster. This is a *VERY* commonly
used technique to pack maximum amount of code into limited ROM space
for Z80 and 6502 systems (e.g.,
http://6502.org/tutorials/6502opcodes.html#BIT). It's at least
partially responsible for enabling complete BASIC implementations,
with floating point support, on Z80 systems with only 16KB of ROM.
On something like the E310 chip, with only 16KB of scratchpad RAM,
this might be a valuable trick to apply for code placed in that RAM,
especially considering the code density of RISC-V is about 2x-3x
poorer than a Z80.
On Tue, Dec 26, 2017 at 4:09 PM, Bruce Hoult <br...@hoult.org> wrote:
> I'd like to see some evidence for that!
This is based on my port of eForth to the RV64I ISA. eForth for Z80
can readily fit in 16KB of space, while mine requires 34KB.
> On https://github.com/deater/ll_asm Z80 comes in 8% smaller than E310 code
> (RV32IMC). 6502 is 18% bigger than RISC-V.
Cute; but, I prefer to see more serious programs, however.