Anyone know of a good forum for ARM assembly language?

On 2011-12-28, David Brown <david@westcontrol.removethisbit.com> wrote:
> On 28/12/2011 02:52, Simon Clubley wrote:
>> On 2011-12-27, Rich Webb<bbew.ar@mapson.nozirev.ten>  wrote:
>
>>> Oh hell yes. ARM assembly is beautiful but I can't imagine wanting to do
>>> more than a pin-wiggler in straight assembly.
>>>
>>
>> You still need to write (at least for traditional devices) the initial
>> startup code as well as the interrupt/abort handlers in assembly language.
>>
>
> In most cases, you can write startup code in C.  It is perfectly 
> possible to write C code before the initial C environment has been 
> brought up.  You need to take certain precautions - like avoiding 

Yes, that's what I do. However, the few lines of _initial_ startup code
(the code that runs right out of reset) needs to be in assembly because
you do need to load a temporary SP in order for your C routine to be able
to use temporary stack variables (I'm not talking about anything in .data
or .bss here, but things like loop counters) as well as setup the various
processor modes permanent stack pointers and CPSRs once the main C startup
code has finished.

I suppose you could use embedded assembly code within a C routine to do
this, but I prefer to have a small outer layer assembly routine be in
control of the startup which calls a couple of C routines (one before
.data/.bss has been setup; one afterwards) to do the bulk of the startup.

> anything that requires the stack until it is in place (you want to do 
> that first thing), and being careful with memory and avoiding incorrect 
> assumptions.  You will also want to check the generated assembly code to 
> be sure it is all safe.  But there is no good reason for writing startup 
> code in assembly - I have often replaced all or part of a toolchain's 
> standard assembly startup code with better, clearer, faster and smaller 
> code written in C.
>
> And almost all toolchains will let you write your interrupt handlers in 
> C.  There may be a small amount of wrapper assembly, especially when you 
> are using a common interrupt vector before farming out to specific 
> interrupt functions, but the main work of the interrupt function can be 
> in C.
>

In my defence, it was past midnight local time when I wrote that. :-)

Yes, I meant the interrupt wrapper, not the full interrupt handler;
the main interrupt handlers are in C. My abort handlers are also a few
lines of assembly (which dumps the register state and abort type to a
.bss area) before calling a C level abort routine.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

On 28/12/2011 10:54, Simon Clubley wrote:
> On 2011-12-28, David Brown<david@westcontrol.removethisbit.com>  wrote:
>> On 28/12/2011 02:52, Simon Clubley wrote:
>>> On 2011-12-27, Rich Webb<bbew.ar@mapson.nozirev.ten>   wrote:
>>
>>>> Oh hell yes. ARM assembly is beautiful but I can't imagine wanting to do
>>>> more than a pin-wiggler in straight assembly.
>>>>
>>>
>>> You still need to write (at least for traditional devices) the initial
>>> startup code as well as the interrupt/abort handlers in assembly language.
>>>
>>
>> In most cases, you can write startup code in C.  It is perfectly
>> possible to write C code before the initial C environment has been
>> brought up.  You need to take certain precautions - like avoiding
>
> Yes, that's what I do. However, the few lines of _initial_ startup code
> (the code that runs right out of reset) needs to be in assembly because
> you do need to load a temporary SP in order for your C routine to be able
> to use temporary stack variables (I'm not talking about anything in .data
> or .bss here, but things like loop counters) as well as setup the various
> processor modes permanent stack pointers and CPSRs once the main C startup
> code has finished.
>
> I suppose you could use embedded assembly code within a C routine to do
> this, but I prefer to have a small outer layer assembly routine be in
> control of the startup which calls a couple of C routines (one before
> .data/.bss has been setup; one afterwards) to do the bulk of the startup.
>

I think we are on the same level here.  I usually put such code in "asm" 
statements in a C file, since they are typically only a couple of 
instructions long.  It's usually a good idea to have a basic stack in 
place before jumping to C - internal ram is very useful for that.  I 
usually also do the clearing of .bss and copying of .data in C - let the 
compiler do its job of unrolling and optimising.

>> anything that requires the stack until it is in place (you want to do
>> that first thing), and being careful with memory and avoiding incorrect
>> assumptions.  You will also want to check the generated assembly code to
>> be sure it is all safe.  But there is no good reason for writing startup
>> code in assembly - I have often replaced all or part of a toolchain's
>> standard assembly startup code with better, clearer, faster and smaller
>> code written in C.
>>
>> And almost all toolchains will let you write your interrupt handlers in
>> C.  There may be a small amount of wrapper assembly, especially when you
>> are using a common interrupt vector before farming out to specific
>> interrupt functions, but the main work of the interrupt function can be
>> in C.
>>
>
> In my defence, it was past midnight local time when I wrote that. :-)
>
> Yes, I meant the interrupt wrapper, not the full interrupt handler;
> the main interrupt handlers are in C. My abort handlers are also a few
> lines of assembly (which dumps the register state and abort type to a
> .bss area) before calling a C level abort routine.
>
> Simon.
>

On 2011-12-27, Rich Webb <bbew.ar@mapson.nozirev.ten> wrote:
> On Tue, 27 Dec 2011 12:18:18 -0600, Les Cargill <lcargill99@comcast.com>
> wrote:
>
>>Jim Stewart wrote:
>>> One that covers evaluating and setting up
>>> toolchains for assembly and debugging?
>>
>>I did find this:
>>http://openocd.sourceforge.net/doc/html/Config-File-Guidelines.html
>>
>>That being said...
>>
>>1) They're mainly done in 'C'.
>
> Oh hell yes. ARM assembly is beautiful but I can't imagine wanting to
> do more than a pin-wiggler in straight assembly.

I wrote an IP checksum routine in ARM assembly once.  It took several
days of sweat to get it to the point where it was faster than the
generic C routine in the NetBSD stack sources -- and doing so required
some hints from an expert regarding some obscure features of the ARM
ALU.

> (Hijacking the thread, I suppose but...) I've not found BSPs to be all
> that useful. I find that I can spend more time trying to find just where
> they've hidden the, e.g., clock configuration stuff and what I need to
> tickle to get the various clocks setup how *I* want them, than the time
> it takes me to read the user manual sections and diddle the registers
> directly.
>
> Your mileage may vary but when I run across things like:
>
> // Setup CAN0
> ... some code to init the CAN 0 peripheral ...
>
> // Setup CAN0 [sic]
> .. some code to init the CAN 1 peripheral that was obviously a
> copy/paste from the CAN 0 block, with some but not all references
> pointing to the right peripheral ...

The sample code provided by most of the CPU vendors is the absolute
worst.  I don't know who they hire to write that stuff...

> I'd just as soon go back to the book and do it myself.

Sometimes "the book" is so badly done that finding some code that
works is the only way to get started (I'm talking about you, Samsung).

-- 
Grant Edwards               grant.b.edwards        Yow! The FALAFEL SANDWICH
                                  at               lands on my HEAD and I
                              gmail.com            become a VEGETARIAN ...

Les Cargill wrote:
> Rich Webb wrote:
>> (Hijacking the thread, I suppose but...) I've not found BSPs to be all
>> that useful. I find that I can spend more time trying to find just where
>> they've hidden the, e.g., clock configuration stuff and what I need to
>> tickle to get the various clocks setup how *I* want them, than the time
>> it takes me to read the user manual sections and diddle the registers
>> directly.
[...]
>> I'd just as soon go back to the book and do it myself.
> 
> Even the SDRAM controller?

Sure. (That was the last thing I did before chrismas holidays :-)

> For a sufficiently advanced ARM,
> that's where the BSP and/or JTAG debugger-plus-register file
> came in really handy.

The BSP was really handy as an example: you need these units to set up
clocks, these for SPI, and here finally you have the SDRAM.

But other than that, it was a big mess. Two u-boot derivatives stacked
above each other, each initialising some part of the hardware, plus an
operating system BSP initialising some other parts and reinitialising
some of the original parts differently -- that's what I happily replace.

By four lines of assembly plus a few hundred lines of C, which compile
to 3.5 k, I might add, for the other half of the thread: the compiler
does a much better job at register-dancing than I do.


  Stefan