-1

I'm reading a textbook which says:

RISC processors have done very well in the market for embedded processors, controlling such systems as cellular telephones, automobile brakes, and Internet appliances. In these applications, saving on cost and power is more important than maintaining backward compatibility.

Does it mean RISC processors (e.g. ARM) are not backward compatible with older versions?

phuclv
  • 37,963
  • 15
  • 156
  • 475
  • which text book? – phuclv Jul 29 '20 at 07:20
  • @phuclv the textbook is CSAPP –  Jul 29 '20 at 07:21
  • 2
    You are reading too much emphasis in this. The reverse of "more important" is *not* "not important". – Jongware Jul 29 '20 at 07:49
  • there is no market use case. why add the waste to the products for something that gives no value? – old_timer Jul 29 '20 at 21:25
  • 1
    If this text is trying to reply that RISC and backwards compatibility are not related, then find a better textbook. You can easily read the arm documentation on the instruction set and find just how much compatibility there is or isnt. – old_timer Jul 29 '20 at 21:26
  • arm makes cores not chips, most of the software that runs no an arm based product has nothing to do with arm nor the instruction set, it is chip/system/os specific, you can to some extent easily swap the arm out for some other core and keep going with relatively minimal code change. – old_timer Jul 29 '20 at 21:27
  • the dos/intel then wintel model was very specific historically and was a win at first but is now not so much, it still keeps those two companies alive but that is crumbling. the software model for those platforms has this notion of I bought a floppy with some files, rather than I bought an application that I download the compiled version that goes with my platform. you dont plug a floppy nor thumb drive nor dvdrom that you bought 10-20-30 years ago into your phone. the pc model is special and unique, not the norm. – old_timer Jul 29 '20 at 21:30
  • you can also look up mips documentation to see how much of the instruction set is or isnt compatible back to the early mips days. – old_timer Jul 29 '20 at 21:31

2 Answers2

1

That's correct; for example on really old ARM, a word load with non-zero low bits meant to rotate an aligned word. On modern ARM, those bits are just part of the address and give you an unaligned load.

So ARM at one point subtly broke compat with rare code which depended on that feature, making those old binaries unusable on modern ARM. Most ARM binaries are still fine because they avoided unaligned word loads/stores entirely.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
  • Thanks for your answer. So why we cannot make RISC processors backward compatibility just like X86-64? –  Aug 08 '20 at 07:42
  • @slowjams: You can if you want to, there just wasn't a market reason to keep backwards compat at the expense of not making improvements that would cause minor incompatibilities. Some other RISC ISAs like MIPS I think did maintain backwards compat for a long time (until MIPS64r6 which reorganized a bunch of opcodes and provided branches without a branch-delay slot.) – Peter Cordes Aug 08 '20 at 14:01
0

Another example is MIPS

Typically when a new ISA version is introduced then instructions are added but old instructions are still left as-is for backward compatibility. For example in x86 many instructions that no one uses for decades are still valid and supported until now. However in MIPS III a few instructions were removed to free up some opcodes. Then after MIPS V when MIPS Technologies split off from SGI, a major overhaul was introduced: MIPS32/MIPS64. The naming scheme was changed and some more instructions were removed

  • some conditional moves
  • branch likely instructions (deprecated in previous releases).
  • integer overflow trapping instructions with 16-bit immediate
  • integer accumulator instructions (together HI/LO registers, moved to the DSP Application-Specific Extension)
  • unaligned load instructions (LWL and LWR), (requiring that most ordinary loads and stores support misaligned access, possibly via trapping and with the addition of a new instruction (BALIGN))

MIPS32/MIPS64

It also "Reorganized the instruction encoding, freeing space for future expansions."

One of the reasons for that is probably because MIPS changed their focus from high performance systems to embedded systems

phuclv
  • 37,963
  • 15
  • 156
  • 475
  • 1
    That opcode reorg didn't come until the 2014 MIPS32r6 / MIPS64r6. Until then, MIPS32 / MIPS64 were close enough to backwards-compatible, at least for user-space code, I think. I thought I remembered Wikipedia being clearer about that, with at least some kind of sub-heading for MIPS32r6 to set it apart earlier MIPS32. – Peter Cordes Aug 10 '20 at 16:54