But that doesn't affect portability. I couldn't imagine what
14740
functions you couold possibly have, mine number less than 1000, but for
most jobs they cover at least 80% of the necessary code. There are too
many things that ANSI C standard leaves to the implementer, especially
with embedded systems, to make C 100% portable. this is a myth.
Lets see, so far this year I've worked on LPC2138, LPC2106, ADuC7024,
MSP430, MAXQ2000, PIC10F, dsPIC and Z8F04, so I guess I'm not stuck on
anything.
Al
alex@alex... wrote:
>Al,
>You R right that the libraries are important. But more important is to
>develop them. My personal libraries count at
>this time 14740 functions all written in ANSI C. This means portability. One
>great asset of an ANSI HLL is the portability :) But if you're stuck on
the
>430 this might not be important to you :)
>
>Alex
>
>
>----- Original Message -----
>From: "Onestone" <onestone@ones...>
>To: <msp430@msp4...>
>Sent: Friday, August 19, 2005 3:03 AM
>Subject: Re: [msp430] Re: Interrupt occurs in ISR A
>
>
>I've used both too, though I admit I haven't recently used C on a
micro
>'in anger' because i simply haven't seen any personal
advantage in doing
>so. To me the advantage of any HLL is the laibraries. Without them why
>bother? Simply redefining putchar() won't go far when you're doing
graphics.
>
>Al
>
>Matthias Weingart wrote:
>
>
>
>>On Fri, Aug 19, 2005 at 03:20:07PM +0930, Onestone wrote:
>>
>>
>>
>>
>>
>>>>I hope "embedded C" (that is using more CPU-features
in C) will become a
>>>>standard very fast.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>Now this might sound really strange but I would LOVE to see a EC
that
>>>was stripped right down to the functions that mean anything to a
micro,
>>>that handled bits cleanly, that allowed flag access, especially with
>>>shifts,
>>>
>>>
>>>
>>>
>>
>>
>>
>>>and that included things like a cprintf that allowed you to
>>>write data to one of the 4 most popular character LCD panels (in 4
or 8
>>>bit mode), after first setting their I/O allocation. Or a gprintf
that
>>>did the same for graphics panels, again after initialisation, and
which
>>>covered perhaps the 4 most popular controller families. Or a kscanf,
>>>that implemented a keyboard string interface, and a kgets that
>>>implements a single keyboard get function, perhaps similar routines
for
>>>IIC, SPI, UART, CAN and USB, then why not A/D, D/A and finally some
>>>timer functions like tpulse, tperiod, spwm, tduty, gpulse, gperiod
etc
>>>where t = time, and g = generate.
>>>
>>>
>>>
>>>
>>You mix basic features and libraries here. I think a eC standard should
>>
>>
>only
>
>
>>handle simple things (cpu related, like shifts, bit access ...)
>>- not libraries. And well with each good c-compiler you can of course
use
>>the printf with any of your output devices. You just need to redefine
the
>>putchar().
>>
>>I think the people here that vote for ASM have never used C extensively
on
>>
>>
>a
>
>
>>micro to see the advantages. (Of course there is a hurdle - some simple
>>things look more complicated in C than in ASM.) I have used both (and
still
>>use both) and from my experiences C makes sense - absolutely.
>>
>> Matthias
>>
>>
>>
>>.
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>.
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>---
>avast! Antivirus: Inbound message clean.
>Virus Database (VPS): 0533-3, 08/17/2005
>Tested on: 8/19/2005 8:24:29 AM
>avast! - copyright (c) 1988-2005 ALWIL Software.
>http://www.avast.com
>
>
>
>
>
>
>.
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
Al,
You R right that the libraries are important. But more important is to
develop them. My personal libraries count at
this time 14740 functions all written in ANSI C. This means portability. One
great asset of an ANSI HLL is the portability :) But if you're stuck on the
430 this might not be important to you :)
Alex
----- Original Message -----
From: "Onestone" <onestone@ones...>
To: <msp430@msp4...>
Sent: Friday, August 19, 2005 3:03 AM
Subject: Re: [msp430] Re: Interrupt occurs in ISR A
I've used both too, though I admit I haven't recently used C on a
micro
'in anger' because i simply haven't seen any personal advantage
in doing
so. To me the advantage of any HLL is the laibraries. Without them why
bother? Simply redefining putchar() won't go far when you're doing
graphics.
Al
Matthias Weingart wrote:
>On Fri, Aug 19, 2005 at 03:20:07PM +0930,
Onestone wrote:
>
>
>
>>>I hope "embedded C" (that is using more CPU-features in C)
will become a
>>>standard very fast.
>>>
>>>
>>>
>>Now this might sound really strange but I would LOVE to see a EC that
>>was stripped right down to the functions that mean anything to a micro,
>>that handled bits cleanly, that allowed flag access, especially with
>>shifts,
>>
>>
>
>
>
>>and that included things like a cprintf that allowed you to
>>write data to one of the 4 most popular character LCD panels (in 4 or 8
>>bit mode), after first setting their I/O allocation. Or a gprintf that
>>did the same for graphics panels, again after initialisation, and which
>>covered perhaps the 4 most popular controller families. Or a kscanf,
>>that implemented a keyboard string interface, and a kgets that
>>implements a single keyboard get function, perhaps similar routines for
>>IIC, SPI, UART, CAN and USB, then why not A/D, D/A and finally some
>>timer functions like tpulse, tperiod, spwm, tduty, gpulse, gperiod etc
>>where t = time, and g = generate.
>>
>>
>
>You mix basic features and libraries here. I think a eC standard should
only
>handle simple things (cpu related, like shifts, bit
access ...)
>- not libraries. And well with each good c-compiler you can of course use
>the printf with any of your output devices. You just need to redefine the
>putchar().
>
>I think the people here that vote for ASM have never used C extensively on
a
>micro to see the advantages. (Of course there is a
hurdle - some simple
>things look more complicated in C than in ASM.) I have used both (and still
>use both) and from my experiences C makes sense - absolutely.
>
> Matthias
>
>
>
>.
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
.
Yahoo! Groups Links
---
avast! Antivirus: Inbound message clean.
Virus Database (VPS): 0533-3, 08/17/2005
Tested on: 8/19/2005 8:24:29 AM
avast! - copyright (c) 1988-2005 ALWIL Software.
http://www.avast.com
Reply by Jonathan Kirwan●August 19, 20052005-08-19
On Fri, 19 Aug 2005 08:10:09 +0200, Matthias wrote:
>I think the people here that vote for ASM have
never used C extensively on a
>micro to see the advantages.
Not so. I've been using C since 1978, when I was using it in Unix
operating system work under version 6. I've completed perhaps a dozen
projects in it in the last 6 years alone, on exclusively embedded
systems. If I added PC applications, it would be many more than that.
Jon
Reply by Onestone●August 19, 20052005-08-19
I've used both too, though I admit I haven't recently used C on a
micro
'in anger' because i simply haven't seen any personal advantage
in doing
so. To me the advantage of any HLL is the laibraries. Without them why
bother? Simply redefining putchar() won't go far when you're doing
graphics.
Al
Matthias Weingart wrote:
>On Fri, Aug 19, 2005 at 03:20:07PM +0930,
Onestone wrote:
>
>
>
>>>I hope "embedded C" (that is using more CPU-features in C)
will become a
>>>standard very fast.
>>>
>>>
>>>
>>Now this might sound really strange but I would LOVE to see a EC that
>>was stripped right down to the functions that mean anything to a micro,
>>that handled bits cleanly, that allowed flag access, especially with
>>shifts,
>>
>>
>
>
>
>>and that included things like a cprintf that allowed you to
>>write data to one of the 4 most popular character LCD panels (in 4 or 8
>>bit mode), after first setting their I/O allocation. Or a gprintf that
>>did the same for graphics panels, again after initialisation, and which
>>covered perhaps the 4 most popular controller families. Or a kscanf,
>>that implemented a keyboard string interface, and a kgets that
>>implements a single keyboard get function, perhaps similar routines for
>>IIC, SPI, UART, CAN and USB, then why not A/D, D/A and finally some
>>timer functions like tpulse, tperiod, spwm, tduty, gpulse, gperiod etc
>>where t = time, and g = generate.
>>
>>
>
>You mix basic features and libraries here. I think a eC standard should only
>handle simple things (cpu related, like shifts, bit access ...)
>- not libraries. And well with each good c-compiler you can of course use
>the printf with any of your output devices. You just need to redefine the
>putchar().
>
>I think the people here that vote for ASM have never used C extensively on a
>micro to see the advantages. (Of course there is a hurdle - some simple
>things look more complicated in C than in ASM.) I have used both (and still
>use both) and from my experiences C makes sense - absolutely.
>
> Matthias
>
>
>
>.
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
Reply by Matthias Weingart●August 19, 20052005-08-19
On Fri, Aug 19, 2005 at 03:20:07PM +0930, Onestone wrote:
> >I hope "embedded C" (that is using
more CPU-features in C) will become a
> >standard very fast.
> >
> Now this might sound really strange but I would LOVE to see a EC that
> was stripped right down to the functions that mean anything to a micro,
> that handled bits cleanly, that allowed flag access, especially with
> shifts,
> and that included things like a cprintf that
allowed you to
> write data to one of the 4 most popular character LCD panels (in 4 or 8
> bit mode), after first setting their I/O allocation. Or a gprintf that
> did the same for graphics panels, again after initialisation, and which
> covered perhaps the 4 most popular controller families. Or a kscanf,
> that implemented a keyboard string interface, and a kgets that
> implements a single keyboard get function, perhaps similar routines for
> IIC, SPI, UART, CAN and USB, then why not A/D, D/A and finally some
> timer functions like tpulse, tperiod, spwm, tduty, gpulse, gperiod etc
> where t = time, and g = generate.
You mix basic features and libraries here. I think a eC standard should only
handle simple things (cpu related, like shifts, bit access ...)
- not libraries. And well with each good c-compiler you can of course use
the printf with any of your output devices. You just need to redefine the
putchar().
I think the people here that vote for ASM have never used C extensively on a
micro to see the advantages. (Of course there is a hurdle - some simple
things look more complicated in C than in ASM.) I have used both (and still
use both) and from my experiences C makes sense - absolutely.
Matthias
Reply by Onestone●August 19, 20052005-08-19
Matthias Weingart wrote:
>On Fri, Aug 19, 2005 at 12:40:18AM +0930,
Onestone wrote:
>
>
>
>>You can't use inp(), or input(0, or gets() or getchar() without
first
>>defining code that processes them.
>>
>>
>
>There is _no_ difference between C and ASM. In both you have to define your
>output functions (and I had never used the C functions printf and so on).
>
>
>
>>In fact about the only things that
>>work straight out of the box are control structures like for() and
>>while, and switch., and maths functions. Any of these are as easy to
>>implement in asm as they are in C, and often easier.
>>
>>
>
>A real advantage of C. You have tested and proven libraries. No
>need to waste time to wrote that functions yourself.
>
>
So, other than maths, what really useful libraries for embedded work
come with C. I am not being pedantic here, I'd really like to know what
people here use. The sort of thing I do is read a sensor. Filter the
data. Write this to flash. Display it on a graphics LCD,. Except for
Maths there is nothing useful for this in C. this is something that has
puzzled me for a long time. On the other hand when I write for the PC
there are lots of things I might want to do using standard functions
>
>
>>Have a look at a large program,
>>then tell me how many complex standard C functions do you use without
>>having to write them first?
>>
>>
>
>Math lib. Floating Math Lib. I can simply write a*(b+c/x+y) in one
line.
>Compare it to the asm code ;-). Is Asm supporting the input of
>floating point constants? (I have not used floating point in asm yet).
>
I've never found a use for floating point on a micro. integrer in,
integer out, why screw it up? so it comes down to Maths.lib. Well I've
got one of those in asm
>Compares are much better readable
"a>b" (I always have problems to see
>at the first look what JGE or JNE JGT or else is meaning).
>
I don't have problem seeing this, in fact it is more obvious to a
newcomer, especially where double operand use is concerned, as in &&,
||, >>, etc.
>Also "if ((a || b) && not c)" is
better readable as a list of conditional
>jumps.
>
>
But you sacrifice a lot for this simple gain., which, in well commented
text in any language, would be noted.
>>You initalise the system in a similar, but less
clear manner than I
>>would in asm. You write ISR's in a less clear, and more cumbersome
>>manner than I would in asm. You have no inherent bit handling and no
>>direct control of register allocation.
>>
>>
>
>Al, well you are really looking through the C-generated code with a
>fine-tooth comb. It does not matter in most cases how ugly the asm code is.
>Plenty of flash, and cpu-time are often available.
>
>Only in very few cases (in my code 2%?) I write asm routines. This 2% are
>most often the interrupt routines and some critical parts in the main part,
>(e.g. routines with shift operations ..;-)
>
>I remember my beginnings. I started with 8051 asm; a large firmware. Main
>problem was space for the local variables (I used the internal RAM, only
>128bytes, very small for stack and variables). Some years later I rewrote
>that project in C. Using the Keil C compiler that was overlaying local
>variables in the RAM. I had much much more space available after that.
>Looking at the generated code I also learned some tricks I did not know
>before. I think beginners are writing much better "code" in C than
in ASM
>- as long as they understand the specifics of uC programming a little
>and dont put a MemAlloc in the interrupt ;-).
>
>Sure you have some drawbacks of C. No real shift operation through carry
>flag, setting bits looks complicated. You have a "strange" startup
routine
>(it isnt strange, the code is known, you can change it to your needs). But
>this are only a few disadvantages.
>
>
I consider the disadvantages to be huge, and have difficulty seeing the
gains.
>I hope "embedded C" (that is using more
CPU-features in C) will become a
>standard very fast.
>
Now this might sound really strange but I would LOVE to see a EC that
was stripped right down to the functions that mean anything to a micro,
that handled bits cleanly, that allowed flag access, especially with
shifts, and that included things like a cprintf that allowed you to
write data to one of the 4 most popular character LCD panels (in 4 or 8
bit mode), after first setting their I/O allocation. Or a gprintf that
did the same for graphics panels, again after initialisation, and which
covered perhaps the 4 most popular controller families. Or a kscanf,
that implemented a keyboard string interface, and a kgets that
implements a single keyboard get function, perhaps similar routines for
IIC, SPI, UART, CAN and USB, then why not A/D, D/A and finally some
timer functions like tpulse, tperiod, spwm, tduty, gpulse, gperiod etc
where t = time, and g = generate.
Of course it would have to be a standard, have a committee to decide
what that will be, so that everybody can have their 2 cents worth, and
the "if you want your feature I want mine too" rule applies, so
you'd
end up with a bloody awful, bloated monster anyway. It's a nice thought
though.
It isn't that I dislike C. I dislike C for mainframes being used as C
for micros. It just don't fit! perhaps it should be called E.
Al
Reply by Jonathan Kirwan●August 18, 20052005-08-18
On Thu, 18 Aug 2005 17:45:23 +0200, Matthias wrote:
><snip>
>> In fact about the only things that
>> work straight out of the box are control structures like for() and
>> while, and switch., and maths functions. Any of these are as easy to
>> implement in asm as they are in C, and often easier.
>
>A real advantage of C. You have tested and proven libraries. No
>need to waste time to wrote that functions yourself.
I just checked two recent applications I wrote in C for embedded use.
The explicit standard C library functions used in both amounted to
string copy and string compare and in one of them an sprintf() because
it was handy and I could afford the space it required. I find the
much touted standard C library largely unused in my applications.
>> Have a look at a large program,
>> then tell me how many complex standard C functions do you use without
>> having to write them first?
>
>Math lib. Floating Math Lib. I can simply write a*(b+c/x+y) in one
line.
>Compare it to the asm code ;-).
Of course, if you are allowed to limit the evidence you consider, you
could reasonably conclude the earth is flat, too. You should take a
more comprehensive view, rather than just pick a detail here and try
and make a broader point from it.
Generally, what I find to be most valuable are the worked out details
of the mathematics, physics, and so on. This has _nothing_ whatsoever
to do with the language used, when it comes to implementation. All
the effort applied to understanding the breadth and depth of an
application space, the sensors involved and so on, all the way through
to developing an output or closed-loop control that performs well is
where most of the serious time is at. And as Al also points out, most
micros have rather similar logical features so that an algorithm coded
up for an 8051 isn't at all difficult to port to the MSP430, despite
register width differences and so on. The basic ideas remain.
Now, there are cases where C is clearly easier to port. Certainly, in
areas where the abstractions are neatly nestled in a comfortable bed
wrapped in a blanket that isolates them from the real world, for
example. (Like strcpy() for example.)
But as I said, if you are allowed to limit the discussion on porting
to narrow cases, you could reasonably conclude just about anything.
>Is Asm supporting the input of
>floating point constants? (I have not used floating point in asm yet).
><snip>
The times are as rare as hen's teeth when I use a floating point
library in embedded applications. Your data arrives in integer form
via the ADC and it leaves in integer form via the DAC. Why in hell
would you go and siphon in a floating point library and all the
pitfalls that may attend it? Even in cases where I deal with dynamic
ranges of 6-8 orders of magnitude (and I routinely work on such
systems dealing with measured currents spanning from fA to uA, for
example), there are only a couple of customized routines I use and
they are highly tested for the application requirements.
I generally don't use floating point, even with C. Not in embedded
applications.
...
Matthias, you are treading very close to arguing that C has advantages
which mean one shouldn't use assembly for any application. And that
simply isn't true, even if the question is limited to the more extreme
case of applications where it is already known that they will be
ported to other controllers at some point in the future.
Jon
Reply by Matthias Weingart●August 18, 20052005-08-18
On Fri, Aug 19, 2005 at 12:40:18AM +0930, Onestone wrote:
> The rationale for this is quite simple. Embedded
systems are NOt like
> PC's (obvious) where you can make full use of the many complex
functions
> and instructions in the C language. However most of the things you do on
> a micro don't really fit the C model. There aren't many standard
C
> functions that relate to everyday embedded design. You can't take
> (x)printf(0 and its many similar functions and use it straight out of
> the box. you actually have to write the procedures for the display
> device you're using.
>
> You can't use inp(), or input(0, or gets() or getchar() without first
> defining code that processes them.
There is _no_ difference between C and ASM. In both you have to define your
output functions (and I had never used the C functions printf and so on).
> In fact about the only things that
> work straight out of the box are control structures like for() and
> while, and switch., and maths functions. Any of these are as easy to
> implement in asm as they are in C, and often easier.
A real advantage of C. You have tested and proven libraries. No
need to waste time to wrote that functions yourself.
> Have a look at a large program,
> then tell me how many complex standard C functions do you use without
> having to write them first?
Math lib. Floating Math Lib. I can simply write a*(b+c/x+y) in one line.
Compare it to the asm code ;-). Is Asm supporting the input of
floating point constants? (I have not used floating point in asm yet).
Compares are much better readable "a>b" (I always have problems to
see
at the first look what JGE or JNE JGT or else is meaning).
Also "if ((a || b) && not c)" is better readable as a list of
conditional
jumps.
> You initalise the system in a similar, but less
clear manner than I
> would in asm. You write ISR's in a less clear, and more cumbersome
> manner than I would in asm. You have no inherent bit handling and no
> direct control of register allocation.
Al, well you are really looking through the C-generated code with a
fine-tooth comb. It does not matter in most cases how ugly the asm code is.
Plenty of flash, and cpu-time are often available.
Only in very few cases (in my code 2%?) I write asm routines. This 2% are
most often the interrupt routines and some critical parts in the main part,
(e.g. routines with shift operations ..;-)
I remember my beginnings. I started with 8051 asm; a large firmware. Main
problem was space for the local variables (I used the internal RAM, only
128bytes, very small for stack and variables). Some years later I rewrote
that project in C. Using the Keil C compiler that was overlaying local
variables in the RAM. I had much much more space available after that.
Looking at the generated code I also learned some tricks I did not know
before. I think beginners are writing much better "code" in C than in
ASM
- as long as they understand the specifics of uC programming a little
and dont put a MemAlloc in the interrupt ;-).
Sure you have some drawbacks of C. No real shift operation through carry
flag, setting bits looks complicated. You have a "strange" startup
routine
(it isnt strange, the code is known, you can change it to your needs). But
this are only a few disadvantages.
I hope "embedded C" (that is using more CPU-features in C) will become
a
standard very fast.
M.
> augusto einsfeldt wrote:
>
> >One of best things about this list is the mix of deep technical
insights
> >with amusement...
> >
> >-Augusto
> >
> >
> >-----Original Message-----
> >From: msp430@msp4... [mailto:msp430@msp4...] On Behalf Of
> >rolf.freitag@rolf...
> >Sent: Thursday, August 18, 2005 11:26 AM
> >To: msp430@msp4...
> >Subject: Re: [msp430] Re: Interrupt occurs in ISR A
> >
> >
> >
> >Hi,
> >
> >the main reason for using high level languages instead of ASM is that
> >ASM is inefficient; you need more time to code (and debug)in ASM.
> >See the old "The Mythical Man-Month".
> >
> >Regards,
> >
> >Rolf
> >
> >
> >msp430@msp4... schrieb am 18.08.05 15:51:03:
> >
> >
> >>Alex, right. ASM coders are usually very diligent people, or people
> >>that go through the C-generated code with a fine-tooth comb. The C
> >>coders are more from the lazy fraction of mankind and can live with
> >>some suboptimal but working solutions :-). And do not forget the
code
> >>reusability. ASM code has to be rewritten from one to another
platform
> >>- well it is mostly simple - but costs time and introduce new
> >>failures.
> >>
> >>Oh well, I should close my mouth. I sweared not to fan the fire of
the
> >>ASM vs. C flame war...
> >>
> >>M.
> >>
> >>On Thu, Aug 18, 2005 at 08:58:11AM -0400, alex@alex... wrote:
> >>
> >>
> >>>Yes Al, but like the baker that can't smell his own bread,
you are
> >>>not observing how much more work you do in ASM. High Level
Languages
> >>>are doing all that time consuming management work for you :)
> >>>
> >>>I am not trying you convert you Al :)
> >>>
> >>>Alex
> >>>
> >>>
> >>>----- Original Message -----
> >>>From: "Onestone" <onestone@ones...>
> >>>To: <msp430@msp4...>
> >>>Sent: Thursday, August 18, 2005 12:28 AM
> >>>Subject: Re: [msp430] Re: Interrupt occurs in ISR A
> >>>
> >>>
> >>>FORTH uses an entirely different structure and notation to
either
> >>>asm or C.
> >>>
> >>>I don't use macros either, if you've watched my posts
at all you'll
> >>>find that I rarely if ever use them. That isn't to say
that use of
> >>>macros isn't use of assembler, most modern assemblers are
called
> >>>MACRO ASSEMBLERS.
> >>>
> >>>Firstly this is asm, I don't need to declare anything in
the formal
> >>>manner required by C. For structures that need to be
initialised I
> >>>can either do what you might do in C, run a function that
calculates
> >>>their values, and intialises them, or initalise them from a
table in
> >>>FLASH. This assumes that they are volatile of course. Otherwise
I
> >>>just initlaise them in a flash table.To allocate the structure
I can
> >>>simply allocate the memory, naming the flelds in my allocation,
then
> >>>further reserving enough memory to allow the maximum number of
> >>>structures. In fact I can do better. I can allocate N
structures of
> >>>M bytes, and, if this overflows memory I can easily arrange to
> >>>temporarily store some of the tables in my flash data base. C
can't
> >>>do that without a lot of work. Rather than waste memory I can
re-use
> >>>the same block of memory over and over again, with different
local
> >>>structures if I need them. But the tendency in asm is probably
to
> >>>not use this method as much as you might in C, but to
micromanage
> >>>memory a bit better by using alternative methods.
> >>>
> >>>as to memory allocation, well this is THE most asked question
by C
> >>>programmers in this, and other forums. "How do I fix the
address of
> >>>a variable", or "How to I reserve a register".
The answer to the
> >>>first seems to vary a little between compilers, the answer in
asm is
> >>>simply by using EQU or DS when naming the variable, the answer
in C
> >>>to the secodn is that usually you can't, unless the
compiler vendor
> >>>allows you 1 or 2 registers, while in asm I have total control
of my
> >>>register allocation.
> >>>
> >>>If I wanted to, in asm I could do... MOV R4,&0213H.
> >>>
> >>>Of course this is fraught with danger, since there is no
indication
> >>>to me whether or not the target RAM address is really in RAM
for
> >>>this micro, is meant to be a word (of course not, since these
are
> >>>even boundaries), so I couldn't readily spot the fact that
it should
> >>>be a MOV.B. It will assemble fine, and run, but not the way you
> >>>might expect it to. Notice the total lack of a declaration.
> >>>
> >>>I could also use:-
> >>>
> >>>THISVAR EQU 0213H
> >>>
> >>>But again when I see
> >>>
> >>> MOV R4,&THISVAR
> >>>
> >>>There's nothing to tell me it should be a byte access.
> >>>
> >>>Then I could use the form:-
> >>>
> >>> ORG RAMSTART
> >>>
> >>>HEAP DS 512
;RESERVE 512
> >>>BYTES FOR LOCAL STRUCTURES
> >>>THISVAR DS 2 ;RESERVE
2 BYTES
> >>>FOR ANY OLD VARIABLE
> >>>
> >>>Now I have explicitly defined THISVAR as using 2 bytes, and my
MOV
> >>>will be correct, because the RAM allocation occurs at an even
> >>>address.
> >>>
> >>>Now I CAN access it as either a pair of bytes, or a word, but
it's
> >>>default is word. again this is something easier to do in asm
than C.
> >>>I have absolute control in asm of ALL my memory. the downside
is
> >>>that I have to be aware of this when programming, and make sure
I do
> >>>control it. In C you don't need to worry about this,
it's taken care
> >>>of for you, at the cost of a little flexibility.
> >>>
> >>>Now asm by its very nature tends to be global. You can use
local and
> >>>extern, public, etc but that is an individual choice. I simply
don't
> >>>like constraints that I don't impose myself.
> >>>
> >>>Al
> >>>
> >>>alex@alex... wrote:
> >>>
> >>>
> >>>
> >>>>Al,
> >>>>How do you declare, initialize and mange a structure in
ASM. Or
> >>>>Memory allocation? If R going to mention MACROS, then you
are not
> >>>>using ASM anymore :) ASM is like Latin. It's good in
it's own
> >>>>Church and for it's own followers
> >>>>:)
> >>>>Alex
> >>>>
> >>>>BTW.
> >>>>One can find a neutral ground between ASM and any other
high level
> >>>>language by simply using FORTH :) A
> >>>>
> >>>>----- Original Message -----
> >>>>From: "Onestone" <onestone@ones...>
> >>>>To: <msp430@msp4...>
> >>>>Sent: Wednesday, August 17, 2005 9:38 PM
> >>>>Subject: Re: [msp430] Re: Interrupt occurs in ISR A
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Hi again, just one last thing before I let this thread
go for good
> >>>>>
> >>>>>Clifford Heath wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Of course, but a good global optimiser will produce
excellent
> >>>>>>code in
> >>>>>>
> >>>>>>almost any case. And that's the point -
you're free to express
> >>>>>>yourself in code (i.e., write your program for
*humans*), but you
> >>>>>>get a result that's good for the *machine*
anyway. There's a
> >>>>>>tradeoff, though not a big one, nevertheless how
you lean depends
> >>>>>>on whether you have a greater need to pander to
people or to the
> >>>>>>machine. When you're working in a team of ten
or twenty, on 2
> >>>>>>million lines of code (as I am), the people issues
> >>>>>>matter a *lot*.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>This is one thing I've never really understood.
The assumption
> >>>>>that C is more user friendly, and easier to read than
asm. I don't
> >>>>>get it.
> >>>>>
> >>>>> MOV, ADD, SUB, RRC, RLA, MAC, MPY, DIV, BIC, BIS,
BSET, DECSZ
> >>>>>etc are all very common abbreviations across a wide
range of
> >>>>>microprocessors and controllers, and are easily
understood. at
> >>>>>least as easily as LTOA, ? /R, /N, ^=, &,
&&, FLOOR, PRAGMA,
> >>>>>MALLOC, CALLOC, * (*) AND ALL ITS VARIATIONS.
> >>>>>
> >>>>>Both are equally crytpic, and both are easily
understandable. C
> >>>>>contains far more nonalphanumeric symbols, which
complicates
> >>>>>things, but the consequences and actions of any
'instruction' are
> >>>>>more 'wdiespread, it does more, which can be both
a blessing and a
> >>>>>hindrance.
> >>>>>
> >>>>>asm uses few symbols, few instructions and each
instruction does
> >>>>>just one clearly defined thing, with possible actiosn
associated
> >>>>>with it such as flag setting. It is therefore less to
learn,
> >>>>>easier to grasp, but requires more instructions per
high level
> >>>>>task usually..
> >>>>>
> >>>>>I don't see that one is more easily read by humans
than the other
> >>>>>though. Either can be made illegible, and either can be
made
> >>>>>readable. being more voluble isn't necessary being
more readable.
> >>>>>I cannot remember the long convolluted names so beloved
of C++
> >>>>>pogrammers for example, which makes debugging much
harder, whereas
> >>>>>it is easy to store a chain of well thought out short
function
> >>>>>names as used by C(as I write
> >>>>>it) and asm
> >>>>>
> >>>>>Al
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>.
> >>>>>
> >>>>>
> >>>>>Yahoo! Groups Links
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>---
> >>>>>avast! Antivirus: Inbound message clean.
> >>>>>Virus Database (VPS): 0533-3, 08/17/2005
> >>>>>Tested on: 8/17/2005 10:42:36 PM
> >>>>>avast! - copyright (c) 1988-2005 ALWIL Software.
> >>>>>http://www.avast.com
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>.
> >>>>
> >>>>
> >>>>Yahoo! Groups Links
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>.
> >>>
> >>>
> >>>Yahoo! Groups Links
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>---
> >>>avast! Antivirus: Inbound message clean.
> >>>Virus Database (VPS): 0533-3, 08/17/2005
> >>>Tested on: 8/18/2005 8:49:30 AM
> >>>avast! - copyright (c) 1988-2005 ALWIL Software.
> >>>http://www.avast.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>.
> >>>
> >>>
> >>>Yahoo! Groups Links
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >> Matthias
> >>
> >>
> >>
> >>.
> >>
> >>
> >>Yahoo! Groups Links
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >.
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
Matthias
Reply by Onestone●August 18, 20052005-08-18
mATTHIAS, HOPEFULLY THIS ISN'T A WAR. I'm just trying to explain
to Alex
why I personally prefer asm. I don't give a rats ass what anyone else
uses. it's their choice.
I haven't got Rolfs original yet, but, Rolf, this is a mantra. It is
more based on religious belief than fact.
The rationale for this is quite simple. Embedded systems are NOt like
PC's (obvious) where you can make full use of the many complex functions
and instructions in the C language. However most of the things you do on
a micro don't really fit the C model. There aren't many standard C
functions that relate to everyday embedded design. You can't take
(x)printf(0 and its many similar functions and use it straight out of
the box. you actually have to write the procedures for the display
device you're using.
You can't use inp(), or input(0, or gets() or getchar() without first
defining code that processes them. In fact about the only things that
work straight out of the box are control structures like for() and
while, and switch., and maths functions. Any of these are as easy to
implement in asm as they are in C, and often easier.
You initalise the system in a similar, but less clear manner than I
would in asm. You write ISR's in a less clear, and more cumbersome
manner than I would in asm. You have no inherent bit handling and no
direct control of register allocation. Have a look at a large program,
then tell me how many complex standard C functions do you use without
having to write them first?
Al
augusto einsfeldt wrote:
>One of best things about this list is the mix of
deep technical insights
>with amusement...
>
>-Augusto
>
>
>-----Original Message-----
>From: msp430@msp4... [mailto:msp430@msp4...] On Behalf Of
>rolf.freitag@rolf...
>Sent: Thursday, August 18, 2005 11:26 AM
>To: msp430@msp4...
>Subject: Re: [msp430] Re: Interrupt occurs in ISR A
>
>
>
>Hi,
>
>the main reason for using high level languages instead of ASM is that
>ASM is inefficient; you need more time to code (and debug)in ASM.
>See the old "The Mythical Man-Month".
>
>Regards,
>
>Rolf
>
>
>msp430@msp4... schrieb am 18.08.05 15:51:03:
>
>
>>Alex, right. ASM coders are usually very diligent people, or people
>>that go through the C-generated code with a fine-tooth comb. The C
>>coders are more from the lazy fraction of mankind and can live with
>>some suboptimal but working solutions :-). And do not forget the code
>>reusability. ASM code has to be rewritten from one to another platform
>>- well it is mostly simple - but costs time and introduce new
>>failures.
>>
>>Oh well, I should close my mouth. I sweared not to fan the fire of the
>>ASM vs. C flame war...
>>
>>M.
>>
>>On Thu, Aug 18, 2005 at 08:58:11AM -0400, alex@alex... wrote:
>>
>>
>>>Yes Al, but like the baker that can't smell his own bread, you
are
>>>not observing how much more work you do in ASM. High Level Languages
>>>are doing all that time consuming management work for you :)
>>>
>>>I am not trying you convert you Al :)
>>>
>>>Alex
>>>
>>>
>>>----- Original Message -----
>>>From: "Onestone" <onestone@ones...>
>>>To: <msp430@msp4...>
>>>Sent: Thursday, August 18, 2005 12:28 AM
>>>Subject: Re: [msp430] Re: Interrupt occurs in ISR A
>>>
>>>
>>>FORTH uses an entirely different structure and notation to either
>>>asm or C.
>>>
>>>I don't use macros either, if you've watched my posts at
all you'll
>>>find that I rarely if ever use them. That isn't to say that use
of
>>>macros isn't use of assembler, most modern assemblers are
called
>>>MACRO ASSEMBLERS.
>>>
>>>Firstly this is asm, I don't need to declare anything in the
formal
>>>manner required by C. For structures that need to be initialised I
>>>can either do what you might do in C, run a function that calculates
>>>their values, and intialises them, or initalise them from a table in
>>>FLASH. This assumes that they are volatile of course. Otherwise I
>>>just initlaise them in a flash table.To allocate the structure I can
>>>simply allocate the memory, naming the flelds in my allocation, then
>>>further reserving enough memory to allow the maximum number of
>>>structures. In fact I can do better. I can allocate N structures of
>>>M bytes, and, if this overflows memory I can easily arrange to
>>>temporarily store some of the tables in my flash data base. C
can't
>>>do that without a lot of work. Rather than waste memory I can re-use
>>>the same block of memory over and over again, with different local
>>>structures if I need them. But the tendency in asm is probably to
>>>not use this method as much as you might in C, but to micromanage
>>>memory a bit better by using alternative methods.
>>>
>>>as to memory allocation, well this is THE most asked question by C
>>>programmers in this, and other forums. "How do I fix the
address of
>>>a variable", or "How to I reserve a register". The
answer to the
>>>first seems to vary a little between compilers, the answer in asm is
>>>simply by using EQU or DS when naming the variable, the answer in C
>>>to the secodn is that usually you can't, unless the compiler
vendor
>>>allows you 1 or 2 registers, while in asm I have total control of my
>>>register allocation.
>>>
>>>If I wanted to, in asm I could do... MOV R4,&0213H.
>>>
>>>Of course this is fraught with danger, since there is no indication
>>>to me whether or not the target RAM address is really in RAM for
>>>this micro, is meant to be a word (of course not, since these are
>>>even boundaries), so I couldn't readily spot the fact that it
should
>>>be a MOV.B. It will assemble fine, and run, but not the way you
>>>might expect it to. Notice the total lack of a declaration.
>>>
>>>I could also use:-
>>>
>>>THISVAR EQU 0213H
>>>
>>>But again when I see
>>>
>>> MOV R4,&THISVAR
>>>
>>>There's nothing to tell me it should be a byte access.
>>>
>>>Then I could use the form:-
>>>
>>> ORG RAMSTART
>>>
>>>HEAP DS 512 ;RESERVE
512
>>>BYTES FOR LOCAL STRUCTURES
>>>THISVAR DS 2 ;RESERVE 2
BYTES
>>>FOR ANY OLD VARIABLE
>>>
>>>Now I have explicitly defined THISVAR as using 2 bytes, and my MOV
>>>will be correct, because the RAM allocation occurs at an even
>>>address.
>>>
>>>Now I CAN access it as either a pair of bytes, or a word, but
it's
>>>default is word. again this is something easier to do in asm than C.
>>>I have absolute control in asm of ALL my memory. the downside is
>>>that I have to be aware of this when programming, and make sure I do
>>>control it. In C you don't need to worry about this, it's
taken care
>>>of for you, at the cost of a little flexibility.
>>>
>>>Now asm by its very nature tends to be global. You can use local and
>>>extern, public, etc but that is an individual choice. I simply
don't
>>>like constraints that I don't impose myself.
>>>
>>>Al
>>>
>>>alex@alex... wrote:
>>>
>>>
>>>
>>>>Al,
>>>>How do you declare, initialize and mange a structure in ASM. Or
>>>>Memory allocation? If R going to mention MACROS, then you are
not
>>>>using ASM anymore :) ASM is like Latin. It's good in
it's own
>>>>Church and for it's own followers
>>>>:)
>>>>Alex
>>>>
>>>>BTW.
>>>>One can find a neutral ground between ASM and any other high
level
>>>>language by simply using FORTH :) A
>>>>
>>>>----- Original Message -----
>>>>From: "Onestone" <onestone@ones...>
>>>>To: <msp430@msp4...>
>>>>Sent: Wednesday, August 17, 2005 9:38 PM
>>>>Subject: Re: [msp430] Re: Interrupt occurs in ISR A
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hi again, just one last thing before I let this thread go
for good
>>>>>
>>>>>Clifford Heath wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Of course, but a good global optimiser will produce
excellent
>>>>>>code in
>>>>>>
>>>>>>almost any case. And that's the point - you're
free to express
>>>>>>yourself in code (i.e., write your program for
*humans*), but you
>>>>>>get a result that's good for the *machine* anyway.
There's a
>>>>>>tradeoff, though not a big one, nevertheless how you
lean depends
>>>>>>on whether you have a greater need to pander to people
or to the
>>>>>>machine. When you're working in a team of ten or
twenty, on 2
>>>>>>million lines of code (as I am), the people issues
>>>>>>matter a *lot*.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>This is one thing I've never really understood. The
assumption
>>>>>that C is more user friendly, and easier to read than asm. I
don't
>>>>>get it.
>>>>>
>>>>> MOV, ADD, SUB, RRC, RLA, MAC, MPY, DIV, BIC, BIS, BSET,
DECSZ
>>>>>etc are all very common abbreviations across a wide range of
>>>>>microprocessors and controllers, and are easily understood.
at
>>>>>least as easily as LTOA, ? /R, /N, ^=, &, &&,
FLOOR, PRAGMA,
>>>>>MALLOC, CALLOC, * (*) AND ALL ITS VARIATIONS.
>>>>>
>>>>>Both are equally crytpic, and both are easily
understandable. C
>>>>>contains far more nonalphanumeric symbols, which complicates
>>>>>things, but the consequences and actions of any
'instruction' are
>>>>>more 'wdiespread, it does more, which can be both a
blessing and a
>>>>>hindrance.
>>>>>
>>>>>asm uses few symbols, few instructions and each instruction
does
>>>>>just one clearly defined thing, with possible actiosn
associated
>>>>>with it such as flag setting. It is therefore less to learn,
>>>>>easier to grasp, but requires more instructions per high
level
>>>>>task usually..
>>>>>
>>>>>I don't see that one is more easily read by humans than
the other
>>>>>though. Either can be made illegible, and either can be made
>>>>>readable. being more voluble isn't necessary being more
readable.
>>>>>I cannot remember the long convolluted names so beloved of
C++
>>>>>pogrammers for example, which makes debugging much harder,
whereas
>>>>>it is easy to store a chain of well thought out short
function
>>>>>names as used by C(as I write
>>>>>it) and asm
>>>>>
>>>>>Al
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>.
>>>>>
>>>>>
>>>>>Yahoo! Groups Links
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>---
>>>>>avast! Antivirus: Inbound message clean.
>>>>>Virus Database (VPS): 0533-3, 08/17/2005
>>>>>Tested on: 8/17/2005 10:42:36 PM
>>>>>avast! - copyright (c) 1988-2005 ALWIL Software.
>>>>>http://www.avast.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>.
>>>>
>>>>
>>>>Yahoo! Groups Links
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>.
>>>
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>---
>>>avast! Antivirus: Inbound message clean.
>>>Virus Database (VPS): 0533-3, 08/17/2005
>>>Tested on: 8/18/2005 8:49:30 AM
>>>avast! - copyright (c) 1988-2005 ALWIL Software.
>>>http://www.avast.com
>>>
>>>
>>>
>>>
>>>
>>>
>>>.
>>>
>>>
>>>Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>> Matthias
>>
>>
>>
>>.
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
>
>.
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
Reply by augusto einsfeldt●August 18, 20052005-08-18
One of best things about this list is the mix of deep technical insights
with amusement...
-Augusto
-----Original Message-----
From: msp430@msp4... [mailto:msp430@msp4...] On Behalf Of
rolf.freitag@rolf...
Sent: Thursday, August 18, 2005 11:26 AM
To: msp430@msp4...
Subject: Re: [msp430] Re: Interrupt occurs in ISR A
Hi,
the main reason for using high level languages instead of ASM is that
ASM is inefficient; you need more time to code (and debug)in ASM.
See the old "The Mythical Man-Month".
Regards,
Rolf
msp430@msp4... schrieb am 18.08.05 15:51:03:
>
> Alex, right. ASM coders are usually very diligent people, or people
> that go through the C-generated code with a fine-tooth comb. The C
> coders are more from the lazy fraction of mankind and can live with
> some suboptimal but working solutions :-). And do not forget the code
> reusability. ASM code has to be rewritten from one to another platform
> - well it is mostly simple - but costs time and introduce new
> failures.
>
> Oh well, I should close my mouth. I sweared not to fan the fire of the
> ASM vs. C flame war...
>
> M.
>
> On Thu, Aug 18, 2005 at 08:58:11AM -0400, alex@alex... wrote:
> > Yes Al, but like the baker that can't smell his own bread, you
are
> > not observing how much more work you do in ASM. High Level Languages
> > are doing all that time consuming management work for you :)
> >
> > I am not trying you convert you Al :)
> >
> > Alex
> >
> >
> > ----- Original Message -----
> > From: "Onestone" <onestone@ones...>
> > To: <msp430@msp4...>
> > Sent: Thursday, August 18, 2005 12:28 AM
> > Subject: Re: [msp430] Re: Interrupt occurs in ISR A
> >
> >
> > FORTH uses an entirely different structure and notation to either
> > asm or C.
> >
> > I don't use macros either, if you've watched my posts at all
you'll
> > find that I rarely if ever use them. That isn't to say that use
of
> > macros isn't use of assembler, most modern assemblers are called
> > MACRO ASSEMBLERS.
> >
> > Firstly this is asm, I don't need to declare anything in the
formal
> > manner required by C. For structures that need to be initialised I
> > can either do what you might do in C, run a function that calculates
> > their values, and intialises them, or initalise them from a table in
> > FLASH. This assumes that they are volatile of course. Otherwise I
> > just initlaise them in a flash table.To allocate the structure I can
> > simply allocate the memory, naming the flelds in my allocation, then
> > further reserving enough memory to allow the maximum number of
> > structures. In fact I can do better. I can allocate N structures of
> > M bytes, and, if this overflows memory I can easily arrange to
> > temporarily store some of the tables in my flash data base. C
can't
> > do that without a lot of work. Rather than waste memory I can re-use
> > the same block of memory over and over again, with different local
> > structures if I need them. But the tendency in asm is probably to
> > not use this method as much as you might in C, but to micromanage
> > memory a bit better by using alternative methods.
> >
> > as to memory allocation, well this is THE most asked question by C
> > programmers in this, and other forums. "How do I fix the address
of
> > a variable", or "How to I reserve a register". The
answer to the
> > first seems to vary a little between compilers, the answer in asm is
> > simply by using EQU or DS when naming the variable, the answer in C
> > to the secodn is that usually you can't, unless the compiler
vendor
> > allows you 1 or 2 registers, while in asm I have total control of my
> > register allocation.
> >
> > If I wanted to, in asm I could do... MOV R4,&0213H.
> >
> > Of course this is fraught with danger, since there is no indication
> > to me whether or not the target RAM address is really in RAM for
> > this micro, is meant to be a word (of course not, since these are
> > even boundaries), so I couldn't readily spot the fact that it
should
> > be a MOV.B. It will assemble fine, and run, but not the way you
> > might expect it to. Notice the total lack of a declaration.
> >
> > I could also use:-
> >
> > THISVAR EQU 0213H
> >
> > But again when I see
> >
> > MOV R4,&THISVAR
> >
> > There's nothing to tell me it should be a byte access.
> >
> > Then I could use the form:-
> >
> > ORG RAMSTART
> >
> > HEAP DS 512 ;RESERVE 512
> > BYTES FOR LOCAL STRUCTURES
> > THISVAR DS 2 ;RESERVE 2
BYTES
> > FOR ANY OLD VARIABLE
> >
> > Now I have explicitly defined THISVAR as using 2 bytes, and my MOV
> > will be correct, because the RAM allocation occurs at an even
> > address.
> >
> > Now I CAN access it as either a pair of bytes, or a word, but
it's
> > default is word. again this is something easier to do in asm than C.
> > I have absolute control in asm of ALL my memory. the downside is
> > that I have to be aware of this when programming, and make sure I do
> > control it. In C you don't need to worry about this, it's
taken care
> > of for you, at the cost of a little flexibility.
> >
> > Now asm by its very nature tends to be global. You can use local and
> > extern, public, etc but that is an individual choice. I simply
don't
> > like constraints that I don't impose myself.
> >
> > Al
> >
> > alex@alex... wrote:
> >
> > >Al,
> > >How do you declare, initialize and mange a structure in ASM. Or
> > >Memory allocation? If R going to mention MACROS, then you are not
> > >using ASM anymore :) ASM is like Latin. It's good in
it's own
> > >Church and for it's own followers
> > >:)
> > >Alex
> > >
> > >BTW.
> > >One can find a neutral ground between ASM and any other high level
> > >language by simply using FORTH :) A
> > >
> > >----- Original Message -----
> > >From: "Onestone" <onestone@ones...>
> > >To: <msp430@msp4...>
> > >Sent: Wednesday, August 17, 2005 9:38 PM
> > >Subject: Re: [msp430] Re: Interrupt occurs in ISR A
> > >
> > >
> > >
> > >
> > >>Hi again, just one last thing before I let this thread go for
good
> > >>
> > >>Clifford Heath wrote:
> > >>
> > >>
> > >>
> > >>>Of course, but a good global optimiser will produce
excellent
> > >>>code in
> > >>>
> > >>>almost any case. And that's the point - you're
free to express
> > >>>yourself in code (i.e., write your program for *humans*),
but you
> > >>>get a result that's good for the *machine* anyway.
There's a
> > >>>tradeoff, though not a big one, nevertheless how you lean
depends
> > >>>on whether you have a greater need to pander to people or
to the
> > >>>machine. When you're working in a team of ten or
twenty, on 2
> > >>>million lines of code (as I am), the people issues
> > >>>matter a *lot*.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>This is one thing I've never really understood. The
assumption
> > >>that C is more user friendly, and easier to read than asm. I
don't
> > >>get it.
> > >>
> > >> MOV, ADD, SUB, RRC, RLA, MAC, MPY, DIV, BIC, BIS, BSET,
DECSZ
> > >>etc are all very common abbreviations across a wide range of
> > >>microprocessors and controllers, and are easily understood. at
> > >>least as easily as LTOA, ? /R, /N, ^=, &, &&,
FLOOR, PRAGMA,
> > >>MALLOC, CALLOC, * (*) AND ALL ITS VARIATIONS.
> > >>
> > >>Both are equally crytpic, and both are easily understandable.
C
> > >>contains far more nonalphanumeric symbols, which complicates
> > >>things, but the consequences and actions of any
'instruction' are
> > >>more 'wdiespread, it does more, which can be both a
blessing and a
> > >>hindrance.
> > >>
> > >>asm uses few symbols, few instructions and each instruction
does
> > >>just one clearly defined thing, with possible actiosn
associated
> > >>with it such as flag setting. It is therefore less to learn,
> > >>easier to grasp, but requires more instructions per high level
> > >>task usually..
> > >>
> > >>I don't see that one is more easily read by humans than
the other
> > >>though. Either can be made illegible, and either can be made
> > >>readable. being more voluble isn't necessary being more
readable.
> > >>I cannot remember the long convolluted names so beloved of
C++
> > >>pogrammers for example, which makes debugging much harder,
whereas
> > >>it is easy to store a chain of well thought out short function
> > >>names as used by C(as I write
> > >>it) and asm
> > >>
> > >>Al
> > >>
> > >>
> > >>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >>.
> > >>
> > >>
> > >>Yahoo! Groups Links
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>---
> > >>avast! Antivirus: Inbound message clean.
> > >>Virus Database (VPS): 0533-3, 08/17/2005
> > >>Tested on: 8/17/2005 10:42:36 PM
> > >>avast! - copyright (c) 1988-2005 ALWIL Software.
> > >>http://www.avast.com
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> > >.
> > >
> > >
> > >Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> > .
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ---
> > avast! Antivirus: Inbound message clean.
> > Virus Database (VPS): 0533-3, 08/17/2005
> > Tested on: 8/18/2005 8:49:30 AM
> > avast! - copyright (c) 1988-2005 ALWIL Software.
> > http://www.avast.com
> >
> >
> >
> >
> >
> >
> > .
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> Matthias
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
.
Yahoo! Groups Links
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.12/75 - Release Date: 17/8/2005
