Roger,
I'd actually pretty much agree with most of what you say. I didn't
mean to suggest there was any harm in learning assembler, just that
there is no need to become expert, or to use it more than necessary.
The compiler problems reported here have tended to be in the area of
using non-portable features of the langauge inappropriately (e.g.
bit-fields to access hardware registers), and as you mention
interrupt modifiers. I'd be inclined to add in-line assembler to the
list of things best avoided.
To clarify further, my recommendation would be:
- use assembler where there's no other option, and based on some
proven pre-existing template
- use 'C' everywhere else, provided it's 100% ANSI-C (i.e. no
special keywords)
- turn all warnings on when compiling, and don't even think of
running anything that gives a warning when compiled
- learn enough assembler to be able to read and understand what
others (including the compiler) produce
That way tends to increase the re-use that can be made of code, and
greatly simplifies moving from one environment to another. It also
means that any straightforward processing (as opposed to I/O) code
can be tested elswhere first (we do a lot of DSP type stuff that is
invariably tested fully before putting it onto the target).
One of the great things about the ARM is that this approach is very
possible: a typical 8051 or PIC 'C' version hardly qualifies the use
of the name (being 'C'-like, rather than 'C').
Having said all that, the very worst bugs to find are where the
compiler generates bad code (been there, done that). This tends to
happen where the optimiser messes up. If you suspect this is
happenening, a good test is to re-compile with optimisation off. If
the problem doesn't go away, it's less likely to be a compiler
issue. (Clearly this last statement is not in any way definitive,
but it's a good first test to try).
On the specific example that prompted this (reading a value from a
register and storing it a buffer) I'd argue it's a lot easier and
more importantly less error prone in 'C', no matter how expert you
are in assembler. And yes, I do now know that the example was to
illustrate a point rather than be a recommendation.
I'd agree 100% about your comment on always aiming to learn, and
living from one's experiences.
I'm probably rambling at this stage, so I'll stop!
Brendan
--- In lpc2000@yahoogroups.com, "roger_lynx" <roger_lynx@...> wrote:
>
> --- In lpc2000@yahoogroups.com, "brendanmurphy37" <brendan.murphy@>
> wrote:
> >
> >
> > Jerome/Peter,
> >
> > I think the example below is a very good illustration of why
it's
> > best not to bother with assembler at all, if you can avoid it.
>
> I beg to differ, since the recently posted messages about
> writing stub for ISR handling of GNU complier may just be an
argument
> for knowing and understanding assembly language, and ARM
architecture
> in general.
>
> In how many versions of gcc this feature is not working right?
> I am not picking on gcc, this type of "things" do happen
elsewhere, as
> well.
> It might be tempting to start YAHW (yet another holy war), but when
> one lives from one's own experience, rather than from any dogma,
life gets
> simpler and more enjoyable. Live and learn, learn and live.
Assembly
> or whatever.
> ;-)
> Go for it Jerome!
>
> > Unless you're doing something very unusual, you can get away
with
> > less than about fifty lines of assembler. All you need is:
> >
> > - interrupt vector table and startup (to setup stacks)
> > - IRQ interrupt dispatch stub (there's been a couple of very
good
> > examples of this posted here recently)
> > - maybe a pair of functions to disable/re-enable interrupts
> >
> > Everything else can be in 'C', including the basic environment
setup
> > (e.g. copying initialised data, zeroing uninitialised data etc.;
PLL
> > setup, VIC, MAM setup, peripheral interrupt handlers etc. etc.).
> >
>
> That is true; to write 50 lines of assembly code *well* will
require
> quite a commitment to learn more than just few opcodes.
>
> > Note that the assembler code mentioned above will typically suit
for
> > every system you're working on (i.e. is done once), and can
typically
> > be found elsewhere (here for example).
>
> You can copy code, whether it is C or assembler without
understanding
> of what it does and how - anytime.
>
> > RISC and RISC-like architectures are very much designed around
the
> > ideas of utilising optimising compilers to make use of the
simplified
> > instruction sets, rather than human programmers.
>
> As much I admire compiler designers, they are human programmers as
> well, and as such prone to make errors.
> There is no compiler version 1.0 (for too long).
> ;-)
>
>
> > You need some expertise to be able to understand ARM assembler
> > (mainly an ability to lookup and understand the "ARM ARM" book),
and
> > modify it if necessary, but my guess is that there are very few
ARM
> > (or MIPS or other RISC) assembler "experts" out there, and
certainly
> > no need to become one.
>
> Agreed.
> They are very very few of those, and it is more than "ability to
look
> up.." the ARM ARM book, I can confirm this fact anytime I am in
> contact with one of those gurus.
> :-)
>
>
> > All this is just an opinion, though!
> >
> > Brendan
>
> And so were those lines above that I wrote.
>
> Cheers
>
> Roger
>
> >
> > --- In lpc2000@yahoogroups.com, jk jlkj <njad2002@> wrote:
> > >
> > > Hi Peter,
> > >
> > > Ur code sure looks complex with all the assembly code. To
tell u
> > the truth i cant understand a single line of it.
> > > I am currenty working on a project which uses LPC2214. But i
have
> > written the entire code in C. Could u guide me, as to how i can
go
> > about writing some assembly language code for my project.
Beginning
> > from, how do i start learning one and what sort of small
programs i
> > can begin with for the IAR assmebler and how do i incooperate my
then
> > acquired knkowledge of assembly into my existing project.
> > >
> > > I know u are in a bit of trouble right now trying to sort
out ur
> > problem, and my timing is inapproproate. However, I would really
> > appreciate a little bit of guidance from some one like you who
is
> > already strong in assembly language.
> > >
> > >
> > > Regards,
> > > Jerome
> > >
> > > Peter Jakacki <peterjak@> wrote:
> > > Hi Paul,
> > > The buffer is 64 bytes and it is not spilling over. It employs
a
> > simple
> > > wraparound and normally I would put some error handling around
this
> > but
> > > it is not a problem as the application is always reading the
buffer.
> > >
> > > *Peter*
> > >
> > > The listing again (slightly tidier)
> > >
> > >
> > > CPU: LPC2138/2148
> > > TOOL: IAR Workbench V4.10B
> > >
> > > This works:
> > > -------------------------
> > > 106 0000D85C 0F412DE9 KBISR: stmfd sp!,{r0-r3,MP,lr}
> > > 107 0000D860 4084A0E3 ldr MP,=RAM
> > > 108 0000D864 CC001FE5 kbrdl: ldr r0,SPCRc
> > > 109 0000D868 042090E5 ldr r2,[r0,#SPISR-
SPCR]
> > > 110 0000D86C 800012E3 tst r2,#80h
> > > 111 0000D870 DBE3FF0A beq EnableVIC
> > > 112 0000D874 0110A0E3 mov r1,#1
> > > 113 0000D878 1C10C0E5 strb r1,[r0,#SPINT-
SPCR]
> > > 114 0000D87C 081090E5 ldr r1,[r0,#SPDR-SPCR]
> > > 115 0000D880 34001FE5 ldr r0,=kbbuf
> > > 116 0000D884 4030D0E5 ldrb r3,[r0,#kbwr-
kbbuf]
> > > 117 0000D888 002083E0 add r2,r3,r0
> > > 118 0000D88C 001082E5 str r1,[r2]
> > > 119 0000D890 043083E2 add r3,r3,#4
> > > 120 0000D894 3F3003E2 and r3,r3,#kbbufsz-1
> > > 121 0000D898 4030C0E5 strb r3,[r0,#kbwr-
kbbuf]
> > > 122 0000D89C F0FFFFEA b kbrdl
> > > -------------------------
> > >
> > > This doesn't quite work:
> > > -------------------------
> > > 106 0000D85C 0F412DE9 KBISR: stmfd sp!,{r0-r3,MP,lr}
> > > 107 0000D860 4084A0E3 ldr MP,=RAM
> > > 108 0000D864 CC001FE5 kbrdl: ldr r0,SPCRc
> > > 109 0000D868 042090E5 ldr r2,[r0,#SPISR-
SPCR]
> > > 110 0000D86C 800012E3 tst r2,#80h
> > > 111 0000D870 DBE3FF0A beq EnableVIC
> > > 112 0000D874 0110A0E3 mov r1,#1
> > > 113 0000D878 1C10C0E5 strb r1,[r0,#SPINT-
SPCR]
> > > 114 0000D87C 081090E5 ldr r1,[r0,#SPDR-SPCR]
> > > 115 0000D880 34001FE5 ldr r0,=kbbuf
> > > 116 0000D884 4030D0E5 ldrb r3,[r0,#kbwr-
kbbuf]
> > > 117 0000D888 002083E0 add r2,r3,r0
> > > !!!!!!!! THIS LINE IS THE PROBLEM !!!!!!
> > > 118 0000D88C B010C2E1 strh r1,[r2]
> > > 119 0000D890 023083E2 add r3,r3,#2
> > > 120 0000D894 3F3003E2 and r3,r3,#kbbufsz-1
> > > 121 0000D898 4030C0E5 strb r3,[r0,#kbwr-
kbbuf]
> > > 122 0000D89C F0FFFFEA b kbrdl
> > > -------------------------
> > >
> > >
> > > *Peter*
> > >
> > >
> > >
> > >
> > > Paul Curtis wrote:
> > > > How big is your buffer? To be specific, what value does
kbbufsz
> > have?
> > > >
> > > > --
> > > > Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> > > > CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3
> > processors
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Peter Jakacki [mailto:peterjak@]
> > > >> Sent: 28 March 2006 09:03
> > > >> To: lpc2000@yahoogroups.com
> > > >> Subject: [lpc2000] ARM halfword bugs?
> > > >>
> > > >> I came across a glitch in my PS/2 keyboard code where every
> > > >> 11th keystroke my system would experience some sort of
> > > >> corruption. I checked the code and I checked the code and
> > > >> everything looks right (it's assembler). Finally in
> > > >> desperation I changed the halfword store to buffer into a
> > > >> full word store and then incremented the index by 4 instead
> > > >> of 2 and now it works perfectly. The buffer is on a word
> > boundary.
> > > >>
> > > >> Normally I wouldn't bother mentioning all this but I have
had
> > > >> a few other episodes in the past somewhat similar to this
> > > >> before where I replaced the halfword stores with byte or
word
> > > >> stores and everything works fine again.
> > > >>
> > > >> I suspect the assembler as I have dissected other opcodes
> > > >> before and from memory I think I found problems in that the
> > > >> machine code was incorrect.
> > > >>
> > > >> Could it be that there is a bug in the ARM core or the
> > > >> assembler? Does anyone know of similar problems?
> > > >>
> > >
> > >
> > > ---------------------------------
> > > YAHOO! GROUPS LINKS
> > >
> > >
> > > Visit your group "lpc2000" on the web.
> > >
> > > To unsubscribe from this group, send an email to:
> > > lpc2000-unsubscribe@yahoogroups.com
> > >
> > > Your use of Yahoo! Groups is subject to the Yahoo! Terms
of
> > Service.
> > >
> > >
> > > ---------------------------------
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------
> > > Jiyo cricket on Yahoo! India cricket
> > > Yahoo! Messenger Mobile Stay in touch with your buddies all
the Show quoted textHide quoted text
> > time.
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
>