5 ms·

Would I be very wrong to suspect that early RISC CPUs forced programmers and compilers to pull similar stunts? The major difference was probably that RISC syste

• Turing_Machine 4y ago
  There were numerous compilers for the 6502.
  • sllabres 4y ago
    I'll remember well UCSD Pascal https://en.wikipedia.org/wiki/UCSD_Pascal https://en.wikipedia.org/wiki/UCSD_Pascal especially as compiling on a system with one floppy drive required 5-6 changes of the floppy disk even for a 'hello world'. So one would think twice before starting the compiler only to find a simple syntax error after a minute or two. :)
  • dwheeler 4y ago
    Absolutely true, there were and are MANY compilers for the 6502. However, the 6502 was a challenge to implement high-level languages on, IF you also wanted speed and small code size. But since the 6502s were slow compared to modern chips, and could only address 64KiB directly, you typically also wanted speed and small size. I posted some links to some approaches here: https://dwheeler.com/6502/ https://dwheeler.com/6502/
    • buescher 4y ago
      I always thought Action! was very crisply tailored to these small systems. It turns out to have been a port of a language called Micro-SPL from the Xerox Alto that (originally) targeted the Alto microcode directly. Atalan and Plasma look nice.
  • kjs3 4y ago
    Sure...they were amazingly widespread machines back in the day so lots of people took a whack at a 6502 compiler (at college if nothing else). But how many could take on non-trivial programs and emit code that would be considered production level? I know Apple Pascal was supposed to be pretty good, but what else?
    • buescher 4y ago
      I am pretty sure there were at least a couple of commercial games and applications written in valFORTH on the Atari 800. Possibly Action! also; for some reason I thought Paperclip was written in Action! but apparently not. There were a lot of magazine games and utilities written in Action!, though.
• kevin_thibedeau 4y ago
  Hardware mul/div is still not universal on new products.
  • cbm-vic-20 4y ago
    RISC-V doesn't have hardware mul/div in it's baseline spec. There's a "Zmmul" extension that adds mul, and the full "M" extension which includes mul/div. Technically, those extensions are optional, but I think most current hardware implementations include them.
    • kjs3 4y ago
      That's...very weird I guess? Hardware mul/div requires so little chip real-estate relative to the whole die these days, and has such obvious advantage, why did they make it optional?
      • shadowofneptune 4y ago
        The point of the baseline spec, as far as I know, is to make a modern chip design that even the smallest fab or ASIC can build on its own.
      • spc476 4y ago
        I wrote almost nothing but assembly for ten years (mid 80s to mid 90s) and I think I can count on one hand the number of times I actually needed a generalized multiplication/division instruction. Heck, even square root could be done with repeated subtraction which could be Good Enough(TM), or maybe a lookup table.
      • kragen 4y ago
        The SeRV implementation of RISC-V fits into 200 4-LUTs on an ICE40 FPGA. If your FPGA doesn't have a multiplier, how many 4-LUTs do you need to build a 32x32 multiplier? I'm guessing the answer is comparable to 200.
        • kjs3 4y ago
• dietrichepp 4y ago
  Yes, the first generation of SPARC and MIPS processors also lacked multiply and divide. Processors are still made without multiply and divide. I think we should look at the culture of programming around architectures like SPARC and MIPS and what kind of assumptions the designers had about how people would program them. Even though you could find compilers for 6502, and you could write assembly for MIPS and SPARC, assembly programming was de rigueur for 6502 and it was not for MIPS and SPARC. 6502 systems are typically cheap and have small amounts of memory, and the architecture is a bit weird if your targeting a C compiler (inconvenient 256 byte stack, for example). MIPS and SPARC systems didn't appear until the late 1980s, they tended to have much larger amounts of memory, and it was assumed that you would use C (or something else). SPARC and MIPS may have also omitted the multiply instruction in an attempt to make it so the processor could execute one operation per cycle for nearly every instruction.
  • cbm-vic-20 4y ago
    The successor to the 6502, the 65816 (both of which are still currently available as new parts from WDC) is a lot more compiler-friendly than the 6502, but is still pretty weird by "real" RISC standards.
    • pcwalton 4y ago
      The 65816 has stack-relative addressing, and a relocatable direct page which can act as a sort of frame pointer, but it's still a far cry from being compiler-friendly. Severe annoyances include the painful lack of registers, having 8 and 16 bit be a global mode switch instead of just specifying the size in the instruction, lack of a barrel shifter, and the near/far pointer distinction. There's a reason why there have never been successful ports of GCC or LLVM to that architecture, even out of tree.
      • adamius 4y ago
        That's a little less true about LLVM. https://llvm-mos.org/wiki/Welcome https://llvm-mos.org/wiki/Welcome They seem fairly sure that llvm can be convinced to support a 6502 target. As for gcc, I'm fairly sure gcc has at least one out-of-tree but yeah perhaps the code wasn't as good as hand rolled.
• shellac 4y ago
  One of the joys of moving from the 6502 BBC micro to the Acorn Archimedes was the Acorn RISC machine had a multiply. It felt like cheating. (They used ARM2 which added MUL and MLA - multiply with accumulate)
• kjs3 4y ago
  Yes and no. Regardless of what early RISCs lacked relative to the 6502 (and other contemporaries), they were generally much fast overall, operated on wider words (32 v 8 bit) and had access to vastly larger memories. So there were often analogous workarounds, but different in details. For example, replacing calculating sine with a lookup table is much easier and more accurate when you can toss it someplace in your 16MB or whatever of memory rather than try and shoehorn it into 64k.
• logicalshift 4y ago
  The main difference between the ARM1 (which was never sold in any quantity) and the ARM2 was the addition of the multiply instruction (and the multiply and accumulate instruction). They were the only multi-cycle arithmetic operation they had, and what's more you couldn't load arbitrary constants into a register with the MOV instruction or use constants with the multiply instruction itself so they were still a bit inconvenient as well as comparatively slow. But you could write: MOV R1, #3 MUL R0, R0, R1 In spite of the limitations, this gave the instruction set a certain 68000 quality to it (except much faster for a given clock speed). To multiply the number in R0 by 3, which was pretty convenient. The ARM had a thing called the barrel shifter though, which let you add an arbitrary shift to the last operand of any arithmetic operation. All arithmetic ops take 1 processor cycle, so you could write this instead to multiply by 3 in a single cycle: ADD R0, R0, R0, LSL #1 Ie, add R0 to itself multiplied by 2. Constant divisions could be constructed with the SUB instruction too. Some constants required multiple instructions (but I think the maximum was something like 4 or 5 instructions for any constant? I wrote an assembler that could figure this out for you automatically in the mid-90s so I used to know for sure). This is basically a single-instruction version of the 6502 trick (handy, because the first OS for the ARM was a hurried port of a 6502 operating system), which sort of fits with the ARM's original inspiration as being a 32-bit version of the 6502. As each instruction completes in one CPU cycle, the ARM could have fairly monstrous integer performance for the mid to late 80s if you knew how to program it.
• mhh__ 4y ago
  Forget early RISC, the DEC Alpha didn't have a divide instruction - I only learnt that a few days ago.