well, here is my thing:
I mostly develop on x86 (and x86-64), and so most of my code is targeted
to this target.
recently, I figured I would try to port some of my stuff to ARM, mostly
as a matter of personal experience and seeing if I could. I started with
my assembler here (it is a major core part of the VM, and the part that
generally deals most directly with the target CPU).
opinion derived:
in terms of ISA encoding, ARM seems far worse than x86 (ARM is
effectively a bit-twiddly mess here) and things one can generally take
for granted in x86 are a bit more of a problem in ARM (things like
getting constants loaded into a variable, or dealing with memory
addresses, ...).
apparently, the assembler itself involves a fair level of "magic" in
making things work (pseudo-ops are not uncommon, ...).
it is sad when x86 seems clean and elegantly designed in comparison.
actually, very little has gone cleanly in all of this. even getting an
ARM-based Linux working in an emulator is a pain.
at the moment the thought that ARM could pose any real threat to x86
seems scary, such as a future where this level of terribleness has come
to be expected.
customer: "what if I want to upgrade the OS on my new PC?", salesman:
"well, contact us, and we will send a technician with an updated version
of the firmware", customer: "what if I want to upgrade it myself?",
salesman: "this is not advised, as it will void your warranty and risks
bricking your system...".
(that is unless HW standardization and UEFI more come more into play,
ideally such that one can freely choose and install their OS, with
bricking no longer looming on the horizon...).
that and anyone who dares look at ASM is faced with funkiness related to
getting values loaded into registers and direct-accessing memory
addresses, ... a world where loading a constant generally requires
multiple CPU instructions, and direct loads/stores have small memory
windows.
from the POV of a casual observer, a lot of this is not so obvious until
one goes and messes with it.
I guess most other things I have read argue mostly in terms of
power-usage in mobile devices.
what of the longer term, and what of "in general".
several possibilities would seem to exist:
x86 comes to dominate all (except maybe for small embedded systems, x86
will dominate laptops, netbooks, tablets, and smartphones);
ARM comes to spread into x86 domain (full-sized laptops and desktop PCs);
stalemate, essentially neither makes significant inroads into the
others' territory due to mutually incompatible requirements and
expectations.
the watts argument will not likely win the desktop, since probably much
under 100W or 200W and people are not all that likely to care. it is
also unlikely that any vendor locked-down appliance-like device would go
over well here (then it is another XBox or PS3, not a PC...).
similar likely applies to laptops/... as well. 2-3 hours of battery is
typical for a laptop, and is generally sufficient. the "appliance" issue
likely still applies here as well.
I suspect that the openness and portability issue may ultimately become
much more important WRT tablets and phones, as they become more common,
people may come to expect them to have more of the capabilities taken
for granted on higher-end systems, likely demanding either x86, or at
least for ARM systems to become more standardized and open.
that and/or ultimately people are forced into using VM-based strategies
as their main SW-development methodology.
a lot of this has again reminded me of a past attempt at creating
effectively an IL which was partway between a simplified x86 and EFI
ByteCode. basically, it would not have been x86, but would have been
fairly similar as to ease targeting it for compilers already targeting
x86 (similar ASM syntax/mnemonics). it would either be interpreted or
translated by JIT to the native ISA.
possible encoding:
bytes 0x00..0xEF: single-byte opcodes;
0xF0..0xFF: escaped longer (2+ bytes) opcodes.
ModRM+SIB would be replaced with MRIB, which would essentially be a
4-nibble combined field (M=mode+scale, R=reg/opext, I=index/type, B=base).
for the past idea, I had originally partly lost motivation.
also it would compete some with my existing high-level ILs.
the idea lacked much point when solely targeting x86, but this option
looks a bit more preferable in the context of otherwise having to
directly target ARM, but as a downside would not cover cases involving
ABI interfacing, which would likely still require ARM assembler.
that, or it may in-fact be that my VM porting effort may not be
worthwhile (much like that of trying to get the memory footprint low
enough to be practical on an Android device...). like, a "test" maybe
itself not worth the effort?...
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?...
or such...
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
