71–80 of 95 posts
Earlier quoted context omitted.
A number of others you might encounter in your embedded devices: 68k, AVR, Z80. (CISC, RISC, CISC, if you’re curious.)
There’s (sadly) not that much 68k left these days, is there? Do you know of any specific companies still using them? (maybe ones that are hiring? :)
Earlier quoted context omitted.
A number of others you might encounter in your embedded devices: 68k, AVR, Z80. (CISC, RISC, CISC, if you’re curious.)
There’s (sadly) not that much 68k left these days, is there? Do you know of any specific companies still using them? (maybe ones that are hiring? :)
Earlier quoted context omitted.
Yep, I also learned MIPS in my CS class. It's pretty nice to program in.
MIPS is typically seen in computer architecture class because it is simple and regular (at least the original version seen in class). However, for Assembly programming, MIPS, like (almost?) all RISC instructions sets, is tedious. Give me any CISC with a generous range of addressing modes, and I take any day over MIPS/RISC. We can make a parallel between those low-level ISA and high-level languages: a language like Li…
Or how about a macro assembler where you can do that with custom pseudo-instructions?
Earlier quoted context omitted.
MIPS is typically seen in computer architecture class because it is simple and regular (at least the original version seen in class). However, for Assembly programming, MIPS, like (almost?) all RISC instructions sets, is tedious. Give me any CISC with a generous range of addressing modes, and I take any day over MIPS/RISC. We can make a parallel between those low-level ISA and high-level languages: a language like Li…
Traditional addressing modes have been largely abandoned because modern architectures are based on the load-store principle. Simplicity has little to do with it, and referring to that whole shift in design as "complex" vs. "simple" instruction sets is a bit of a misnomer. Besides, well-designed architectures are not exactly lacking in ease-of-use.
I don't think MIPS is going to completely disappear as long as Linux works on it. Someone somewhere in some country will keep making them as long as the licensing situation is more favorable for whatever use than ARM or x86. If the owning company is going bankrupt that means making MIPS CPUs will be cheaper than ARM or x86.
The question it's not if someone will use some old MIPS ISA in a few years from now on, the question is if someone will improve the ISA from now on, in the same way x86 and ARM are consistently being improved.
Some companies are still fabbing old Z80 CPUs, but that's not to say Z80 has a bright future.
In the '90s and early 2000s there were lots of CPUs, computer systems, operating systems.
May be its days are numbered, but MIPS still has significant presence in the low to medium end routers (Mediatek's MT72xx, Atheros AR7xxx so on).
MIPS still has a very large presence in the education sector as well - MIPS asm is very easy to learn because of how consistent it's syntax is and the plethora of open source debuggers as well. Learning MIPS was what originally got me interested in ASM programming since we had a class that was focused on MIPS code and another class that had us build a digital MIPS processor from scratch. The combination of these two…
Its version of 32-bit MIPS is so simple, its whole instruction set fit in a 2-side cheatsheet (the famous "green sheet"). The design of the CPU is quite easy too. Given an instruction and its binary representation, it is almost straightforward to see how each bit contributes to the computation (setting the correct ALU operation, retrieving a value from the correct register, etc.).
Earlier quoted context omitted.
DSPs as well.
And neither can be used as a compilation target for, say, Firefox, (or simpler, nethack) can they ?
Please help me remove some of my ignorance: ARM = RISC? Intel = CISC? ? = MIPS? What else is out there in large amounts?
I assume that all modern CPUs are CISC-ish opcodes running in microcode on a RISC-ish core, and it’s been a few decades since those were useful labels.
It's also a thing to fuse smaller operations into macro-ops in many microarchitectures.
All high performance chips avoid running microcode, it's reserved for eg emulating seldom used legacy instructions. Microcoded CPUs (where all instuctions are implemented with microcode) were a 80s/90s thing.