> "Wilco Dijkstra" <wilco-dot-dijkstra@ntlworld.com> wrote in message
> news:6kUpe.6357$jS3.2937@newsfe2-win.ntli.net...
>>
>>
>> However the 667 MHz Samsung ARM10 proves you can take an old ARM
>> design and push it hard (it has a simple 6-stage pipe with single
>> cycle ARM/Thumb decode stage).
>
> I can find that proccessor anywhere. Does it really exists
> or is it a propaganda announcement like their 1.2GHz ARM9?
Some years ago they announced "Halla" which was to be a 1.2GHz ARM1020E, but
I don't think it has made silicon yet. More recently they announced the
S3C2440 which is a 533MHz ARM920T, which they sampled, but I don't know if
it is in production at that speed.
John
--
John Penton, posting as an individual unless specifically indicated
otherwise.
Reply by Andre●June 9, 20052005-06-09
"Wilco Dijkstra" <wilco-dot-dijkstra@ntlworld.com> wrote in message
news:6kUpe.6357$jS3.2937@newsfe2-win.ntli.net...
>
>
> However the 667 MHz Samsung ARM10 proves you can take an old ARM
> design and push it hard (it has a simple 6-stage pipe with single cycle
> ARM/Thumb decode stage).
I can find that proccessor anywhere. Does it really exists
or is it a propaganda announcement like their 1.2GHz ARM9?
Andr�
Reply by Wilco Dijkstra●June 9, 20052005-06-09
<chris.shore@arm.nospam.com> wrote in message news:42A80942.229CD7EE@arm.nospam.com...
> > Isn't there at least one implementation where Thumb required an extra
> > pipeline stage to translate the code into ARM instructions? Depending
> > on how branchy the code is, that may actually slow things down.
>
> To my knowledge this has never been the case.
... in ARMs own designs. XScale is different.
> ARM9T (and later) implementations incorporate two decoders, one for ARM
> and one
> for Thumb so there is no need for the translation operation. This
> allows the decode stage to be shorter in terms of time and contributes
> to the higher potential clock speed of these implementations.
Yes, all modern ARMs do it this way. XScale is the only exception as it
uses an extra decode stage to deal with Thumb instructions. In some sense
this is similar to what high-end ARMs do, as they split the ARM and Thumb
decoders over 2 stages. You only pay for the extra pipeline stage on a branch
mispredict, so it works fine if you have a decent branch predictor.
However the 667 MHz Samsung ARM10 proves you can take an old ARM
design and push it hard (it has a simple 6-stage pipe with single cycle
ARM/Thumb decode stage).
Wilco
Reply by ●June 9, 20052005-06-09
> Isn't there at least one implementation where Thumb required an extra
> pipeline stage to translate the code into ARM instructions? Depending
> on how branchy the code is, that may actually slow things down.
To my knowledge this has never been the case. In ARM7T implementations
of thumb, the Thumb instructions are translated into ARM instructions
during the first half of the decode stage. The translated instructions
are then decoded by the existing ARM decoder in the second half
of the cycle. This does not introduce any extra stages or delays and
is completely neutral from a pipeline throughput point of view.
ARM9T (and later) implementations incorporate two decoders, one for ARM
and one
for Thumb so there is no need for the translation operation. This
allows the decode stage to be shorter in terms of time and contributes
to the higher potential clock speed of these implementations.
Chris
(posting as an individual)
Reply by Wilco Dijkstra●June 8, 20052005-06-08
"Everett M. Greene" <mojaveg@mojaveg.iwvisp.com> wrote in message
news:20050608.7A20708.BC9F@mojaveg.iwvisp.com...
> > int f(int x, int y) { return x + (y << 2); }
> >
> > ARM code (2 instructions, 8 bytes):
> >
> > ADD r0,r0,r1,LSL #2 ; 32-bits
> > BX lr ; 32-bits
...
>
> The example is an illustration of the power of the ARM
> instruction set when the problem happens to fit the
> solution.
It's just an example out of many - C idioms fit very well onto the
ARM instructionset.
> However, it's easy to see how the Thumb
> instruction set can be produced in that four bits of
> the ARM instruction is (mostly) for conditional
> execution, a feature that's rarely used.
Conditional execution is used quite a lot actually in compiled code,
and even more so in assembler. Compilers can use conditional
execution in cases where you wouldn't expect it. Using 4 bits is a
lot however, looking at the frequencies it appears using just 2 bits
would have been more appropriate.
> Another
> twelve bits are generally used for two source registers
> and one destination register designation; most of the
> time, only two of these are needed. Then there are
> varying numbers of bits (4 to 12) used for the "shifter"
> operand; shifting of one of the operands isn't used
> that often.
Shifts are used quite a lot actually, for example in constant
multiplies, array indexing, address generation, bit manipulation
and even constant generation. Again, one could probably save
a few bits by only supporting the most frequently used shifts -
indexed loads for example typically use a left shift of 0..3 bits
(Thumb-2 does this).
>Therefore, the ARM 32-bit instructions can
> be reduced to the 16-bit Thumb instructions without
> much loss of power.
16 bits isn't much to encode a full instructionset in, so Thumb
is a compromise. You can still do everything ARM can do, but
it often takes 2 or more instructions. If you need more instructions
you need more registers to store intermediate results, but Thumb
can only access to 8 registers. Most instructions are 2- rather
than 3-operand, so you may need to save the original value as well.
It is quite a challenge for a compiler to produce good Thumb code.
> Now, if "they" would just add support for position-
> independent (PC-relative) programming (LEA, BSR,
> et al)...
This stuff has been supported since day one - everything
on ARM is PC relative (branches, calls, literal loads etc):
the PC is one of the general purpose registers.
Wilco
> > Yes I do agree on what you said above, while i am goignt through
> > the ARM7TDMI rev (3) Introduction Chapter. Now I have read this
> > chapter but as you and chapter aslo state that Thumb instruction
> > set a subset of the full ARM Inctruction, So why the number of
> > the Instruction set for the thumb is greater then the ARM 32 bit??
>
> I take it you mean "why does Thumb need more instructions than ARM?".
>
> Thumb being a subset of ARM means that a Thumb instruction is simply
> not as powerful as an ARM one. One can sometimes encode 4 different
> operations into a 32-bitARM instruction, but you can encode only one
> operation in each 16-bit Thumb instruction. Thumb doesn't support ARM
> features like conditional execution, combined shift&operate instructions,
> use of 16 registers, 3 operand instructions, 8-bit rotated literals, etc.
> Therefore you typically need more instructions in Thumb. An example:
>
> int f(int x, int y) { return x + (y << 2); }
>
> ARM code (2 instructions, 8 bytes):
>
> ADD r0,r0,r1,LSL #2 ; 32-bits
> BX lr ; 32-bits
>
> Thumb code (3 instructions, 6 bytes):
>
> LSLS r1,r1,#2 ; 16-bits
> ADDS r0,r0,r1 ; 16-bits
> BX lr ; 16-bits
>
> Thumb-2 code (2 instructions, 6 bytes):
>
> ADD r0,r0,r1,LSL #2 ; 32-bits
> BX lr ; 16-bits
The example is an illustration of the power of the ARM
instruction set when the problem happens to fit the
solution. However, it's easy to see how the Thumb
instruction set can be produced in that four bits of
the ARM instruction is (mostly) for conditional
execution, a feature that's rarely used. Another
twelve bits are generally used for two source registers
and one destination register designation; most of the
time, only two of these are needed. Then there are
varying numbers of bits (4 to 12) used for the "shifter"
operand; shifting of one of the operands isn't used
that often. Therefore, the ARM 32-bit instructions can
be reduced to the 16-bit Thumb instructions without
much loss of power.
Now, if "they" would just add support for position-
independent (PC-relative) programming (LEA, BSR,
et al)...
Reply by Stephen Sprunk●June 8, 20052005-06-08
"Ishvar" <ishvargarewal@gmail.com> wrote in message
news:1118193089.395113.75100@g49g2000cwa.googlegroups.com...
> There is also a performance gain with high code density as we
> can now fit more code in the cache.
Isn't there at least one implementation where Thumb required an extra
pipeline stage to translate the code into ARM instructions? Depending
on how branchy the code is, that may actually slow things down.
S
--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
Reply by Wilco Dijkstra●June 8, 20052005-06-08
"Ricardo" <spamgoeshere1978@yahoo.com> wrote in message
news:3gobeuFddah3U1@individual.net...
> ranjeet.gupta@gmail.com escreveu:
> >
> <snip>
> >>In practice, a Thumb program is about 60% in code length compared
> >>to the equivalent ARM program. If there is a full-width bus to
> >>the code memory and the memory is fast enough to follow the processor,
> >>Thumb mode execution is about 20% slower than ARM code, due to
> >>the additional instructions to compensate for the more limited
> >>instruction set.
>
> A question that just arrived. Given the above mentioned code and speed
> reduction, I would also imagine that, for code being executed from
> external memory, the lower number os memory access cycles needed would
> make thumb code also execute faster. Has anyone tried it and has some
> results?
Yes, Thumb code runs faster than ARM when you use slow memory, eg. a
16-bit wide bus like various ARM MCUs. ARM performance almost halves
in this case, so Thumb code would run 30 - 50% faster than ARM. This is the
other key reason why Thumb was created.
This effect also happens to a lesser extent with multiple wait-state memory, or
when many cache misses occur in a cached system (after context switch).
However this will become an issue only for pin-limited MCUs with few on-chip
resources: MCUs are starting to use wide on-chip flash interfaces, allowing
ARM code to be run directly from flash without a huge penalty. Other MCUs
can run critical ARM code from on-chip SRAM for best performance.
Wilco
Reply by Ricardo●June 8, 20052005-06-08
ranjeet.gupta@gmail.com escreveu:
>
<snip>
>>In practice, a Thumb program is about 60% in code length compared
>>to the equivalent ARM program. If there is a full-width bus to
>>the code memory and the memory is fast enough to follow the processor,
>>Thumb mode execution is about 20% slower than ARM code, due to
>>the additional instructions to compensate for the more limited
>>instruction set.
>>
A question that just arrived. Given the above mentioned code and speed
reduction, I would also imagine that, for code being executed from
external memory, the lower number os memory access cycles needed would
make thumb code also execute faster. Has anyone tried it and has some
results?
Ricardo
Reply by Ishvar●June 7, 20052005-06-07
There is also a performance gain with high code density as we can now
fit more code in the cache.
Wilco Dijkstra wrote:
> <ranjeet.gupta@gmail.com> wrote in message
> news:1118178673.561458.28370@z14g2000cwz.googlegroups.com...
> >
> >
> > Tauno Voipio wrote:
> > > ranjeet.gupta@gmail.com wrote:
>
> > As it has been said that the code density of the thumb instruction
> > set is 60% higher then the ARM 32 bit Instruction set, So When the
> > memory is constrained then does it sounds logical to go for the
> > thumb instruction set as it is 60% more then the 32 bit ARM
> > Instruction.
>
> Correct - you need less memory with Thumb, which is a key reason
> why Thumb is so popular.
>
> > But Taking it other way round that the code density of the thumb
> > instruction set is 60% Lower then the ARM 32 bit Instruction set,
> > then every things makes the sense correctly as what is said in the
> > Specs and what you said.
>
> No, Thumb is more dense than ARM. Thumb instructions are half
> the size of ARM, so twice as dense. You need more instructions than
> ARM though, so you lose some of the gain. But overall, Thumb codesize
> is around 65% of that of ARM code, which is a 54% code density gain.
>
> > as it is not specifically mentioned in the specs.. It has been
> > just said that code density of Thumb is 60% then of 32 bit ARM.
>
> No, Thumb code *size* is 65% of that of ARM, code *density* is
> 54% better than ARM (1/0.65 = ~1.54).
>
> Code size and code density are not the same. Code density is the inverse
> of codesize, ie. lower code size means higher code density and visa versa.
> If X is half the size of Y, this means 50% less code, so in other words X
> is twice as dense as Y, or 100% better code density. Conversely, Y uses
> twice as much code than X (100% worse codesize), or 50% less code
> density than X. So it matters a lot whether you take X or Y as the baseline.
> It's a little confusing at first, but hopefully it makes sense after a while :-)
>
> > > The Thumb instruction set is a subset of full ARM instructions,
> > > operating on the same registers as the ARM instruction set. Due
> > > to the shorter instruction length (16 bits instead of 32 bits),
> > > only the first 8 registers (r0 to r7) are available as general
> > > registers. The other 8 registers (r8 to r15) can be accessed in
> > > a limited way in the Thumb mode. Also, conditional instruction
> > > execution is limited compared to full ARM mode.
> >
> > Yes I do agree on what you said above, while i am goignt through
> > the ARM7TDMI rev (3) Introduction Chapter. Now I have read this
> > chapter but as you and chapter aslo state that Thumb instruction
> > set a subset of the full ARM Inctruction, So why the number of
> > the Instruction set for the thumb is greater then the ARM 32 bit??
>
> I take it you mean "why does Thumb need more instructions than ARM?".
>
> Thumb being a subset of ARM means that a Thumb instruction is simply
> not as powerful as an ARM one. One can sometimes encode 4 different
> operations into a 32-bitARM instruction, but you can encode only one
> operation in each 16-bit Thumb instruction. Thumb doesn't support ARM
> features like conditional execution, combined shift&operate instructions,
> use of 16 registers, 3 operand instructions, 8-bit rotated literals, etc.
> Therefore you typically need more instructions in Thumb. An example:
>
> int f(int x, int y) { return x + (y << 2); }
>
> ARM code (2 instructions, 8 bytes):
>
> ADD r0,r0,r1,LSL #2 ; 32-bits
> BX lr ; 32-bits
>
> Thumb code (3 instructions, 6 bytes):
>
> LSLS r1,r1,#2 ; 16-bits
> ADDS r0,r0,r1 ; 16-bits
> BX lr ; 16-bits
>
> Thumb-2 code (2 instructions, 6 bytes):
>
> ADD r0,r0,r1,LSL #2 ; 32-bits
> BX lr ; 16-bits
>
> > > Exception handling (e.g. interrupts) and control is not possible
> > > in the base Thumb instruction set: the processor has to switch
> > > into 32 bit ARM mode for the control register accesses.
> >
> > What I find in the ARM7TDMI rev (3), that In the thumb instruction
> > set we have one instruction named SWI 8bit_Inm (software Interrupt)
> > then this stands for, As above you said that it is not possible in
> > the base thumb instruction set, Is there diffrence between the
> > base thumb instructuion set and the thumb instruction set. ?
> > Is some thing I am missing
>
> For ARM7tdmi they are the same. Yes, SWI is in Thumb (note it is
> nowadays called "SuperVisor Call" as it is not an interrupt).
>
> There is no single Thumb instructionset - Thumb has been evolving over
> many years, and today 5 different versions exist. The most interesting variant
> is Thumb-2, which adds all ARM features to the Thumb instruction set
> thereby avoiding the need for extra instructions. This makes Thumb-2 code
> as fast as ARM while it is still as dense as Thumb.
>
> Wilco