The Art of Picking Intel Registers (2003)

http://www.swansontec.com/sregisters.html

by Tomte • 8 years ago

133 44 8 years ago

bogomipz7• 8 years ago

"There are three major processor architectures: register, stack, and accumulator. In a register architecture, operations such as addition or subtraction can occur between any two arbitrary registers. In a stack architecture, operations occur between the top of the stack and other items on the stack. In an accumulator architecture, the processor has single calculation register called the accumulator."

I have only ever seen register and stack used to distinguish between a virtual machine implementation - i.e a "stack machine", example - the JVM , a "register machine", example - Dalvik. The author explains that the x86 is register based architecture but what are some examples of a stack based CPU architecture and an accumulator based CPU architecture?

shagie2• 8 years ago

The 6502 and many of its kindred are accumulator based machines. From http://nesdev.com/6502.txt

THE ACCUMULATOR
This is THE most important register in the microprocessor. Various machine language instructions allow you to copy the contents of a memory location into the accumulator, copy the contents of the accumulator into a memory location, modify the contents of the accumulator or some other register directly, without affecting any memory. And the accumulator is the only register that has instructions for performing math.

It has some other registers (X, Y, Status, Program Counter and Stack Pointer). Looking at the instruction set ( http://www.e-tradition.net/bytes/6502/6502_instruction_set.h... ) , you'll see that all of the math operands work off of the accumulator. X and Y are primarily for the offset for a memory location.

bogomipz7• 8 years ago

Thanks, architectures where the accumulator is always used implicitly then?

I have often heard "register based architecture" used to describe MIPS/load store type architectures. It seems that the author here is implying that the x86 is "register based" since they''re stating its not actually an "accumulator machine" does have an accumulator like register?

amluto• 8 years ago

Knuth’s MIX. Z80 is also sort-of an accumulator architecture, to a greater extent than x86.

pvg4• 8 years ago

One way you can look at 'accumulator architecture' is as a special, constrained case of 'register machine' that makes sense when you're making CPUs out of 3510 transistors. A modern virtual machine and the CPUs it would target have grown past the constraint so you don't see that particular approach any more.

bogomipz7• 8 years ago

Sorry can you explain why it only makes sense when your making cpus out of 3510 transistor? What constraint specifically are you referring to? Thanks.

innocenat• 8 years ago

For stack machine, RTX2010 comes to mind. It's a radiation-hardened processor used in various spaceships.

gh02t• 8 years ago

Neat, I didn't know about this chip. Is there anything particular about a stack architecture that makes it ideal for radhard applications, or is it just the one they selected because they wanted to use Forth?

kabdib• 8 years ago

Also, the INMOS Transputer. It's a seriously odd but inspired architecture. Didn't scale in performance. Had some really interesting ideas in its ISA and interprocessor communication system.

userbinator3• 8 years ago

Most of the early computers were accumulator-based; and the concept predates computers, since the early mechanical calculators had a single "register" --- the accumulator --- which... accumulated the results of successive calculation. It's no surprise that computers, which initially were developed to be essentially automatic calculators, adopted the same architecture:

https://en.wikipedia.org/wiki/Arithmometer

https://en.wikipedia.org/wiki/Comptometer

adrianratnapala• 8 years ago

I suspect it was also rational, given the performance trade-offs at the time.

As transistors have become smaller, the caching hierarchy has become more important. A modern register set is a level-0 cache -- i.e. a useful pool of memory that is really close to the the computation units.

In the old days, the communication between components was less of a bottleneck than the speed of the components themselves. So there was less advantage to this. On the other hand, making a CPU simpler by having just one or two registers was more of an advantage than it is now.

skissane2• 8 years ago

The original CISC HP 3000s were a stack machine.

Newer HP 3000s used PA-RISC CPUs instead (register not stack CPU), but the MPE operating system included an emulator/translator so they could still run the legacy CISC code.

(The same architecture was also used in some of the early HP 9000 workstations, specifically the 500 series.)

skissane2• 8 years ago

Another example of stack machines was the original Tandem architecture, which was based on HP 3000. (Most of the early Tandem team had come from HP.) Tandem then moved away from stack machines, to MIPS – but like the HP-3000 RISC transition, the MIPS Tandems had an emulator/translator for the original stack machine architecture.

From MIPS, Tandem moved to Itanium, and now to x86. And, having been founded by ex-HP engineers, Tandem is now part of HPE.

abfan1127• 8 years ago

isn't the Microchip Pic an Accumulator based architecture?

monocasa• 8 years ago

Yeah, those are basically fancier clones of a PDP-8.

zokier• 8 years ago

I think F18A architecture (used in GA144 chips) is stack based, optimized for running forth

http://www.greenarraychips.com/home/documents/index.html#arc...

Lionsion• 8 years ago

what are some examples of a stack based CPU architecture

https://en.wikipedia.org/wiki/Burroughs_large_systems

dbrgn2• 8 years ago

This is a great article. I used it to optimize the code for a code golf puzzle our hackerspace made: http://codegolf.coredump.ch/challenges/asm-compass/ If you want a challenge to reduce the binary size of a very simple program (= choosing instructions with smaller opcodes), give it a try :)

userbinator3• 8 years ago

I've done a few challenges like that[1] but seeing that the smallest so far is over 300 bytes makes me think most of those 300 bytes are not actual code but program header overhead, because it should be doable in much fewer bytes of actual code. Once you've done these challenges a few times, you can easily estimate a rough size:

The template is 48 bytes. Add 16 bytes for an [offset,char] table. Maybe another 30 bytes (let's be generous and round that up to 32) for code to pull the commandline parameter, do the indexing and template modification, write the output, and exit. 96 bytes of code. Add 64 bytes of minimal ELF headers[2] and you're still well below 200 bytes.

I don't have an environment at the moment that doesn't do ELF files, so I just tried it with 16-bit DOS and ended up at... 95 bytes:

https://pastebin.com/C7vDfFbR

I wasn't trying very hard so someone will probably find an even smaller version, and it was just for fun since it doesn't meet the rules anyway.

[1] http://www.hugi.scene.org/compo/compoold.htm

[2] http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm...

jsjohnst• 8 years ago

ELF binaries under 200b:

142 bytes: http://timelessname.com/elfbin/

45 bytes: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm...

dbrgn2• 8 years ago

Thanks for the links! Most of the submitted approaches don't even mess with the ELF binary structure. But even if you don't do that, there's a lot you can learn by optimizing (sometimes doing something with more instructions instructions actually result in a smaller binary because of shorter opcodes).

It was the first time I really messed around with x86 assembly and I learned a lot during the progress :)

Edit: Wording

Edit2: Also note that for this challenge you need to submit NASM assembly, and not the resulting binary. So you can't resort to hex editing the binary itself.

colatkinson• 8 years ago

I've been working on learning x86 ASM, and this was a fun challenge. Cool stuff.

aetherspawn• 8 years ago

Don’t get any ideas though. Whilst these instructions might make the output code smaller, it will probably make the program slower (1). Processors are optimised to run code generated by compilers fast, and compilers stopped outputting these a long time ago.

1/ There are edge cases like when the code is very big then less code might fit in the cache better or perhaps dispatch better .. but probably not many.

userbinator3• 8 years ago

In my experience, cache matters a lot and compilers aren't smart enough to figure out what parts of the code are time-critical and what parts aren't, so they just use the fastest (and sometimes significantly bigger) instruction sequences everywhere. Optimising non-critical-path code by making it smaller even if it's somewhat slower can actually make the program as a whole faster, since the cache misses decrease.

rwmj• 8 years ago

On Ivybridge and later the string instructions are actually faster than the equivalent unrolled instructions. https://news.ycombinator.com/item?id=12353455

cesarb• 8 years ago

Another interesting trivia about the x86 registers: while most programmers think of their order as being EAX, EBX, ECX, EDX, ESI, EDI, ESP, EBP, when you look at how the registers are numbered in the instruction set, you see that their true order is different: EAX, ECX, EDX, EBX, ESP, EBP, ESI, EDI.

teh_klev2• 8 years ago

What's the significance of this?

eyer2016• 8 years ago

Next time you play trivia at your local bar and get asked, "what's the true order of x86 registers," you will get 5 points

The Art of Picking Intel Registers (2003)

Related Stories