Re: Hi
- From: "Wilco Dijkstra" <Wilco_dot_Dijkstra@xxxxxxxxxxxx>
- Date: Thu, 05 Apr 2007 20:15:12 GMT
"Martin Wuerthner" <spamtrap@xxxxxxxxxxxxxxx> wrote in message
news:e5aaa7cd4e.martin@xxxxxxxxxxxxxxxxxxxxxx
In message <8PzPh.19608$2F5.13408@xxxxxxxxxxxxxxxxxxxx>
"Wilco Dijkstra" <Wilco_dot_Dijkstra@xxxxxxxxxxxx> wrote:
"Martin Wuerthner" <spamtrap@xxxxxxxxxxxxxxx> wrote in message
news:ceb0e3cb4e.martin@xxxxxxxxxxxxxxxxxxxxxx
In message <3i_Mh.17307$NK3.5441@xxxxxxxxxxxxxxxxxxxx>
"Wilco Dijkstra" <Wilco_dot_Dijkstra@xxxxxxxxxxxx> wrote:
PIC and ARM very different. PIC is a collection of several unrelated
architectures, ARM is a single architecture. You can run code from the
first ARM1 on the latest Cortex-A8 unchanged.
You may be able to run it but it would not work. ;-) Unless I have
missed something and the latest Cortex-A8 implements the old 26-bit
mode, which was the only mode of operation on ARM1 to ARM3?
I didn't say *all* code. My point is that none of the bitpatterns of the
original 26 or so instructions ever changed.
Well, they did not change in that the mnemonic for a certain
bitpattern remained the same, but the meanings of some of the
bitpatterns changed radically. Take MOVS pc,r14 for example - on an
ARM9 that is an entirely different instruction as on an ARM2 (in
particular in non-USR modes), and that instruction was the standard
subroutine return instruction on an ARM1/2/3 - even in compiled code.
That is hardly any change. In both cases the flags and mode bits are
updated, the only difference is where the bits are stored. Any code using
MOVS pc,lr (say an interrupt handler) continues to behave identically
irrespective of 26- or 32-bit mode. Only code that assumes where the
mode bits or flags are is affected (ie. code using mode/flag bit tricks).
Only a tiny subset of instructions changed meaning or became invalid
over 20 years.
Yes, which broke binary compatibility at that point. It does not help
if your new processor can execute 95% of the instructions in a program
correctly. One incorrectly executed instruction breaks everything.
Binary compatibility is only relevant for application code. There are
lots of instructions that are different between different CPUs (eg.
how to clean the cache), but that doesn't make them incompatible.
The issues of 26-bit mode relate to mode changes and flag bit tricks
in supervisor mode - ie. OS code, not application code.
But not all old code depends on 26-bit mode, I wrote quite a lot of
assembler without such tricks. Compiled code didn't use them either.
Oh yes. All compiled code back then used MOVS pc,r14 to return from a
subroutine. In SVC mode that is likely to break immediately.
No. If the CPSR is copied into SPSR, MOVS pc,r14 works perfectly
fine in any mode (if a little slower than BX lr on modern CPUs).
Besides,
compilers did exploit the fact that the status flags were preserved
over subroutine calls (which was mandatory in the original APCS). It
is therefore quite likely that C code compiled for an ARM2 executes
incorrectly in 32-bit mode.
Yes the original ARM compilers could use BL in conditional execution.
I fixed the ARM compiler to generate the same code for 26- and 32-bit
mode and investigated the differences. My conclusion was that compiled
code very rarely relied on flags being preserved. There was hardly any
codesize loss on a large amount of code. Additionally it is trivial to check
that compiled code doesn't have this problem.
Code written for 26-bit mode operation is likely to contain instructions
that have a different meaning in 32-bit mode (e.g., something like
ORRS pc,lr,#(1<<28) to return from a subroutine with V set and other
flags preserved).
Using the V-flag like that was a bad idea...
Only with hindsight of the incompatible change introduced long
afterwards. At the time of the ARM2 there was no idea of a "26-bit
mode" nor of "26-bit mode tricks". All there was was *THE* ARM
instruction set and the flags being part of pc were an integral part
of the design, as integral as the idea that the BL instruction stores
the return address in r14.
I meant the RISCOS use of using the V flag to denote an error. It made
both SWIs and the code that used them more complex (and hard to
use from C). If this practise hadn't become standard, far less code
would rely on these tricks.
I always thought the idea of writing to the PC to set some flags or
change mode was a bit odd, and certainly didn't like the ORRS trick.
The one thing I did find really useful was TEQP which allowed you to
set the flags based on 4 bits (good for memcpy/memset). Of course
that instruction didn't work properly when not in user mode... So 26-bit
mode wasn't ideal back then, but as you say there was no alternative.
I don't think 32-bit mode is much of an improvement either. Disabling
interrupts and switching mode only became efficient in v6. Then there
is the issue of having 15 unused registers for most of the time, except
briefly in exception handlers. Apart from requiring register renaming
on mode changes (a major source of bugs in many ARMs), this is a
problem as register files require many ports, and thus a lot of area.
However it was the solution that was the least incompatible with 26-bit
mode. With hindsight it would have been better to do it like Cortex-M3.
So, I think you need to paddle back a bit, but not much: You can run
code from the first ARM6 processor on the latest Cortex-A8 unchanged
(provided that code was meant to be run on the ARM6 in 32-bit mode).
Rather: you can run any code that is not incompatible with 32-bit mode
without any problem.
Yes, of course, but my point is that the vast majority of code written
back then *is* a problem because both standard programming practices
and compiler output back then led to code that could not be run in
32-bit mode unchanged.
My point is that not much code actually relied on it (RISCOS excepted),
so most compiled code runs without any issues. Assembler code is more
difficult of course, but it can be scanned automatically for the tricks.
Oddly enough even after 32-bit mode was introduced, the Acorn world
ignored the issue for many years - presumably thinking 26-bit mode
would live on - despite the fact that early Acorn compilers had switches
to avoid emitting MOVS or relying on calls preserving flags.
Wilco
.
- References:
- Re: Hi
- From: Martin Wuerthner
- Re: Hi
- Prev by Date: Re: ARM C compiler expression evaluation doubt!
- Next by Date: Re: ARM abort exceptions from C Code
- Previous by thread: Re: Hi
- Next by thread: have you programmed in assembly for ARM using arm-elf-as?
- Index(es):
Relevant Pages
|
