1

Are there any good practices for optimizing and micro-optimizing EFI Byte code (or bytecode in general) for speed given that instructions are executed in strict order? Like maybe one instruction is always faster (even if it's longer) than two consecutive or something.

For example, will

MOVIqq R1, -1 ; (10 bytes)

still be faster than

XOR64 R1, R1 ; (2 bytes)
NOT64 R1, R1 ; (2 bytes)

or will

MOVIqq R1, -10 ; (10 bytes)

still be faster than

MOVIww R1, -10  ; (4 bytes)
EXTNDW64 R1, R1 ; (2 bytes)

Is it preferable to use 64-bit variants over 32-bit when possible or not? (XOR32 R1, R1, which zero-extends to 64 bits vs XOR64 R1, R1)

Unfortunately I cannot test different implementations myself on a variety of EBC VM implementations to get empirical data. Only hope that it's not strictly implementation dependent and some general rules exist and may be applied.

Improve this question
2
  • EFI byte code doesn't have a 7-byte mov r64, sign-extended-imm32 the way x86-64 machine code does? If it's interpreted, I'd assume that 2 instructions are slower than 1, even if the one is much bigger.
    – Peter Cordes
    Commented Dec 2, 2017 at 11:42
  • 1
    If microoptimizations like the ones you're describing actually make a difference then you shouldn't be using EBC. Native code will be an order of magnitude or more faster. EBC is meant for EFI drivers where performance doesn't matter much because they're only used at boot time and because performance will be I/O bound anyways.
    – Ross Ridge
    Commented Dec 2, 2017 at 18:57
Related questions
2
EFI or BIOS in intel atom??.
2
UEFI BootLoader
0
UEFI file systems GUIDs and firmware
Load 7 more related questions Show fewer related questions

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.