 Taming the x86 beast
started 4/1/2004; 9:58:03 PM - last post 4/2/2004; 11:52:57 AM
|
|
Chris Rathman - Taming the x86 beast 
4/1/2004; 9:58:03 PM (reads: 8620, responses: 2)
|
|
| Taming the x86 beast |
|
If you've never had the pleasure of programming an x86-family processor in assembly language, you don't know pain. The 32-bit x86 chips (including the '386, '486, and Pentium-class parts from Intel and AMD) do an amazing job of dragging one of the world's oldest processor designs into the modern age. They do it while still maintaining binary compatibility with chips that are three generations and 15 years behind. It's impressive, really, but it makes these chips tricky to program with low-level code.
Since the discussion forum has gotten into a question of evolution and popularity, I thought I'd pop in with the parallel universe of assembly language. IMHO, x86 assembly language is far inferior to many of the other alternatives. Yet, the biggest target cpu is the x86.
The only upside, I suppose, is that Intel managed to single handedly destroy the art of hand crafted assembly. The vacuum being filled in by C. The problem with the popular choices is not just restricted to higher level languages (and that's not even getting into the question of Operating Systems).
Posted to general by Chris Rathman on 4/1/04; 10:01:26 PM
|
|
|
|
Dominic Fox - Re: Taming the x86 beast
4/2/2004; 1:01:37 AM (reads: 387, responses: 0)
|
|
|
I used to write "hand-crafted" assembly for the ARM processor used in Acorn's Archimedes machines. That was pretty fun actually - very minimalist, astonishingly fast (for the time). I've never felt the slightest inclination to do the same with x86...
|
|
James Hague - Re: Taming the x86 beast
4/2/2004; 11:52:57 AM (reads: 281, responses: 0)
|
|
|
You could hand craft x86 assembly code--and get a lot of benefit from doing so--up until the Pentium II. There were some great books on x86 optimization prior to that, especially "The Zen of Assembly Language," which focused on the original 8088 and 8086 (and, strangely, wasn't published until 1990, a year after the 80486 was introduced). Things fell apart quickly after the Pentium II, because the correspondence between object code and performance became obscure.
It's interesting to discover the things you can do in assembly language that actually slow down the processor. For example, putting code and data within the same 1024 byte "line" on the P4 causes a massive slowdown. Ditto for return stack manipulations that break the branch predictor.
The best way to experiment with x86 assembly these days is to use a machine code generating Forth, such as VFX Forth or SwiftForth.
|
|
|
|