Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #30444 > unrolled thread

Arm registers

Started byHul Tytus <ht@panix.com>
First post2021-04-16 19:30 +0000
Last post2021-04-18 14:00 +0000
Articles 20 on this page of 24 — 6 participants

Back to article view | Back to comp.arch.embedded


Contents

  Arm registers Hul Tytus <ht@panix.com> - 2021-04-16 19:30 +0000
    Re: Arm registers Richard Damon <Richard@Damon-Family.org> - 2021-04-16 16:20 -0400
      Re: Arm registers Hul Tytus <ht@panix.com> - 2021-04-16 22:12 +0000
        Re: Arm registers Richard Damon <Richard@Damon-Family.org> - 2021-04-16 19:41 -0400
          Re: Arm registers Hul Tytus <ht@panix.com> - 2021-04-17 15:43 +0000
            Re: Arm registers Theo <theom+news@chiark.greenend.org.uk> - 2021-04-17 21:45 +0100
              Re: Arm registers Hul Tytus <ht@panix.com> - 2021-04-18 13:57 +0000
                Re: Arm registers Theo <theom+news@chiark.greenend.org.uk> - 2021-04-18 16:31 +0100
                  Re: Arm registers Hul Tytus <ht@panix.com> - 2021-04-19 21:22 +0000
    Re: Arm registers David Brown <david.brown@hesbynett.no> - 2021-04-17 12:43 +0200
      Re: Arm registers Hul Tytus <ht@panix.com> - 2021-04-17 15:53 +0000
        Re: Arm registers David Brown <david.brown@hesbynett.no> - 2021-04-17 18:50 +0200
          Re: Arm registers Hul Tytus <ht@panix.com> - 2021-04-17 19:30 +0000
            Re: Arm registers David Brown <david.brown@hesbynett.no> - 2021-04-18 15:02 +0200
        Re: Arm registers Richard Damon <Richard@Damon-Family.org> - 2021-04-17 13:16 -0400
          Re: Arm registers Hul Tytus <ht@panix.com> - 2021-04-17 19:23 +0000
          Re: Arm registers Theo <theom+news@chiark.greenend.org.uk> - 2021-04-17 21:42 +0100
        Re: Arm registers Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-04-17 21:09 +0300
          Re: Arm registers Hul Tytus <ht@panix.com> - 2021-04-17 19:38 +0000
            Re: Arm registers Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-04-18 11:44 +0300
              Re: Arm registers Hul Tytus <ht@panix.com> - 2021-04-18 14:07 +0000
            Re: Arm registers David Brown <david.brown@hesbynett.no> - 2021-04-18 15:10 +0200
        Re: Arm registers antispam@math.uni.wroc.pl - 2021-04-17 21:05 +0000
          Re: Arm registers Hul Tytus <ht@panix.com> - 2021-04-18 14:00 +0000

Page 1 of 2  [1] 2  Next page →


#30444 — Arm registers

FromHul Tytus <ht@panix.com>
Date2021-04-16 19:30 +0000
SubjectArm registers
Message-ID<s5cok2$cfj$1@reader1.panix.com>
sci.electronics.design
Arm Cortex assembley code

    Does the Arm Cortex support both the "thumb" 16 bit machine codes and also 
the 32 bit codes? I had been under the impression that Cortex devices only 
provided the thumb codes but a little time going through "Arm v7-M 
Architecture Reference Manual" indicates otherwise. Whether or not that 
reference manual is suitable for Cortex information needs verification also. 
There may be a more pertinent text available.
   And another question: the thumb instructions show 8 available registers 
rather than 16. However, somewhere on the internet a site states that 16 
registers are available & which group of 8 varies with the "processor state". 
Any suggestions on an Arm manual or text that defines "processor state"? The 
CPS (change processor state) machine code description in the "Arm v7-M 
Architecture Reference Manual" doesn't mention register groups. 

Hul

[toc] | [next] | [standalone]


#30447

FromRichard Damon <Richard@Damon-Family.org>
Date2021-04-16 16:20 -0400
Message-ID<XjmeI.33520$nn2.9399@fx48.iad>
In reply to#30444
On 4/16/21 3:30 PM, Hul Tytus wrote:
> sci.electronics.design
> Arm Cortex assembley code
> 
>     Does the Arm Cortex support both the "thumb" 16 bit machine codes and also 
> the 32 bit codes? I had been under the impression that Cortex devices only 
> provided the thumb codes but a little time going through "Arm v7-M 
> Architecture Reference Manual" indicates otherwise. Whether or not that 
> reference manual is suitable for Cortex information needs verification also. 
> There may be a more pertinent text available.
>    And another question: the thumb instructions show 8 available registers 
> rather than 16. However, somewhere on the internet a site states that 16 
> registers are available & which group of 8 varies with the "processor state". 
> Any suggestions on an Arm manual or text that defines "processor state"? The 
> CPS (change processor state) machine code description in the "Arm v7-M 
> Architecture Reference Manual" doesn't mention register groups. 
> 
> Hul
> 

Thumb instructions can be 16 or 32 bit, the 32 bit instruction are
different than the non-thumb 32-bit mode, which may be the confusion,
and are sometimes called Thumb-2 instructions, as they weren't available
in the first version of the Arm Processors that just had the basic 16
bit Thumb instructions.

The Arm v7-M processor has 16 32-bit registers, but the top 3 are
special purpose (LR, SP, PC), so only R0-R12 are really general purpose.

Most of the 16-bit thumb instruction can only access R0-R7, (but some
will use the special registers implicitly), to get to the full set of
registers you often need to use a 32-bit Thumb instructions.

[toc] | [prev] | [next] | [standalone]


#30454

FromHul Tytus <ht@panix.com>
Date2021-04-16 22:12 +0000
Message-ID<s5d259$fqt$1@reader1.panix.com>
In reply to#30447
Richard - you've verified that the v7-m processors use both the 16 bit
and the 32 bit instructions and for that I thank you. I'm guessing now 
the Cortex processors, not the v7-m types, are what I should be looking
at. Do you know the title of Arm's Architectural Reference Manual for the
Cortex versions?

Hul

Richard Damon <Richard@damon-family.org> wrote:
> On 4/16/21 3:30 PM, Hul Tytus wrote:
> > sci.electronics.design
> > Arm Cortex assembley code
> > 
> >     Does the Arm Cortex support both the "thumb" 16 bit machine codes and also 
> > the 32 bit codes? I had been under the impression that Cortex devices only 
> > provided the thumb codes but a little time going through "Arm v7-M 
> > Architecture Reference Manual" indicates otherwise. Whether or not that 
> > reference manual is suitable for Cortex information needs verification also. 
> > There may be a more pertinent text available.
> >    And another question: the thumb instructions show 8 available registers 
> > rather than 16. However, somewhere on the internet a site states that 16 
> > registers are available & which group of 8 varies with the "processor state". 
> > Any suggestions on an Arm manual or text that defines "processor state"? The 
> > CPS (change processor state) machine code description in the "Arm v7-M 
> > Architecture Reference Manual" doesn't mention register groups. 
> > 
> > Hul
> > 

> Thumb instructions can be 16 or 32 bit, the 32 bit instruction are
> different than the non-thumb 32-bit mode, which may be the confusion,
> and are sometimes called Thumb-2 instructions, as they weren't available
> in the first version of the Arm Processors that just had the basic 16
> bit Thumb instructions.

> The Arm v7-M processor has 16 32-bit registers, but the top 3 are
> special purpose (LR, SP, PC), so only R0-R12 are really general purpose.

> Most of the 16-bit thumb instruction can only access R0-R7, (but some
> will use the special registers implicitly), to get to the full set of
> registers you often need to use a 32-bit Thumb instructions.

[toc] | [prev] | [next] | [standalone]


#30455

FromRichard Damon <Richard@Damon-Family.org>
Date2021-04-16 19:41 -0400
Message-ID<1hpeI.35442$nn2.7997@fx48.iad>
In reply to#30454
I was looking in the Arm®v7-M Architecture Reference Manual manual.

One thing to note, there are multiple 'Cortex' lines, the Cortex-A, the
Cortex-R, and the Cortex-M

Which one you are looking at will change the -M in the manual name.

Arm v7 updated the Thumb instruction set from the Thumb-1 set which was
16 bits only, to include the Thumb-2 instructions (using unused codes in
the Thumb-1 set).



On 4/16/21 6:12 PM, Hul Tytus wrote:
> Richard - you've verified that the v7-m processors use both the 16 bit
> and the 32 bit instructions and for that I thank you. I'm guessing now 
> the Cortex processors, not the v7-m types, are what I should be looking
> at. Do you know the title of Arm's Architectural Reference Manual for the
> Cortex versions?
> 
> Hul
>

[toc] | [prev] | [next] | [standalone]


#30464

FromHul Tytus <ht@panix.com>
Date2021-04-17 15:43 +0000
Message-ID<s5evmv$5rs$1@reader1.panix.com>
In reply to#30455
Thanks again Richard. I will assume that the "Arm v7-m Architecture Reference
Manual" is most current. The only similiarly titled text on Arm's web site
was for a 64 bit version. 

Hul

Richard Damon <Richard@damon-family.org> wrote:
> I was looking in the Arm??v7-M Architecture Reference Manual manual.

> One thing to note, there are multiple 'Cortex' lines, the Cortex-A, the
> Cortex-R, and the Cortex-M

> Which one you are looking at will change the -M in the manual name.

> Arm v7 updated the Thumb instruction set from the Thumb-1 set which was
> 16 bits only, to include the Thumb-2 instructions (using unused codes in
> the Thumb-1 set).



> On 4/16/21 6:12 PM, Hul Tytus wrote:
> > Richard - you've verified that the v7-m processors use both the 16 bit
> > and the 32 bit instructions and for that I thank you. I'm guessing now 
> > the Cortex processors, not the v7-m types, are what I should be looking
> > at. Do you know the title of Arm's Architectural Reference Manual for the
> > Cortex versions?
> > 
> > Hul
> >

[toc] | [prev] | [next] | [standalone]


#30477

FromTheo <theom+news@chiark.greenend.org.uk>
Date2021-04-17 21:45 +0100
Message-ID<V5y*3iThy@news.chiark.greenend.org.uk>
In reply to#30464
Hul Tytus <ht@panix.com> wrote:
> Thanks again Richard. I will assume that the "Arm v7-m Architecture Reference
> Manual" is most current. The only similiarly titled text on Arm's web site
> was for a 64 bit version. 

You probably want the ARMv8-M architecture reference, unless you're dealing
with older hardware:
https://developer.arm.com/documentation/ddi0553/latest

THeo

[toc] | [prev] | [next] | [standalone]


#30490

FromHul Tytus <ht@panix.com>
Date2021-04-18 13:57 +0000
Message-ID<s5hdru$q5c$1@reader1.panix.com>
In reply to#30477
I'm aiming at the 32 bit devices and looking at the v7 text.

Hul

Theo <theom+news@chiark.greenend.org.uk> wrote:
> Hul Tytus <ht@panix.com> wrote:
> > Thanks again Richard. I will assume that the "Arm v7-m Architecture Reference
> > Manual" is most current. The only similiarly titled text on Arm's web site
> > was for a 64 bit version. 

> You probably want the ARMv8-M architecture reference, unless you're dealing
> with older hardware:
> https://developer.arm.com/documentation/ddi0553/latest

> THeo

[toc] | [prev] | [next] | [standalone]


#30493

FromTheo <theom+news@chiark.greenend.org.uk>
Date2021-04-18 16:31 +0100
Message-ID<S5y*XqXhy@news.chiark.greenend.org.uk>
In reply to#30490
Hul Tytus <ht@panix.com> wrote:
> I'm aiming at the 32 bit devices and looking at the v7 text.

ARMv8-M devices /are/ 32 bit.

ARMv8-A brought in the 64 bit instruction set (AArch64) for Application
cores.  The classic 32 bit instruction set (AArch32) remains optional for
Application cores.  v8-A (and v9-A) describe the Application class
architecture.

ARMv8-M describes the Microcontroller class architecture and it's all 32
bit.  For example v8-M brought in TrustZone instructions which weren't in
ARMv7-M.

You should check which core(s) you plan to use and what architecture they
are.  For example the Cortex M55 follows ARMv8.1-M while the Cortex M7
follows ARMv7E-M.

Theo

[toc] | [prev] | [next] | [standalone]


#30525

FromHul Tytus <ht@panix.com>
Date2021-04-19 21:22 +0000
Message-ID<s5ksaf$ccv$1@reader1.panix.com>
In reply to#30493
Thanks Theo. I will get the version 8 manual. Is the title for that "Armv8-m
Archetecture Reference Manual"? From what you've said, I was probably looking
at the v8-A manual.

Hul

Theo <theom+news@chiark.greenend.org.uk> wrote:
> Hul Tytus <ht@panix.com> wrote:
> > I'm aiming at the 32 bit devices and looking at the v7 text.

> ARMv8-M devices /are/ 32 bit.

> ARMv8-A brought in the 64 bit instruction set (AArch64) for Application
> cores.  The classic 32 bit instruction set (AArch32) remains optional for
> Application cores.  v8-A (and v9-A) describe the Application class
> architecture.

> ARMv8-M describes the Microcontroller class architecture and it's all 32
> bit.  For example v8-M brought in TrustZone instructions which weren't in
> ARMv7-M.

> You should check which core(s) you plan to use and what architecture they
> are.  For example the Cortex M55 follows ARMv8.1-M while the Cortex M7
> follows ARMv7E-M.

> Theo

[toc] | [prev] | [next] | [standalone]


#30460

FromDavid Brown <david.brown@hesbynett.no>
Date2021-04-17 12:43 +0200
Message-ID<s5ee5e$9u8$1@dont-email.me>
In reply to#30444
On 16/04/2021 21:30, Hul Tytus wrote:
> sci.electronics.design
> Arm Cortex assembley code
> 
>     Does the Arm Cortex support both the "thumb" 16 bit machine codes and also 
> the 32 bit codes? I had been under the impression that Cortex devices only 
> provided the thumb codes but a little time going through "Arm v7-M 
> Architecture Reference Manual" indicates otherwise. Whether or not that 
> reference manual is suitable for Cortex information needs verification also. 
> There may be a more pertinent text available.
>    And another question: the thumb instructions show 8 available registers 
> rather than 16. However, somewhere on the internet a site states that 16 
> registers are available & which group of 8 varies with the "processor state". 
> Any suggestions on an Arm manual or text that defines "processor state"? The 
> CPS (change processor state) machine code description in the "Arm v7-M 
> Architecture Reference Manual" doesn't mention register groups. 
> 

You seem to be mixing up a range of different things here.  (That is not
surprising - ARM has /seriously/ confusing terminology here, with
similar names for different things, different names for similar things,
different numbers for instruction sets, architectures, and implementations.)

The answers you got from Richard are all correct - I am just wording
things a little differently, to see if that helps your understand.

In the beginning, Arm used a 32-bit fixed-size instruction set.  It was
fast, but not very compact.  Most instructions had three registers (so
you have "Rx = Ry + Rz"), with 16 registers - that adds up to 12 bits of
instruction just for the registers.

When they started getting serious in the microcontroller market, this
extra space was a cost - it meant code was bigger than for other
microcontrollers, and you needed a bigger and more expensive flash.  So
they invented the "Thumb" mode.  Here, instructions are 16-bit only and
so much more compact.  These were a subset of the ARM instructions -
instructions only cover two registers, and for many operations these
could only come from 8 registers (so only needed 6 bits of the
instruction set).  The cpu decoder expanded the Thumb instructions into
32-bit ARM instructions before executing them.

Thumb gave more compact code, but slower code, and there were some
things you simply could not do in Thumb mode.  So the microcontrollers
had to support both instruction sets, and you would switch sets in code
(interrupts, for example, would be in ARM mode for speed).  It was all a
bit of a mess.

So ARM invented "Thumb-2".  This was a set of 32-bit instructions that
can be mixed along with the slightly re-named "Thumb-1" 16-bit
instructions.  Sometimes it is now all called "Thumb2", or just "Thumb"
(since for the vast majority of ARM programmers, 16-bit only thumb was
ancient history from before they started using the devices).  16-bit and
32-bit instructions are called "narrow" and "wide" forms.  These new
32-bit additions to thumb meant you could get a mixed code that was
compact, fast, and covered all needs (including full access to all
registers).

So for the Cortex-M devices, Thumb2 is the only set needed - they don't
support "old-style" 32-bit Arm instructions.  You no longer need to
worry about changing states or modes, you are always in "thumb2" mode.

Different Cortex-M processors support different subsets and extensions
of this, so it is important that you inform your compiler of exactly
which device you are using.  Do that, and you don't really need to care
about the details for the most part - the compiler does the work.  But
it can be interesting to know what is going on.




There are also Cortex-A devices for applications processors - basically,
running Linux (including Android) or, occasionally, Windows.  And there
are Cortex-R devices for safety-critical systems.  But I expect you are
talking about Cortex-M devices here.

[toc] | [prev] | [next] | [standalone]


#30466

FromHul Tytus <ht@panix.com>
Date2021-04-17 15:53 +0000
Message-ID<s5f09r$5rs$2@reader1.panix.com>
In reply to#30460
David - I'm in the process of putting together an assembler for the Arm
32 bit processors. There is no all-knowing compiler envolved so I need
to know what machine codes are valid for a given processor. Any suggestions
on where that information can be found?

Hul

David Brown <david.brown@hesbynett.no> wrote:
> On 16/04/2021 21:30, Hul Tytus wrote:
> > sci.electronics.design
> > Arm Cortex assembley code
> > 
> >     Does the Arm Cortex support both the "thumb" 16 bit machine codes and also 
> > the 32 bit codes? I had been under the impression that Cortex devices only 
> > provided the thumb codes but a little time going through "Arm v7-M 
> > Architecture Reference Manual" indicates otherwise. Whether or not that 
> > reference manual is suitable for Cortex information needs verification also. 
> > There may be a more pertinent text available.
> >    And another question: the thumb instructions show 8 available registers 
> > rather than 16. However, somewhere on the internet a site states that 16 
> > registers are available & which group of 8 varies with the "processor state". 
> > Any suggestions on an Arm manual or text that defines "processor state"? The 
> > CPS (change processor state) machine code description in the "Arm v7-M 
> > Architecture Reference Manual" doesn't mention register groups. 
> > 

> You seem to be mixing up a range of different things here.  (That is not
> surprising - ARM has /seriously/ confusing terminology here, with
> similar names for different things, different names for similar things,
> different numbers for instruction sets, architectures, and implementations.)

> The answers you got from Richard are all correct - I am just wording
> things a little differently, to see if that helps your understand.

> In the beginning, Arm used a 32-bit fixed-size instruction set.  It was
> fast, but not very compact.  Most instructions had three registers (so
> you have "Rx = Ry + Rz"), with 16 registers - that adds up to 12 bits of
> instruction just for the registers.

> When they started getting serious in the microcontroller market, this
> extra space was a cost - it meant code was bigger than for other
> microcontrollers, and you needed a bigger and more expensive flash.  So
> they invented the "Thumb" mode.  Here, instructions are 16-bit only and
> so much more compact.  These were a subset of the ARM instructions -
> instructions only cover two registers, and for many operations these
> could only come from 8 registers (so only needed 6 bits of the
> instruction set).  The cpu decoder expanded the Thumb instructions into
> 32-bit ARM instructions before executing them.

> Thumb gave more compact code, but slower code, and there were some
> things you simply could not do in Thumb mode.  So the microcontrollers
> had to support both instruction sets, and you would switch sets in code
> (interrupts, for example, would be in ARM mode for speed).  It was all a
> bit of a mess.

> So ARM invented "Thumb-2".  This was a set of 32-bit instructions that
> can be mixed along with the slightly re-named "Thumb-1" 16-bit
> instructions.  Sometimes it is now all called "Thumb2", or just "Thumb"
> (since for the vast majority of ARM programmers, 16-bit only thumb was
> ancient history from before they started using the devices).  16-bit and
> 32-bit instructions are called "narrow" and "wide" forms.  These new
> 32-bit additions to thumb meant you could get a mixed code that was
> compact, fast, and covered all needs (including full access to all
> registers).

> So for the Cortex-M devices, Thumb2 is the only set needed - they don't
> support "old-style" 32-bit Arm instructions.  You no longer need to
> worry about changing states or modes, you are always in "thumb2" mode.

> Different Cortex-M processors support different subsets and extensions
> of this, so it is important that you inform your compiler of exactly
> which device you are using.  Do that, and you don't really need to care
> about the details for the most part - the compiler does the work.  But
> it can be interesting to know what is going on.




> There are also Cortex-A devices for applications processors - basically,
> running Linux (including Android) or, occasionally, Windows.  And there
> are Cortex-R devices for safety-critical systems.  But I expect you are
> talking about Cortex-M devices here.

[toc] | [prev] | [next] | [standalone]


#30468

FromDavid Brown <david.brown@hesbynett.no>
Date2021-04-17 18:50 +0200
Message-ID<s5f3l2$u2k$1@dont-email.me>
In reply to#30466
On 17/04/2021 17:53, Hul Tytus wrote:
> David - I'm in the process of putting together an assembler for the Arm
> 32 bit processors. There is no all-knowing compiler envolved so I need
> to know what machine codes are valid for a given processor. Any suggestions
> on where that information can be found?
> 

Why?  There are perfectly good Arm assemblers available freely.  Is this
just for fun, or do you have a good reason behind it?

Arm use what they call "Unified Assembly Language" to let people write
assembly in a single consistent format that can be used to generated
object code in the various instruction formats.  That means a single UAL
instruction might lead to multiple object code instructions if necessary
(for example, loading a register with a constant might need multiple
instructions depending on the constant value and the instruction set).

Add to that there /lots/ of different subsets of the instructions that
are available on different devices.  It is a big effort writing an
assembler her.


> 
> David Brown <david.brown@hesbynett.no> wrote:
>> On 16/04/2021 21:30, Hul Tytus wrote:
>>> sci.electronics.design
>>> Arm Cortex assembley code
>>>
>>>     Does the Arm Cortex support both the "thumb" 16 bit machine codes and also 
>>> the 32 bit codes? I had been under the impression that Cortex devices only 
>>> provided the thumb codes but a little time going through "Arm v7-M 
>>> Architecture Reference Manual" indicates otherwise. Whether or not that 
>>> reference manual is suitable for Cortex information needs verification also. 
>>> There may be a more pertinent text available.
>>>    And another question: the thumb instructions show 8 available registers 
>>> rather than 16. However, somewhere on the internet a site states that 16 
>>> registers are available & which group of 8 varies with the "processor state". 
>>> Any suggestions on an Arm manual or text that defines "processor state"? The 
>>> CPS (change processor state) machine code description in the "Arm v7-M 
>>> Architecture Reference Manual" doesn't mention register groups. 
>>>
> 
>> You seem to be mixing up a range of different things here.  (That is not
>> surprising - ARM has /seriously/ confusing terminology here, with
>> similar names for different things, different names for similar things,
>> different numbers for instruction sets, architectures, and implementations.)
> 
>> The answers you got from Richard are all correct - I am just wording
>> things a little differently, to see if that helps your understand.
> 
>> In the beginning, Arm used a 32-bit fixed-size instruction set.  It was
>> fast, but not very compact.  Most instructions had three registers (so
>> you have "Rx = Ry + Rz"), with 16 registers - that adds up to 12 bits of
>> instruction just for the registers.
> 
>> When they started getting serious in the microcontroller market, this
>> extra space was a cost - it meant code was bigger than for other
>> microcontrollers, and you needed a bigger and more expensive flash.  So
>> they invented the "Thumb" mode.  Here, instructions are 16-bit only and
>> so much more compact.  These were a subset of the ARM instructions -
>> instructions only cover two registers, and for many operations these
>> could only come from 8 registers (so only needed 6 bits of the
>> instruction set).  The cpu decoder expanded the Thumb instructions into
>> 32-bit ARM instructions before executing them.
> 
>> Thumb gave more compact code, but slower code, and there were some
>> things you simply could not do in Thumb mode.  So the microcontrollers
>> had to support both instruction sets, and you would switch sets in code
>> (interrupts, for example, would be in ARM mode for speed).  It was all a
>> bit of a mess.
> 
>> So ARM invented "Thumb-2".  This was a set of 32-bit instructions that
>> can be mixed along with the slightly re-named "Thumb-1" 16-bit
>> instructions.  Sometimes it is now all called "Thumb2", or just "Thumb"
>> (since for the vast majority of ARM programmers, 16-bit only thumb was
>> ancient history from before they started using the devices).  16-bit and
>> 32-bit instructions are called "narrow" and "wide" forms.  These new
>> 32-bit additions to thumb meant you could get a mixed code that was
>> compact, fast, and covered all needs (including full access to all
>> registers).
> 
>> So for the Cortex-M devices, Thumb2 is the only set needed - they don't
>> support "old-style" 32-bit Arm instructions.  You no longer need to
>> worry about changing states or modes, you are always in "thumb2" mode.
> 
>> Different Cortex-M processors support different subsets and extensions
>> of this, so it is important that you inform your compiler of exactly
>> which device you are using.  Do that, and you don't really need to care
>> about the details for the most part - the compiler does the work.  But
>> it can be interesting to know what is going on.
> 
> 
> 
> 
>> There are also Cortex-A devices for applications processors - basically,
>> running Linux (including Android) or, occasionally, Windows.  And there
>> are Cortex-R devices for safety-critical systems.  But I expect you are
>> talking about Cortex-M devices here.

[toc] | [prev] | [next] | [standalone]


#30474

FromHul Tytus <ht@panix.com>
Date2021-04-17 19:30 +0000
Message-ID<s5fd0s$8qr$2@reader1.panix.com>
In reply to#30468
David: writing an assembler isn't really a "big effort" although
the documentation of the Arm and the heaps of machine codes it
has moves in that direction. As for "why?", there are several
reasons and fun is one.
   Thanks for the direction regarding the Arm device.

Hul

David Brown <david.brown@hesbynett.no> wrote:
> On 17/04/2021 17:53, Hul Tytus wrote:
> > David - I'm in the process of putting together an assembler for the Arm
> > 32 bit processors. There is no all-knowing compiler envolved so I need
> > to know what machine codes are valid for a given processor. Any suggestions
> > on where that information can be found?
> > 

> Why?  There are perfectly good Arm assemblers available freely.  Is this
> just for fun, or do you have a good reason behind it?

> Arm use what they call "Unified Assembly Language" to let people write
> assembly in a single consistent format that can be used to generated
> object code in the various instruction formats.  That means a single UAL
> instruction might lead to multiple object code instructions if necessary
> (for example, loading a register with a constant might need multiple
> instructions depending on the constant value and the instruction set).

> Add to that there /lots/ of different subsets of the instructions that
> are available on different devices.  It is a big effort writing an
> assembler her.


> > 
> > David Brown <david.brown@hesbynett.no> wrote:
> >> On 16/04/2021 21:30, Hul Tytus wrote:
> >>> sci.electronics.design
> >>> Arm Cortex assembley code
> >>>
> >>>     Does the Arm Cortex support both the "thumb" 16 bit machine codes and also 
> >>> the 32 bit codes? I had been under the impression that Cortex devices only 
> >>> provided the thumb codes but a little time going through "Arm v7-M 
> >>> Architecture Reference Manual" indicates otherwise. Whether or not that 
> >>> reference manual is suitable for Cortex information needs verification also. 
> >>> There may be a more pertinent text available.
> >>>    And another question: the thumb instructions show 8 available registers 
> >>> rather than 16. However, somewhere on the internet a site states that 16 
> >>> registers are available & which group of 8 varies with the "processor state". 
> >>> Any suggestions on an Arm manual or text that defines "processor state"? The 
> >>> CPS (change processor state) machine code description in the "Arm v7-M 
> >>> Architecture Reference Manual" doesn't mention register groups. 
> >>>
> > 
> >> You seem to be mixing up a range of different things here.  (That is not
> >> surprising - ARM has /seriously/ confusing terminology here, with
> >> similar names for different things, different names for similar things,
> >> different numbers for instruction sets, architectures, and implementations.)
> > 
> >> The answers you got from Richard are all correct - I am just wording
> >> things a little differently, to see if that helps your understand.
> > 
> >> In the beginning, Arm used a 32-bit fixed-size instruction set.  It was
> >> fast, but not very compact.  Most instructions had three registers (so
> >> you have "Rx = Ry + Rz"), with 16 registers - that adds up to 12 bits of
> >> instruction just for the registers.
> > 
> >> When they started getting serious in the microcontroller market, this
> >> extra space was a cost - it meant code was bigger than for other
> >> microcontrollers, and you needed a bigger and more expensive flash.  So
> >> they invented the "Thumb" mode.  Here, instructions are 16-bit only and
> >> so much more compact.  These were a subset of the ARM instructions -
> >> instructions only cover two registers, and for many operations these
> >> could only come from 8 registers (so only needed 6 bits of the
> >> instruction set).  The cpu decoder expanded the Thumb instructions into
> >> 32-bit ARM instructions before executing them.
> > 
> >> Thumb gave more compact code, but slower code, and there were some
> >> things you simply could not do in Thumb mode.  So the microcontrollers
> >> had to support both instruction sets, and you would switch sets in code
> >> (interrupts, for example, would be in ARM mode for speed).  It was all a
> >> bit of a mess.
> > 
> >> So ARM invented "Thumb-2".  This was a set of 32-bit instructions that
> >> can be mixed along with the slightly re-named "Thumb-1" 16-bit
> >> instructions.  Sometimes it is now all called "Thumb2", or just "Thumb"
> >> (since for the vast majority of ARM programmers, 16-bit only thumb was
> >> ancient history from before they started using the devices).  16-bit and
> >> 32-bit instructions are called "narrow" and "wide" forms.  These new
> >> 32-bit additions to thumb meant you could get a mixed code that was
> >> compact, fast, and covered all needs (including full access to all
> >> registers).
> > 
> >> So for the Cortex-M devices, Thumb2 is the only set needed - they don't
> >> support "old-style" 32-bit Arm instructions.  You no longer need to
> >> worry about changing states or modes, you are always in "thumb2" mode.
> > 
> >> Different Cortex-M processors support different subsets and extensions
> >> of this, so it is important that you inform your compiler of exactly
> >> which device you are using.  Do that, and you don't really need to care
> >> about the details for the most part - the compiler does the work.  But
> >> it can be interesting to know what is going on.
> > 
> > 
> > 
> > 
> >> There are also Cortex-A devices for applications processors - basically,
> >> running Linux (including Android) or, occasionally, Windows.  And there
> >> are Cortex-R devices for safety-critical systems.  But I expect you are
> >> talking about Cortex-M devices here.

[toc] | [prev] | [next] | [standalone]


#30488

FromDavid Brown <david.brown@hesbynett.no>
Date2021-04-18 15:02 +0200
Message-ID<s5hal9$1t8$1@dont-email.me>
In reply to#30474
(Please don't top-post.  Usenet has its standards for formatting posts,
and it is best to stick to those.)

On 17/04/2021 21:30, Hul Tytus wrote:
> David: writing an assembler isn't really a "big effort" although
> the documentation of the Arm and the heaps of machine codes it
> has moves in that direction. As for "why?", there are several
> reasons and fun is one.
>    Thanks for the direction regarding the Arm device.
> 
> Hul

I have always felt that "fun" is a perfectly good reason for any
programming project - you don't need more than that.  But there is no
doubt that as assemblers go, making one for ARM is complicated by all
its variations and the fact that unlike most assemblies, there is not a
one-to-one relationship between assembly instructions and machine code
instructions.

But have fun with it anyway!

[toc] | [prev] | [next] | [standalone]


#30469

FromRichard Damon <Richard@Damon-Family.org>
Date2021-04-17 13:16 -0400
Message-ID<BJEeI.21060$lyv9.6815@fx35.iad>
In reply to#30466
The ARM Architecture Reference Manuela give the detailed encoding of
every instruction. You may need to look at the documentation for a given
processor class to see which instructions are legal for that given
processor, as that varies by machine class/sub-class.

It will be a bit of work to assemble the info, a lot of 'paper' to wade
through.

On 4/17/21 11:53 AM, Hul Tytus wrote:
> David - I'm in the process of putting together an assembler for the Arm
> 32 bit processors. There is no all-knowing compiler envolved so I need
> to know what machine codes are valid for a given processor. Any suggestions
> on where that information can be found?
> 
> Hul
> 

[toc] | [prev] | [next] | [standalone]


#30473

FromHul Tytus <ht@panix.com>
Date2021-04-17 19:23 +0000
Message-ID<s5fcjv$8qr$1@reader1.panix.com>
In reply to#30469
Yes, I've noticed a slight difficulty so far. Once again, I do appreciate
you aid along those lines.

Hul

Richard Damon <Richard@damon-family.org> wrote:
> The ARM Architecture Reference Manuela give the detailed encoding of
> every instruction. You may need to look at the documentation for a given
> processor class to see which instructions are legal for that given
> processor, as that varies by machine class/sub-class.

> It will be a bit of work to assemble the info, a lot of 'paper' to wade
> through.

> On 4/17/21 11:53 AM, Hul Tytus wrote:
> > David - I'm in the process of putting together an assembler for the Arm
> > 32 bit processors. There is no all-knowing compiler envolved so I need
> > to know what machine codes are valid for a given processor. Any suggestions
> > on where that information can be found?
> > 
> > Hul
> > 

[toc] | [prev] | [next] | [standalone]


#30476

FromTheo <theom+news@chiark.greenend.org.uk>
Date2021-04-17 21:42 +0100
Message-ID<U5y*piThy@news.chiark.greenend.org.uk>
In reply to#30469
Richard Damon <Richard@damon-family.org> wrote:
> The ARM Architecture Reference Manuela give the detailed encoding of
> every instruction. You may need to look at the documentation for a given
> processor class to see which instructions are legal for that given
> processor, as that varies by machine class/sub-class.
> 
> It will be a bit of work to assemble the info, a lot of 'paper' to wade
> through.

Arm has a machine-readable architecture description that's amenable to
formal proof - describes all of the instructions and where all the bits go. 
There are pathways to take this and generate various bits of toolchain, if
you would rather not do it manually:
https://alastairreid.github.io/ARM-v8a-xml-release/

Theo

[toc] | [prev] | [next] | [standalone]


#30471

FromTauno Voipio <tauno.voipio@notused.fi.invalid>
Date2021-04-17 21:09 +0300
Message-ID<s5f885$vrc$1@dont-email.me>
In reply to#30466
On 17.4.21 18.53, Hul Tytus wrote:
> David - I'm in the process of putting together an assembler for the Arm
> 32 bit processors. There is no all-knowing compiler envolved so I need
> to know what machine codes are valid for a given processor. Any suggestions
> on where that information can be found?


Why on earth?

What is wrong with the GNU arm-none-eabi-as?

The arm-none-eabi-gcc has switches for different processor
architectures.

ARM has an instruction reference card for Thumb2, with
different processors marked on the card.

-- 

-TV

[toc] | [prev] | [next] | [standalone]


#30475

FromHul Tytus <ht@panix.com>
Date2021-04-17 19:38 +0000
Message-ID<s5fdgd$8qr$3@reader1.panix.com>
In reply to#30471
Tauno - just the GNU copyright provides reason for not using it.
I would expect anyone using it, or considering same, to a major extent, whether
government sponsored or private, would look closely.

Hul

Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:
> On 17.4.21 18.53, Hul Tytus wrote:
> > David - I'm in the process of putting together an assembler for the Arm
> > 32 bit processors. There is no all-knowing compiler envolved so I need
> > to know what machine codes are valid for a given processor. Any suggestions
> > on where that information can be found?


> Why on earth?

> What is wrong with the GNU arm-none-eabi-as?

> The arm-none-eabi-gcc has switches for different processor
> architectures.

> ARM has an instruction reference card for Thumb2, with
> different processors marked on the card.

> -- 

> -TV

[toc] | [prev] | [next] | [standalone]


#30484

FromTauno Voipio <tauno.voipio@notused.fi.invalid>
Date2021-04-18 11:44 +0300
Message-ID<s5grgt$ule$1@dont-email.me>
In reply to#30475
Your code is just data passed through the tools, the GNU
copyright does not limit it.

You'll be safe as long as you are not going to modify the
tools. Even then you have to publish the modifications, not
the code processed using the tools.

For libraries, there is the GNU LGPL coversin such cases
and permitting to use them.

-- 

-TV


On 17.4.2021 22:38 PM, Hul Tytus wrote:
> Tauno - just the GNU copyright provides reason for not using it.
> I would expect anyone using it, or considering same, to a major extent, whether
> government sponsored or private, would look closely.
> 
> Hul
> 
> Tauno Voipio <tauno.voipio@notused.fi.invalid> wrote:
>> On 17.4.21 18.53, Hul Tytus wrote:
>>> David - I'm in the process of putting together an assembler for the Arm
>>> 32 bit processors. There is no all-knowing compiler envolved so I need
>>> to know what machine codes are valid for a given processor. Any suggestions
>>> on where that information can be found?
> 
> 
>> Why on earth?
> 
>> What is wrong with the GNU arm-none-eabi-as?
> 
>> The arm-none-eabi-gcc has switches for different processor
>> architectures.
> 
>> ARM has an instruction reference card for Thumb2, with
>> different processors marked on the card.
> 
>> -- 
> 
>> -TV

[toc] | [prev] | [next] | [standalone]


Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch.embedded


csiph-web