On 7/9/2011 5:07 PM, Jecel Assumpcao Jr. wrote:
BGB,
or, maybe all my x86 experience blinds me some to the "elegance" of
ARM's ISA?...
whatever is so great about it, well, I am not seeing it at this level.
why then do so many people seem to complain that the x86 ISA is so
horrible?...
I think this is completely off topic for this list, but it would be rude
to leave your without an answer.
sorry, the topic of this list is not really all that clear.
sometimes people talk about hardware (such as FPGAs), sometimes about
programming languages, and sometimes about random distant-future type stuff.
it isn't really all that clear what is or is not topical.
x86 vs ARM does seem to be related, as it relates both to hardware and
to the future of computing (like, which ISA people might end up using,
or similar...).
Back in 1988 I wrote an ARM emulator
for the PC and a 8086 emulator for the ARM and can tell you that the ARM
was so much "cleaner" than the x86 that it was hard to compare them.
When you add a hack to go from 26 to 32 bit addressing, an object
oriented MMU from Apple, floating point, 16 bit encoding (Thumb), Java
compatibility, DSP and so on then it would be suprising if the core
simplicity of the ARM didn't get buried way deep.
mostly I am dealing with Thumb-2, which is an extension of Thumb to
support variable-length instructions. the basic instructions are
16-bits, but some forms are longer (such as to allow larger immediates,
...).
there are several "compund instructions" where multiple instruction
words are treated as a single unit and values are spread between them.
part of how it is nasty is that often the immediates/... are split up
into 4 or so different pieces spread into different parts of the
instruction (a few bits here, a few bits there, ...).
all this leading to needing a lot of hairy logic in the assembler (vs
x86 where one spits out a byte or a dword and they are done with it).
pure ARM, maybe would be cleaner/nicer, if it were without Thumb and
Thumb-2 and Jazelle and similar added on.
Of course, if you are not using segments (and nobody is, these days)
then you are only programming in a limited subset of the x86 and I can
see how it can look elegant (see what Chuck Moore does on a Pentium for
his ColorForth, for example).
yeah, typically:
segments are ignored (legacy, don't care, they are a system feature
anyways);
system-level instructions are ignored (since one can't really use them
in application code);
many legacy instructions or instruction forms are ignored (some were
"deprecated" and partly removed from the ISA when x86-64 was created,
but then Intel re-introduced them with a flag to control whether or not
they exist in long-mode).
basically, this mostly leaves x86 in its modern form:
a flat address space model;
a set of 8 or 16 registers (depending on CPU mode) which are mostly
orthogonal;
basic instructions like mov/add/sub/...
actually, it is funny that a fair amount of the single-byte opcode map
is now are largely non-applicable (either deprecated by AMD or otherwise
unusable in application code).
also, on x86-64 targets, x87 has largely fallen into disuse as well
(generally not used directly by compilers, and left mostly for
implementing math functions), ... this role has been mostly picked up by
SSE and SSE2.
there are also many of those instructions which still exist but are
rarely used anymore (loop, enter, leave, ...), because it is more common
to write out their operations via more basic instructions.
depending on specifics, it is not entirely unreasonable that an
x86-based chip could be created which itself lacks support for segmented
addressing (only it would need EFI or coreboot or similar to boot up,
with no traditional BIOS). potentially, this could be done with minimal
impact to modern operating systems (such as Linux or Win7). that or
real-mode is a partial software-level emulator built into the BIOS (whos
use is mostly confined to the initial bootup sequence).
in my case, I have written assemblers for both x86 and for ARM, and a
partial interpreter for x86 (does userspace-stuff, ignores most
system-level features, wont do real-mode or PM-16).
my assembler also can't really be used for system or 16-bit code,
because it lacks many instruction forms needed for this.
so, maybe it was more that, at one time, x86 was very nasty and covered
in crud, and ARM was simple, but over several decades, x86 got cleaned
up and much of it fell into disuse, and ARM got piles of crud added onto
it, leaving things at the present situation?...
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
