Meet ARM1, grandfather of today's mobe, tablet CPUs – watch it crunch code live in a browser Chip geeks have produced an interactive blueprint of the ARM1 – the granddaddy of the processor cores powering billions of gadgets today, from Apple iPhones to Raspberry Pis, cameras, routers and Android tablets. The peeps behind the fascinating blog visual6502.org normally reverse-engineer chips by pulling the silicon out of …
Hehe... Blast from the past - full OS level record management in file IO. The app developer had no clue what is going on behind the scenes, VMS was managing it all for them including by default revisioning the file on each open for write. So if it decided to do the actual writes as variable size, the app developer would have had no clue of that - it would have looked like ordinary record retrieval to the application.
The end result was the most insane open() syntax known to man. My recollections were that it took 5+ lines of optional args to open a file in VMS Pascal.
However - as VMS had the record management - almost any program could read almost any file - the record attributes were stored in the file header and an open() call without optional parameters used the attributes in the file header to read the file correctly. (None of the mess that is in Windows where some text files open correctly in Notepad - others need Wordpad.) From (very old) memory - ordinary variable length record text files needed no optional parameters - fixed length record files needed 2 parameters (type = fixed length and the length of each record) - it could however get messy if you were creating indexed files (but a sequential read of an indexed file could be performed by almost any program).
The really bad case was reading a foreign (not created by VMS) binary file where everything had to be specified as the OS did not have valid data in the file header.
Yes, VMS files came in the proverbial 57 varieties. This was all well documented, but few people ever consulted the manuals, Many programmers got confused and made mistakes.
It was as confusing as the old George 3 file varieties: graphic mode (for all-capitals text), normal mode (quite rare, upper and lower case), and allchars (normal plus control characters).
>Eventually, about 18 months later, they produced the ARM1 – a tiny, efficient CPU fabricated by VLSI Technology with fewer than 25,000 gates using a 3,000nm (3μm) process. Today, a quad-core Intel Skylake Core i7 processor, with builtin GPU, has 1,350,000,000 gates using a 14nm process.
Why not compare it to the Exynos 8890, Snapdragon 820, Kirin 950, or Mediatek Helio X20 instead of an x86 flagship chip?
Then if there is a gate/block level of this available then you have everything you need to cover simple logic gates on silicon all the way you to virtualised machines.
I have spent some time trying to gather z80 material to do this but Zilog no longer have the original ccts etc. But this and GCC etc and you have it all.
~~ My chip articles bring the pedants to the yard. And they're like, our knowledge is better than yours. We can teach you but we have to charge. ~~
It's fixed, ta. Once upon a time I used VLSI design software to layout gates and doping regions and cells and metallization layers and, arrgh, I thought I'd erased all that from my mind.
C.
that rang a bell too - found it right here:
"Deeply puzzling, though, was the reading on the multimeter connected in series with the power supply. The needle was at zero: the processor seemed to be consuming no power whatsoever.
As Wilson tells it: “The development board plugged the chip into had a fault: there was no current being sent down the power supply lines at all. The processor was actually running on leakage from the logic circuits. "
The history of Acorn and ICL presents two wonderful examples of politicians being utterly clueless at IT policy. Gordon Brown flogging off the gold reserves was trivial in comparison. ARM today is barely a medium size company, but its potential was to be the next Intel.
If one looked purely at each instruction set and where computing has recently gone nobody in there right mind would pick Intel with their POS x86 to be the 800lb guerilla. ARM has kept the core of their (imho superior) instruction set intact and grown a successful business with it for a few decades. Intel has tried repeatedly to kill their abomination but the market won't let them (a market that has rewarded them very handsomely until lately). Guess its been a good thing Intel has been a generation ahead of everyone else in fab technology (the real reason to Intel's success) which is how they made it work in most spaces historically. Sadly now that chips are fast enough and becoming a commodity that overhead is killing Intel and making ARM look real pretty indeed. ARM lets the companies that know how to do high volume low margin manufacturing do the heavy lifting and then they get their (rather fair) cut.
Also I am aware that the x86 IS has been emulated in hardware since the mid 1990s but even with emulation Intel with their state of the art fabbing as been unable until very recently to compete with ARM on mobile with x86. Also beware as it looks like one of El Reg's adverts (only page I had open at time) decided to try and serve up malware to me due to not remembering to run through privoxy (and NoScript on full blast) like I regularly do. Of course with me running Tails in a VM straight off an ISO file with no persistent storage and it flashing up obviously fake firefox out of date warrnings trying to run MalwarePretendingToUpdateFirefox.exe it wasn't going to get far. I just reset the VM as opposed to trying debug but wasn't real happy to see.
I'm not actually sure why people care so much about the instruction set.
When everyone had to code in assembly it mattered.. now that decent quality C compilers are available for free the 10 or so lines of assembly most (even low level embedded guys) programmers have to come up with every other year means the underlying assembly language means very little.
Since humans don't care about the prettyness of the assembly language anymore surely code density etc should matter much more..
You say the only reason Intel are "winning" is that they have the latest fab technology. Well the only reason ARM cores ship as many units as they do is that they can be produced on old production lines.
Don't get me wrong. I like ARM but not because I'm in love with their instruction set. They are one of the few companies that make information on things like how debugging works over JTAG etc available so there is a decent ecosystem of free tools to work with ARM cores. On the other hand I'm not going to poo poo Intel based on some childish dislike of their instruction set. If there weren't significantly faster Intel machines out there developing for ARM machines would be many many times less productive.
Because, AC, the instruction set is what your ultra high level wysiwyg code gets compiled into, so:
1) Understanding the IS helps a competent programmer write efficient code
2) No matter how good your code and compiler is, if the target is a heinous kludge like x86, your binaries will flop out bigger, slower and kludgier than if they'd been made for a more elegant architecture
>No
My own real world tests show that ARM binaries are 10-15% bigger than x86 ones.
You have to mix ARM and thumb in the same binary to get decent code density and performance.. so you move the nasty kludges from the instruction decoding in the CPU into the binaries.
And here I was thinking the ARM instruction set is some of gift from $deity that is perfect in every way.
Have an upvote for the PDP-11, but the Alpha ISA was more perfect. :)
Much as I love the -11, the Alpha's big collection of 64bit registers did make it's pretty easy to write *fast* assembler - in practice the compilers were pretty good too. I did debug a few bits of rabid C code I'd never seen before in no time flat by looking at the disassembled output and mapping it back to the source - the ISA made the compiler output trivial to map back to the source. I do miss that somtimes. :)
As of 1992 on a particular bit set of benchmarks we ran the smallest code generated was for the INMOS T800, the x86 binaries were 30% bigger. The INMOS chips used a cute instruction encoding that made a lot of common ops single byte instructions, it was handy when you were trying to cram everything into the 1-4kb of on-board single cycle memory. ;)
>'x86 has much better code density than ARM.'
Whether that is true or not is only somewhat relevant. Even if the code density is higher if it takes a lot more chip real estate to implement the instruction set and it can only be implemented somewhat efficiently its still going to use more energy and run hotter which is exactly what you want to avoid for mobile (and in the datacenter as well). From what I understand x86 is such a dog for mobile even emulating puts Intel at such a disadvantage it took them a herculean effort to finally even compete wtih ARM (and still not in ultra low power last I heard). What they are finding though is competing with ARM is not like competing with AMD. The payoff are not the type of margins Intel is used to.
>Whether that is true or not is only somewhat relevant.
>Even if the code density is higher
Code density is a good benchmark of the "goodness" of an ISA that doesn't basically boil down to "it's good because I like it, that makes it good". Code density is such a big problem ARM have an alternative instruction set in their chips to make up for the main one.
>if it takes a lot more chip real estate
>to implement the instruction set
And that matters to end users because? The number of transistors Intel have to squeeze onto a chip does not keep me awake a night. There are lots and lots of products out in the real world that use ARM Cortex M? parts to implement stuff that could have been done with discreet logic or a 555 timer instead. Baby Jesus doesn't weep when a transistor is wasted.
>and it can only be implemented somewhat efficiently its still going to use more energy
>and run hotter which is exactly what you want to avoid for mobile
But not every machine in the world is mobile. Imagine developing for mobile/embedded platforms if you didn't have a hideous x86 box doing the grunt work of compiling all the tools and code for the target? The only reason mobile is works is because there are smelly x86 boxes on the desk and in the cloud doing the grunt work.
>From what I understand x86 is such a dog for mobile even emulating puts Intel
So you don't actually know. You read this "fact" somewhere and use it in your little rants against x86 without really knowing what you are talking about.
Intel's desktop x86 chips kick even ARM's latest stuff in the balls. Decent performance is not a disadvantage for mobile. If Intel could get an i7 class chip into the energy budget for a phone they would have a winner on their hands.
The problem for Intel apparently is that they can't retain the performance without breaking the energy budget (they seem to be making some progress though..). It's like performance increases complexity which in turn increases the required energy! Who would have thunk it!
The emulation point brings nothing to the table. Intel need an ARM emulator because of ARM's hold on the market. Emulation is processor intensive. ARM's ISA is no better at it.
>The payoff are not the type of margins Intel is used to.
ARM is a fabless semiconductor company that licenses designs with good energy performance and acceptable execution performance at low low prices and chips based on their designs can be produced on fabs that are a lot cheaper than what Intel is using for their top of the range lines. I'm not sure how Intel thought they'd have a chance at breaking into ARM's core business and make any money in the process. I'm sure they have seen shrinking shipments of their high performance lines and thought they need to make a move. Intel's attempt to get back into the microcontroller market with their Quark stuff is equally laughable.
But either way Intel's bad business decisions doesn't make x86 "bad".
" Imagine developing for mobile/embedded platforms if you didn't have a hideous x86 box doing the grunt work of compiling all the tools and code for the target?"
If there was any doubt where you were coming from, it's clear now. And it's not a good place.
Lots of people don't have to *imagine* not using "hideous x86 box grunt work of compiling all the tools and code for the target". Lots of people have done it, yea even unto the days of PDP11s. There are still people using stuff other than x86 too, but the typical IT department's dependence on x86 means there aren't as many cross-tool setups on Unix, VMS, etc, as there used to be.
If x86 is so brilliant in general, why is it near invisible outside the IT department?
>If there was any doubt where you were coming from, it's clear now. And it's not a good place.
Please do forget to mention where that place actually is.
>Lots of people don't have to *imagine* not using "hideous x86 box grunt
>work of compiling all the tools and code for the target".
Because they don't do work in a field that requires them to do lots of compiling, data processing etc.
But they'll consume content that has been processed by machines many times more powerful than their "mobile" device multiple times a day.
>There are still people using stuff other than x86 too, but the
On the desktop? Are there any desktop machines shipping in volume that aren't x86? The only ones I can think of are chromebooks and they aren't exactly winning any ass kicking competitions.
>typical IT department's dependence on
IT departments - The be all and end all of people that think that their job fixing printers is "working in high technology"
>Unix, VMS, etc, as there used to be.
Unix doesn't run on x86? You better tell that to all the Unix vendors that ported their breed of Unix to x86 as soon as they realised fast commodity priced x86 hardware was going to ruin their RISC party.
>If x86 is so brilliant in general, why is it near invisible outside the IT department?
Who said it's so brilliant? All I'm saying is it's not the ISIS of instruction sets and it's not like ARM is some amazing super technology sent from heaven to save us all. It's horses for courses.
If you want your desktop machine to be limited to performance levels of 5 years ago and only able to access a quarter of the RAM that my core i7 setup does knock yourself out.. but I'll be keeping my commodity machine with 32GB of RAM kthnxbye.
And not exactly invisible outside of the IT department unless your job fixing printers involves printers attached to machines that consume multiple rooms:
https://en.wikipedia.org/wiki/Supercomputer#/media/File:Processor_families_in_TOP500_supercomputers.svg
Leaving a lot out to keep this short.
>The number of transistors Intel have to squeeze onto a chip does not keep me awake a night
No but it does very much affect the performance/energy trade off you allude to later.
>But not every machine in the world is mobile.
> I'm not sure how Intel thought they'd have a chance at breaking into ARM's core business and make any money in the process.
Mobile is the only segment still with decent growth which is why Intel is panicking. They are having their Kodak moment.
>But either way Intel's bad business decisions doesn't make x86 "bad".
Like I said nobody hates x86 more than Intel does, which is why they have tried repeatedly to kill it. It really has held them back in many ways even if it buttered their bread for decades. x86 is a prime example of how its not always the best product winning the market (Motorola ISA were so much better in the early days) but the one in the right place at the right time and most important at the right price.
Just to add.
>x86 is a prime example of how its not always the best product winning the market
Few product lines ever have had a stronger network effect which is why it won the day and carried Intel to be one of the 30 biggest companies in the world but ironically may end up dragging it down to its doom as well.
"nobody hates x86 more than Intel does"
Citation welcome. The story isn't quite as simple as that.
In the mid/late 1990s patent wars between Intel and DEC, Intel could have ended up with ownership of the Alpha architecture if they'd wanted to, or at least as an Alpha licencee (like Samsung were). As owners of Alpha they could also have had one implementation that was almost an SoC before most industry folk knew SoCs existed (the 21066). In addition Intel could also have ended up with ownership of DEC's StrongARM designs and designers (which they did) and carried on with them (which they didn't, not in any serious way).
Intel HQ chose to carry on their own sweet way with IA64 ("because 64bit x86 is impossible and IA64 is the answer"). Sadly high end DEC systems (by then Compaq systems) were among those drinking the IA64 KoolAid, and the Alpha fell by the wayside, despite very prescient stuff like this slightly-techy 1999 whitepaper from DEC's Alpha people explaining why IA64 would fail:
http://www.cs.trinity.edu/~mlewis/CSCI3294-F01/Papers/alpha_ia64.pdf
Then when AMD showed that x86-64 was not only possible but practical and popular, Intel HQ finally realised that "industry standard 64-bit" meant AMD64 not IA64 (and not Alpha or MIPS or Power or SPARC). But the IA64 lived on alongside x86-64 for a while, even though everyone with a clue knew IA64 was going nowhere.
Alongside all that, Intel HQ chose not to retain and enhance the StrongARM designs (and people) they did end up with in 1997, they chose to sell them off to Marvell and carry on down the x86 road.
If those are signs of hating x86, you could have fooled me.
Btw, much of this "x86 vs the rest" stuff could be, and was, written ten years or so ago. Ten years after, Intel still haven't got with the SoC programme (there's more to this than "mobile", as in mobile phones/tablets/etc).
E.g.
http://www.theregister.co.uk/2006/06/27/intel_sells_xscale/
"Intel is to flog off its XScale [nee StrongARM] processor operation, the chip giant said today. The move paves the way for it to push low-power x86 CPUs at mobile phone and PDA makers. The buyer is comms chip company Marvell Technology Group, which is paying $600m cash for the product line and taking on "certain liabilities"."
and (the following day)
http://www.theregister.co.uk/2006/06/28/intel_mobile_failure/
"Intel's name looks forever to be associated with the PC, now that it's ended a nine year dalliance with the phone business. The firesale of its 1,400 strong XScale processor division, and the write down of its cellular investments, means that Intel has passed up the chance to play in the largest volume chip market of them all. There are 2bn mobile phones in the world, and in many emerging markets the phone is the only computing device likely to achieve ubiquity."
Intel: the x86 company, now and always.
All good points AC about Intel shitting the bed on moving away from x86. Intel of course suffers from a legendary case of not invented here like many companies so yes they have recognized the weaknesses from time to time in x86 but they haven been damned if they were going to use somebody else's solution. The exception being AMD64 but that was an existential crisis which Intel might be looking at again.
"an existential crisis which Intel might be looking at again."
Intel need to get with the programme with respect to "System on Chip" designs, implementations, and business practices - there's more to "mobile" than the instruction set, even with $100/chip sold "contra revenue".
Without that change in direction, Intel are just continuing on the way to eventually being just another Power or SPARC class vendor, watching the desktop/laptop client sector becoming more and more a niche market, leaving "just" Xeon-class stuff supporing Intel and paying for their next two generations of chips and chip factories which they currently fund in part from volume desktop/laptop chip sales.
Intel won't have the embedded capability of Power or the IBM mainframe business, or the open architectureness of SPARC. (Apologies to Alpha and MIPS but for various reasons I think their time has probably passed).
ICBW, but I don't see where else Intel are headed (or have been headed for a few years). They've a few dollars in the bank so they'll be OK for a little while.
"Intel need to get with the programme with respect to "System on Chip" designs, implementations, and business practices"
Apparently Intel HQ agree:
http://www.theregister.co.uk/2015/11/23/intel_hires_qualcomms_compute_leader_to_lead_new_mobile_push/
" Intel has hired Doctor Venkata “Murthy” Renduchintala.
The new hire was until recently executive veep and president of Qualcomm's mobile and computing division, in other words Intel's nemesis as Chipzilla tried and failed to make a dent in mobile devices. For having pulled off that feat, Renduchintala gets to head Intel's new “Client and Internet of Things (IoT) Businesses and Systems Architecture Group.”"
Without that change in direction, Intel are just continuing on the way to eventually being just another Power or SPARC class vendor,
Problem is this: Should Intel come up with a really revolutionary design, a true "x86-killer", the net present value of their existing x86 IP and x86 product portfolio will rapidly drop towards Zero.
The designers of the "x86-zombie-killer" would be "Destroying Shareholder Value" - and most of that IP is probably mortgaged & those bonds leveraged 50:1 so they might be flirting with bankruptcy even. By doing better!!
That kind of change is not the kind of initiative that comes "from the top"; this can only happen when some rogue tech team manage to design the new technology "in stealth mode" and manage to push it out of the door *before* the accountants and the board can sabotage it!
"The top" likes to talk a lot about such new revolutions, to placate investors and look good and "up with the trend" reality is: They want the existing product range, but slightly better, anything *competing* with the viability of the existing products will be sabotaged or killed directly.
AC wrote: 'Code density is a good benchmark of the "goodness" of an ISA that doesn't basically boil down to "it's good because I like it, that makes it good".'
Code density is only one dimension of "goodness", and it is one of the hardest to measure. If you measure compiled code, the density depends as much on the compiler (and optimisation flags) as it does on the processor, and if you measure hand-written code, it depends a lot on whether the code was written for compactness or speed and how much effort the programmer put into this. So you should expect 10-20% error on such benchmarks. Also, for very large programs, the difference in code density is provably negligible: You can write an emulator for the more compact code in constant space, and the larger the code is, the smaller a proportion of the code size is taken by the emulator. This is basically what byte code formats (such as JVM) are for.
I agree that the original ARM ISA is not "optimal" when it comes to code density, but it was in the same ballpark as 80386 (using 32-bit code). The main reason ARM made an effort to further reduce code size and Intel did not was because ARM targeted small embedded systems and Intel targeted PCs and servers, where code density is not so important. Also, Thumb was designed for use on systems where the data bus was 8 or 16-bits wide, so having to read only 16 bits per instruction sped up code execution. The original ARM was not designed for code density, but for simplicity and speed.
>Citation welcome
https://lwn.net/Articles/647636/
"The SuperH architecture is so dense that a 2009 research paper [PDF] plotted it ahead of every architecture other than x86, x86_64, and CRIS v32. ARM even licensed the SuperH patent portfolio to create its Thumb instruction set in the mid-1990s."
The claim apparently comes from one of the guys that designed the SH2 and holds/held the patents which relate to instruct length and code density.
"The SuperH architecture is so dense that a 2009 research paper [PDF] plotted it ahead of every architecture other than x86, x86_64, and CRIS v32"
Thanks for the lwn link.
According to the graphs in the referenced PDF, there's not much density difference between SH3 and its close competitors. The generic features which contribute to code density are covered in reasonable depth but reasons for *SH3 specifically* being a winner are barely touched on, which is a shame. The expiration of patents seems to be a major reason for looking again at SH3 to create an open source processor design. All that being said, a comment on the LWN article says:
"There has been further code density work since that 2009 paper, and SH3 is now beaten by a few others including THUMB and THUMB2.
http://www.deater.net/weave/vmwprod/asm/ll/ll.html
That's partly because I've spent more time on ARM platforms lately; I haven't had a reason to go back and re-optimize SH3."
ARM has sufficient advantages that for many (most?) purposes it wins volume applications without much debate. Not all of them, but lots. Code density is just one of many factors to be looked at when choosing a chip.
>ARM has sufficient advantages that for many (most?) purposes it
>wins volume applications without much debate.
If you need millions of chips on the cheap you need something you can produce with high yields for the lowest cost possible and ARM fits that market. Some of the other poster's arguments are like comparing the top of the range Intel product and the top of the range ARM design with an F1 car with a relatively fast commodity car but thinking the ARM design is the F1 car because of some preconceived notions about the ARM/RISC designs being "betterer".
>Code density is just one of many factors to be
>looked at when choosing a chip.
Exactly. If I have a power budget of a few nano amps in standby and a processing requirement of blinking an LED once a second or so fully active then having something more complex than an 8bit microcontroller would be insane. But does the fact that the 8bit controller does that job with less power than a full computer could make the full computer ISIS of the instruction stream processing world? Nope. Code density, performance per watt etc are things we can actually look at and compare and probably notice that increasing one metric causes another desirable metric to suffer. "I liked the way that it was it basic enough that even I could code for it" isn't something we can work with to objectively decide.
When everyone had to code in assembly it mattered.. now that decent quality C compilers are available for free ....
1) Never done a Board Support Package before, have we laddie?
2) The people doing the GCC versions (some may argue about quality here) are most certainly writing the assembly that the compiler tool-chain will splurge from the C source; Simple instruction sets makes their job easier which makes your C-code work better.
>ARM has kept the core of their (imho superior) instruction set intact
and this is simply not true. There are differences between the different ARM instruction sets i.e. some versions can handle unaligned accesses for some instructions that others can't.
Then you have the fact what people call "ARM" is a combination of the base instruction set, optional extensions and different FPU configurations. Until the cortex A stuff happened and the FPU stuff became a little bit saner you basically had to avoid using the FPU if you wanted your binaries to work on more than one ARM machine.
Asdf wrote: " Intel has tried repeatedly to kill their abomination but the market won't let them"
That is mainly because the processors that Intel designed to replace the x86 were utter crap. Most people vaguely remember the Itanium failure, but few these days recall the iAPX 432, which was supposed to replace the 8080. Due to delays, Intel decided to make a "stop-gap" solution called 8086 for use until the 432 was ready. While Intel managed to make functional 432 processors, they ran extremely slow, partly because of an object-oriented data model and partly due to bit-level alignment of data access. Parts of the memory-protection hardware made it into the 80286 and later x86 designs, but the rest was scrapped. Itanium did not do much better, so Intel had to copy AMD's 64-bit x86 design, which must have been a blow to their pride.
If Intel had designed a simple 32-bit processor back in the early 1980s, ARM probably would not have been. Acorn designed the ARM not because they wanted to compete with x86 and other processors, but because they were not satisfied with the current commercial selection of 16/32 bit microprocessor (mainly Intel 8086, Motorola 68000, Zilog Z8000 and National 32016). If there had been a good and cheap 16/32-bit design commercially available, Acorn would have picked that.
Being a BBC-ist I went straight from 6502 to ARM2.
The first thing that wowed me was all those (then 24bit addressing) registers, but what really blew me away was that you use any of them for any function - and the instruction set was short enough to be almost instantly memorable!
I'd like to see them take on the transputer chip. Remember it? Great RISC potential, killed
The death of the transputer has been greatly exaggerated...
If you've got a digital TV decoder, there's a good chance it's got a transputer core running the decode hardware.
Vic.
[ Former ST employee ]
I used to love Arm assembler coding. Each instruction exactly the same size, pipelined in a humanly understandable way. The instruction MLA amazed me at the time - multiply two different registers and add a third, then store it in a forth. RISC made CISC processors look like a joke, with their internal microcode burning away power.
There is a worrying amount of coders out there that couldn't give a shit about that of course, their wasteful programs chomping up resources like it's infinite - and these fucking idiots wonder why things crash after a few hours! ;p
"I used to love Arm assembler coding. Each instruction exactly the same size, pipelined in a humanly understandable way."
I have a feeling the humanely understandable pipeline you imagine is the ideal representation of the processor's pipeline that was in the programmers manual and not the reality. This stuff is hard to get right even for basic RISC designs. Look at chip errata for a bunch of different chips and you'll find "certain instruction sequence locks up processor" more than once.
"The instruction MLA amazed me at the time - multiply two different registers and add a third, then store it in a forth."
That sounds like a fairly complex instruction to actually implement. I hope they had a good reason to add that to the instruction set. The whole point of RISC is to avoid overly complex instructions in the hope that you can push more of them through the pipeline faster.
"RISC made CISC processors look like a joke, with their internal microcode burning away power."
How does microcode "burn away" power?
"There is a worrying amount of coders out there that couldn't give a shit about that of course,"
Yes, coders should be constantly worrying about how many micro ops the code they are writing in managed high level languages that are compiled in to byte code and then machine code at runtime by a JIT compiler will turn into.
"their wasteful programs chomping up resources like it's infinite"
Code for pure RISC machines takes up more space than code for CISC machines.
"and these fucking idiots wonder why things crash after a few hours! ;p"
You're trying to use the "good old days" argument.
I hope they had a good reason to add that to the instruction set.
Not the OP, but the Multiply-Add instruction is a fundamental building block of signal processing operations (it's how you mix two audio signals, or do alpha-blending of images), so it is a "RISC" instruction in that sense.
IIRC the MUL and MLA instructions didn't exist on the ARM1 but were added to the ARM2 (which I think was otherwise pretty much identical) because Acorn's engineers came to realise that the chip would be embarassingly slow for certain operations without a hardware multiply.
Neither instruction was particularly fast though, they were several times slower than the other, simpler ALU operations. You could multiply a register with a constant *much* faster by using the MOV, ADD or SUB instruction in combination with the "free" barrel shifter, something like this example which multiples R0 by 320 (a common operation in games on the Arc where you'd need to calculate the start address of a line on a MODE 13 screen)
MOV R1,R0,ASR#8 ;multiply R0 by 256 and store in R1
ADD R1,R1,R0,ASR#6 ;multiply R0 by 64 and add to R1
I think that's right, my ARM code is pretty rusty these days.
IIRC, the MUL and MLA instructions took four bits per cycle from the first operand, so a multiplication could take up to 8 cycles. This also meant that it would be an advantage to have the smallest number as the first operand, so multiplication terminates early.
Expanding a constant-multiply to shifts and adds speeds up the computation only if the constant is relatively large and has few 1-bits (a bit simplified, as you can handle many 1-bits if you also use subtraction, so it is really the number of changes between 1-bits and 0-bits that count). But multiplying by, say, 255 or 257 was indeed faster to do by shift-and-add/subtract.
They were just genuine experiences at the time, not opinions born from nothing. And I've seen some bloody awful coding techniques.
Writing ASM in Arm for the Archimedes was great fun, and I could test it instantly.
C++ compilers these days often do a better job at optimising code than using assembly yourself, unless you've got a simple block of intrinsics to do. (I write time critical DSP code now)
But those compilers don't stop coders leaking memory everywhere, needlessly and lazily.
The 6510 was different from the 6502 in a few ways: it had the extra bits to let you remove ROMs from memory so you could directly access the whole 64K of RAM at once, giving the Commodore 64 its name, and also it had different undocumented operations in assembly. While the regular 6502 instruction set worked the same on the 6510, there were "extra" operations that weren't in any of the official MOS manuals that did work on the 6510. The one I still remember is LAX, which loaded both the A and X registers with the same number. I think it was either A9 or A7.
"You've got to love making all instructions able to be conditional"
It was fun while it lasted but predication has gone from the latest high performance ARMs, hasn't it?
Presumably something to do with when you've got so many speculative execution instructions in flight, predication actually turns out to be a hindrance rather than a help, because speculative stuff works better if it doesn't touch real global state, and the condition flags are real global state, thereby causing undesirable interactions or delays or both. [Massively oversimplified and perhaps misrepresented].
Conditional execution was in Thumb2 replaced by an if-then-else instruction that specifies which of the following up to four instructions are executed when the condition is true and which are executed when the condition is false. Specifying ahead of time is better for pipelining, ARM64 has, IIRC, done away with generalized conditional execution entirely, except for jumps. I suspect this is to make implementation simpler and because branch prediction can make jumps almost free, so all you would save with conditional instructions is code space.
ARM64 has, IIRC, done away with generalized conditional execution entirely, except for jumps.
The 6809 has a set of conditional jumps dedepndent on various flags. One of the instructions is BRN - Branch Never.
I thought it was a triumph of orthogonality over common sense until I used it...
Vic.
IIRC (It's been a while) the computer described in "First Draft of a Report on EDVAC" had no conditional branches. Only conditional "assign". One did a conditional branch by selecting one of two addresses to "code crash" into a jump instruction. This could have been worse than it was, had that machine not also had tagged memory. Storing into a word tagged as an instruction only altered the address portion of the word (executing a word tagged as data was treated as a LOAD IMMEDIATE). So the first "von Neumann Machine" was not what we now call a "von Neumann Machine".
Predicated execution was nice. As were other bits already mentioned. What knocked the ARM off the short list for my employer's "next CPU" was the lack of direct 16-bit data support (at the time). When one is doing process-control sorts of tasks, let alone something like a video game, one often uses a fair bit of 16-bit data, and the tradeoff of picking it up one byte at a time or wasting half of each 32-bit entry in an array can hurt.
We didn't fully dodge that bullet. At one point we used a board licensed from another company. They had chosen the "Big Endian" option. Why? I can guess (68K wankers), and the Norcroft compiler. That compiler properly handled things like table[x] if "table" was an array of 16 bit values in memory with a known address, but muffed them if table was a pointer to such data. Big fun.
I didn't downvote you, but tagged memory is still a Von Neumann architecture - the architectural principle is only that the program and data occupy the same addressing space.
Being able to overwrite program with data and vice-versa is not a required feature of a Von Neumann architecture; despite being a side effect of most implementations.
Can an experienced engineer look at a chip design photo/schematic and see how it "works" or do they have to drill down to the details and follow the paths? Are there common "patterns" that repeat across chips & manufacturers or is each chip unique?
I used to understand the very basics of a single transistor but at this scale its just a pretty, meaningless picture.
Can an experienced engineer look at a chip design photo/schematic and see how it "works
Not any more.
In days of yore, when chips were laid out by hand, you could recognise certain traits. Features made sense.
These days, everything is fully-synthesised. You can recognise major blocks, and that's about it...
Vic.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
