3 ms·

I find it hard to believe that you wouldn't know how many registers code should use. However - it's not C code, it's assembly code, so it seems unfair to blame

• matttah 17y ago
  register allocation is a notoriously hard problem. To make matters worse, registers on different architectures have vastly different properties.
  • rbanffy 17y ago
    Wouldn't it be simple in SPARC-like architectures with register windows?
• yuvi 17y ago
  There are a couple reasons you wouldn't know that (for an entire inline asm function): 1. x86_64 vs. x86_32. It's possible that you'd want to use more registers than 32-bit has. In this case, it's usually optimal to use memory operands on x86_32 but registers on x86_64. 2. gcc _will not_ allow you to use ebx in inline asm with PIC code. Likewise with ebp with frame pointer. There's no technical reason gcc couldn't just save+restore those registers around the block, but it doesn't. 3. The case in the bugreport: you have various locations in memory you want to address, and you want gcc to figure out their addresses for you. Without analysis that eliminates identical registers, the naive implementation of using 1-2 new registers per operand will quickly fail.
  • viraptor 17y ago
    > There's no technical reason gcc couldn't just save+restore those registers around the block, but it doesn't. While it's not impossible to do, it makes debugging a lot harder. gdb would have a much harder job of figuring out what's going on if the code messed with ebp, since the fp location would depend on the code. Some more debug information to describe that location could solve the problem... but why create that problem in the first place.