Any ARMs with hardware divide?

Hi - does anybody know of any ARMs with a built in hardware divide? I heard 
that a new core coming out would have a built-in hardware divide, but I've 
been unsuccessful in finding out which core that is and if any chips have 
that core. Thanks,

-Michael J. Noone

Michael Noone wrote:
> Hi - does anybody know of any ARMs with a built in hardware divide? I heard 
> that a new core coming out would have a built-in hardware divide, but I've 
> been unsuccessful in finding out which core that is and if any chips have 
> that core. Thanks,
> 
> -Michael J. Noone

You could be thinking of the Cortex core?, their promo stuff says this:

"The exceptional performance of the ARM
Cortex-M3 processor is achieved through a highly
revised architecture that also implements many
new technologies in this type of core, such as
hardware divide and single cycle multiply."

No, it is not binary compatible.

Anyone working on this silicon is in stealth mode right now...

-jg

"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:4275b157$1@clear.net.nz...
> Michael Noone wrote:
> > Hi - does anybody know of any ARMs with a built in hardware divide? I heard
> > that a new core coming out would have a built-in hardware divide, but I've
> > been unsuccessful in finding out which core that is and if any chips have
> > that core. Thanks,
> >
> > -Michael J. Noone
>
> You could be thinking of the Cortex core?, their promo stuff says this:

Cortex defines 3 families of cores - the M3 is just the first announced
in the deeply embedded/microcontroller space.

> "The exceptional performance of the ARM
> Cortex-M3 processor is achieved through a highly
> revised architecture that also implements many
> new technologies in this type of core, such as
> hardware divide and single cycle multiply."
>
> No, it is not binary compatible.

Why not? It depends on your definition of "binary compatible".
A purist definition would imply no ARM chip is binary compatible
with another because most chips have different peripherals, or use
a different way to clean the cache etc. You'll always need to port
your OS and drivers to a new CPU, and the M3 is no different in
this respect.

However a commonly used definition is that it implies user mode
compatibility. The M3 uses the Thumb-2 instruction set which is
backwards compatible with Thumb, so existing compilers and
objects will continue to work (as long as they don't contain ARM
code). Of course to get the maximum benefit of the M3, you'll want
to recompile with a good Thumb-2 compiler - but again this is no
different from any other new core.

Wilco

> However a commonly used definition is that it implies user mode
> compatibility. The M3 uses the Thumb-2 instruction set which is
> backwards compatible with Thumb, so existing compilers and
> objects will continue to work (as long as they don't contain ARM
> code). Of course to get the maximum benefit of the M3, you'll want
> to recompile with a good Thumb-2 compiler - but again this is no
> different from any other new core.
>
> Wilco


You cannot compile an ARM program in pure Thumb mode.
You need some ARM mode stuff as well so no ARM/Thumb compiler
would work off the shelf with the Cortex.
Also no operating system would work with Cortex.
Very few semiconductor vendors have licensed Cortex cores
You will have to invest in a new set of tools to start with the Cortex
so it will have no special benefit over any proprietary architecture.


-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may bot be shared by my employer Atmel Nordic AB 

"Ulf Samuelsson" <ulf@atmel.nospam.com> wrote in 
news:Cibee.54509$Of5.34248@nntpserver.swip.net:

> You cannot compile an ARM program in pure Thumb mode.
> You need some ARM mode stuff as well so no ARM/Thumb compiler
> would work off the shelf with the Cortex.

Why ever not? A user land program doesn't need to have access to 
the CPSR! You can still SWI from Thumb, and the OS Libs could 
have Thumb entry points. Sure it takes some careful thought, but 
that thought has been around for a long time under the name 
"interworking".

> Also no operating system would work with Cortex.
No "compiled for ARM" OS would work for Cortex, and no OS could 
be compiled for Thumb because of the need for mode changees and 
Exception handling (inc Reset), However this is a long way from 
saying that an OS cannot work with Cortex, it simply needs some 
basic porting work.
There is still value in keeping much of the toolchain, OS and 
apps compiled in the same way.

Will

Ulf Samuelsson <ulf@atmel.nospam.com> wrote:
> You cannot compile an ARM program in pure Thumb mode. You need some ARM
> mode stuff as well so no ARM/Thumb compiler would work off the shelf with
> the Cortex.

Of course you can. Obviously code running on bare metal will need some level
of porting due to the fact that exception handlers had to be in ARM
preiously. However code running under an OS should not.

It also should be pointed out that this whole thread applies only to the
Cortex-M series which is designed for the deeply embedded space. The
Cortex-A and Cortex-R series support the ARM instruction set as well as
Thumb-2.

> Also no operating system would work with Cortex.

This comment applies to almost any new processor produced by ARM ever. Most
OSes are complex beasts and invariably require some level of porting to a
new core.

-p
-- 
 "What goes up must come down, ask any system administrator"
--------------------------------------------------------------------

paulg@at-cantab-dot.net wrote:
> Ulf Samuelsson <ulf@atmel.nospam.com> wrote:
> 
>>You cannot compile an ARM program in pure Thumb mode. You need some ARM
>>mode stuff as well so no ARM/Thumb compiler would work off the shelf with
>>the Cortex.
> 
> 
> Of course you can. Obviously code running on bare metal will need some level
> of porting due to the fact that exception handlers had to be in ARM
> preiously. However code running under an OS should not.
> 
> It also should be pointed out that this whole thread applies only to the
> Cortex-M series which is designed for the deeply embedded space. The
> Cortex-A and Cortex-R series support the ARM instruction set as well as
> Thumb-2.

  So are you saying, the -A and -R variants, can safely swallow 
libraries created for ARM7 cores, - ie that ALL cortex extensions are in 
the 'opcode gaps' of older cores ?

  Point to ponder: If the Cortex core is so wonderfull and efficent, why 
do the -A and -R versions need ARM opcode support. Sounds a bit like a 
reflex oops-fix ?

  Will this not get very confusing in the field, since some Cortex cores 
are binary compatible, and some are not, and some have smaller die, and 
some do not... ?

  ARM seem to have lost their way a bit on handling this one....

-jg

"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:427a79f0$1@clear.net.nz...
> paulg@at-cantab-dot.net wrote:
> > Ulf Samuelsson <ulf@atmel.nospam.com> wrote:
> >
> >>You cannot compile an ARM program in pure Thumb mode. You need some ARM
> >>mode stuff as well so no ARM/Thumb compiler would work off the shelf with
> >>the Cortex.
> >
> > Of course you can. Obviously code running on bare metal will need some level
> > of porting due to the fact that exception handlers had to be in ARM
> > preiously. However code running under an OS should not.
> >
> > It also should be pointed out that this whole thread applies only to the
> > Cortex-M series which is designed for the deeply embedded space. The
> > Cortex-A and Cortex-R series support the ARM instruction set as well as
> > Thumb-2.
>
>   So are you saying, the -A and -R variants, can safely swallow
> libraries created for ARM7 cores, - ie that ALL cortex extensions are in
> the 'opcode gaps' of older cores ?

Yes - just like all previous extensions.

>   Point to ponder: If the Cortex core is so wonderfull and efficent, why
> do the -A and -R versions need ARM opcode support. Sounds a bit like a
> reflex oops-fix ?

Despite the success of Thumb, ARM code is still used a lot in many markets
(WinCE and Linux are almost exclusively ARM for example), so dropping
all support for the ARM instruction set would be a bit stupid, don't you
think?

The markets Cortex-M is aimed at almost exclusively use Thumb because
codesize is essential there. ARM is typically only used in a few routines that
cannot be written in Thumb. Thumb-2 solves this problem (most ARM
code can be reassembled to Thumb-2), thus making ARM "unnecessary baggage"
in a tiny micro controller. If you think about it, it all makes sense...

>   Will this not get very confusing in the field, since some Cortex cores
> are binary compatible, and some are not, and some have smaller die, and
> some do not... ?

And how exactly is this different from today? All existing cores have different
die sizes, power consumption, architectures, micro architectures, coprocessors,
cache architectures etc. If you're not confused by the existing CPUs then you
shouldn't be confused by Cortex.

The key is that you can always upgrade to a bigger and better core (eg from
ARM7tdmi to ARM9E to ARM1156T2). You can sometimes literally use old
binaries, but this will not result in the best possible performance. In some cases
you'll have to do an OS port (eg. due to different cache architecture), but in all
cases a recompile is highly desirable to make optimal use of the new instructions
and micro architecture.

The Cortex family is very similar: there will be multiple CPUs at different
performance levels within each of the A, R and M strands, and these will be
binary compatible (ie. no recompile needed). You can also move between
them if you wish, but this obviously requires more effort (just like moving
from ARM7tdmi to ARM1156 would).

>   ARM seem to have lost their way a bit on handling this one....

I think you're a bit confused...

Wilco

"Ulf Samuelsson" <ulf@atmel.nospam.com> wrote in message
news:Cibee.54509$Of5.34248@nntpserver.swip.net...

> You cannot compile an ARM program in pure Thumb mode.

Yes you can. A program can be a Thumb-only application, a library or
a DLL or similar. The OS interface doesn't change for new hardware -
a basic principle of OS design!

With the ARM1156T2-S however it is possible to create a Thumb-only
system, including the OS.

> You need some ARM mode stuff as well so no ARM/Thumb compiler
> would work off the shelf with the Cortex.

Yes until Thumb-2 you generally need some ARM code in your OS
(but not necessarily in your application).

> Also no operating system would work with Cortex.

Operating systems need to be ported to new CPUs. What's new?

> Very few semiconductor vendors have licensed Cortex cores

Perhaps Cortex is so new that none of the CPUs have been released yet?

> You will have to invest in a new set of tools to start with the Cortex
> so it will have no special benefit over any proprietary architecture.

No, existing tools will continue to work fine for Cortex. For Cortex-M
you'll need Thumb-2 capable tools of course, but these either exist today
or are close to being released by your favorite compiler vendor.
Cortex-A and -R can continue to use any existing tools of course.

Wilco

Wilco Dijkstra wrote:
> "Jim Granville" <no.spam@designtools.co.nz> wrote in message
> news:427a79f0$1@clear.net.nz...
> 
>>paulg@at-cantab-dot.net wrote:
>>
>>>Ulf Samuelsson <ulf@atmel.nospam.com> wrote:
>>>
>>>
>>>>You cannot compile an ARM program in pure Thumb mode. You need some ARM
>>>>mode stuff as well so no ARM/Thumb compiler would work off the shelf with
>>>>the Cortex.
>>>
>>>Of course you can. Obviously code running on bare metal will need some level
>>>of porting due to the fact that exception handlers had to be in ARM
>>>preiously. However code running under an OS should not.
>>>
>>>It also should be pointed out that this whole thread applies only to the
>>>Cortex-M series which is designed for the deeply embedded space. The
>>>Cortex-A and Cortex-R series support the ARM instruction set as well as
>>>Thumb-2.
>>
>>  So are you saying, the -A and -R variants, can safely swallow
>>libraries created for ARM7 cores, - ie that ALL cortex extensions are in
>>the 'opcode gaps' of older cores ?
> 
> 
> Yes - just like all previous extensions.
> 
> 
>>  Point to ponder: If the Cortex core is so wonderfull and efficent, why
>>do the -A and -R versions need ARM opcode support. Sounds a bit like a
>>reflex oops-fix ?
> 
> 
> Despite the success of Thumb, ARM code is still used a lot in many markets
> (WinCE and Linux are almost exclusively ARM for example), so dropping
> all support for the ARM instruction set would be a bit stupid, don't you
> think?
> 
> The markets Cortex-M is aimed at almost exclusively use Thumb because
> codesize is essential there. ARM is typically only used in a few routines that
> cannot be written in Thumb. Thumb-2 solves this problem (most ARM
> code can be reassembled to Thumb-2), thus making ARM "unnecessary baggage"
> in a tiny micro controller. If you think about it, it all makes sense...

Don't these two claims conflict a little ? In one you state dropping ARM 
would be stupid, then in the next, you call it unnecessary baggage ?

  As to the debate of usefullness of ARM code on uC, you could look at the
very recent posts in c.a.e, by messers Pelc and Schwob "Re: CPU 
selection", where they show that the Philips 128 bit FLASH fetch has 
moved the goalposts a bit on this one.

  I did note that ARMs 'benchmarks' to justify the Cortex, focus on 
narrow bus systems, but there ARE very small uC shipping, with wide 
busses...


>>  Will this not get very confusing in the field, since some Cortex cores
>>are binary compatible, and some are not, and some have smaller die, and
>>some do not... ?
> 
> 
> And how exactly is this different from today? All existing cores have different
> die sizes, power consumption, architectures, micro architectures, coprocessors,
> cache architectures etc. If you're not confused by the existing CPUs then you
> shouldn't be confused by Cortex.
> 
> The key is that you can always upgrade to a bigger and better core (eg from
> ARM7tdmi to ARM9E to ARM1156T2). You can sometimes literally use old
> binaries, but this will not result in the best possible performance. In some cases
> you'll have to do an OS port (eg. due to different cache architecture), but in all
> cases a recompile is highly desirable to make optimal use of the new instructions
> and micro architecture.
> 
> The Cortex family is very similar: there will be multiple CPUs at different
> performance levels within each of the A, R and M strands, and these will be
> binary compatible (ie. no recompile needed).

Err What ?! [Who is confused here ?]

Earlier in this thread, you stated
" ... so existing compilers and objects will continue to work (as long 
as they don't contain ARM code). "

  So, exactly what DOES happen when a Cortex M3 encounters an ARM (not 
thumb) opcode ?

  If it chokes, it is not binary compatible. Very simple.


> You can also move between
> them if you wish, but this obviously requires more effort (just like moving
> from ARM7tdmi to ARM1156 would).

> 
>>  ARM seem to have lost their way a bit on handling this one....
> 
> 
> I think you're a bit confused...

  I'd agree that the _situation_ is confusing....

  It would probably help if ARM used a different family name for cores 
that are NOT binary compatible.

  I can understand marketing want 'a bob each way', but there is no grey 
area in "binary compatible".

-jg