Searching \ for '[EE]: C vs ASM' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/language/index.htm?key=asm
Search entire site for: 'C vs ASM'.

Exact match. Not showing close matches.
PICList Thread
'[EE]: C vs ASM'
2002\10\14@144618 by Andre Abelian

picon face
Hi to all,

Sorry if the tag isn't right.
I always use assembly and I noticed that
I am not moving fast enough it takes months to get it
done. I think it is time to start thinking in C. I was wondering
How many engineers in this list use C. Is
There any engineer that knows asm and C but
Still uses asm? If yes why?

Andre

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\10\14@155939 by Matt Heck

flavicon
face
Hi Andre,

First off-- whichever you use, your tools MUST BE ROBUST.  A bad
assembler is bad enough, but a flakey C compiler can take MONTHS
to code around.  Compare notes with other people working on the
same processor as you, and get one that people trust.  This is
worth mentioning, because one bad experience with an embedded C
compiler can turn you off to the language for years, and it really
shouldn't.  Anyway...

As a programmer who works on both microcontrollers and PC software
systems, let me try to explain the strengths and weaknesses of each
approach.  Keep in mind that most high-level language compilers
will let you embed, or at least link with, assembly language
routines where you need them.

ASSEMBLY
pros:
  - potential for absolute maximum speed (if the designer really
    knows the hardware)
  - best choice for functions which require exact cycle-counted
    timing
  - can allow a program to fit in a smaller device than a high-
    level language might require (reduces product cost)
  - tends to ensure programmers are familiar with any quirks of
    the processor in use
  - good for things that need to be very tightly packed, and that
    are device-specific anyway (for example, bootloaders and
    integrity checks)
  - may be portable within different processors in the same
    family (but this is not always guarranteed)
  - easy to lock down a block of code to a particular section of
    the device
  - you always know (or at least CAN know) exactly what the chip
    is doing at any given point
cons:
  - generally takes longer to develop applications in
  - generally harder to debug    - short syntax and large number of source bytes per instruction
    statistically increase typos and paramater transposition
  - requires a detailed knowledge of the device's instruction set
    and execution timing
  - does not port between differrent architectures easily (for
    example, migrating 8051 assembly code to a PIC18F part will
    basically require rewriting the program)
  - very cryptic unless careful documentation is kept (hard to
    maintain)
  - smaller market supply of suitable programmers for any one
    particular device (higher development and maintenance costs)
  - assembler (generally, changes to macros) or linker updates can
    break code
  - very poorly suited to developing floating-point functions,
    especially untested ones


HIGH-LEVEL LANGUAGE (C, C++, ML, Modula, etc.)
pros:
  - portable between processors with similar capabilities, even
    if they have dissimilar designs (RISC vs. CISC, for example)
  - designer does not need intimate knowledge of the processor's
    instruction set (though it's still a good idea)
  - faster to prototype in than assembly
  - allows an object-oriented approach (can make some complicated
    designs simpler to maintain and document)
  - can be somewhat self-documenting (especially C++)
  - easier to maintain in general
  - much easier to develop, test, and maintain floating-point math
  - much easier to locate suitable developers to maintain project
    (reduces development and maintenance costs)

cons:
  - exact size and execution time of a block of code is not readily
    apparrent from the source, and will depend on the compiler, chip,
    and compiler settings
  - generally need to allocate about 50% to 2X more ROM and RAM than
    the project would take in assembly (not all of it may be used;
    some of it is just so the compiler can do things the way it likes)
  - minor modifications in source may radically change the output
    instruction code (though it should execute "about the same")
  - switching or upgrading compilers mid-stream may move things
    around in memory or flat-out break things
  - assembler bugs can make you scream, but compiler bugs can make
    you commit a felony (ask about your compiler before you buy it!)
  - you get this nagging feeling sometimes, especially during
    debugging, that something is going on in hardware that you don't
    know about (because it is, and you don't-- it's just usually not
    that important =] )

So, my suggestions for any given platform are:
1. Get familiar with an assembler.
2. Get familiar with a C compiler.
3. Learn how to call routines in one from the other (assembly from C
  being the major case).
4. Learn how to make your C compiler generate ASSEMBLY OUTPUT in case
  you have to do that to use a hardware debugger.
5. If a profiler is available for your platform, learn how to use it.
6. NEVER upgrade or switch tools near a demo or ship date.
7. NEVER switch from assembly to C or vice-versa unless your timeline
  allows you to do so, or you are SURE that the switch will save more
  development time than the port will require.
8. If your chip will be turning on other devices (external DACs, etc.),
  then there are some good reasons why your power-on code should be
  written in assembly-- most of them are tight timing issues.

My bottom line, if I have to have one, is probably this:

IN GENERAL, if you have a compiler you trust, start in C, get it working
as well as you can, then profile the system and optimize the pieces that
aren't fast enough, or need to be timed carefully, in assembly.

Does that help?

Cheers,
  Matt Heck
  Crystal Engineering Corporation

> {Original Message removed}

2002\10\14@163615 by Walter Banks

picon face
Matt Heck wrote:

> HIGH-LEVEL LANGUAGE (C, C++, ML, Modula, etc.)
> cons:
>    - generally need to allocate about 50% to 2X more ROM and RAM than
>      the project would take in assembly (not all of it may be used;
>      some of it is just so the compiler can do things the way it likes)
>

This popular myth is no longer  true with current good commercial compilers.

C programs that are well written that regularily will beat hand written
assembler
in RAM usage and should be very competative in ROM usage. With a PIC
compiler ROM within 5% or so.

W..

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\10\14@164424 by Russell McMahon

face
flavicon
face
> How many engineers in this list use C. Is
> There any engineer that knows asm and C but
> Still uses asm? If yes why?

You MUST read the archives before asking those questions :-) !!!
This is one of the threads that gets repeated over and over and over again
over the years.
We have just finished one such in the last few weeks.

Maybe we want a mutually agreed on version of the following in a FAQ.
Better still, a list of YOU MUST READ questions in the archive. Anyone
asking a question covered in the YMR question list is banished to the
reading room until they have read it :-)

_________________

The answers you get after days or weeks of discussion go like -

C (and any HLL) is a power-tool used to do things faster. Assembler is a
tradesman's hand tool capable of finer detail and more control but harder to
use and slower in the hands of all but the most skilled. A novice can find
the job uncompleteable with the hand tool but can also make an awful mess
with the power-tool. There is a place in most people's toolboxes for both.
(metaphor courtesy of Ken Mardle).

Many here use C.
Many know both.
Almost all who use C also use assembler sometimes.
Some who know C use assembler most of the time.

C is faster to get results with for most people. When mixed with assembler
you get results which are good enough for most purposes. A few experts claim
they are as quick or quicker with assembler as with C (and it may be true)
and that everyone else can be as well (which isn't true) and that everyone
should learn to use only assembler (which isn't true).

C is usually slightly less efficient in code space than a good assembler
program. In some cases a good assembler program will be MUCH smaller and or
faster than a good C program. A good C program may be faster and or smaller
than a badly written assembler program.

C is easy to make mistakes in.
Assembler is even easier :-)

How good the C's optimising abilities are is a critical factor. Generally
but not always, the dearer the C the better it is at making small fast code.
Grown men will kill each other over this statement.

It is a really really really good idea to be able to use assembler even if
you mostly use C as you can leap into assembler when really really
necessary, and sometimes it is. Also, all C's will SOMETIMES not do what you
expect or want and being able to look at the assembler code they (should)
produce and understand what it is (or isn't) doing is a big bonus. Some
would say it is essential. When a compiler goes wrong you are completely
stuck if you can't work out why it does what it does. No amount of insisting
that it SHOULD do what they say it should do will save the project that it
fails to work on. With assembler its usually your fault :-). (Sometimes its
the processor's fault but that's not a language issue per se).

You will find many people to disagree with, and slightly fewer people to
agree with each of the above thoughts.



       Russell McMahon

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\10\14@165243 by Wouter van Ooijen

face picon face
> There any engineer that knows asm and C but
> Still uses asm? If yes why?

(from 'start with PICs'):

The last issue (effective use of resources) can start a flame war on its
own: the famous C-versus-assembler war (for C you can substitute your
own favorite language). As often in such a case the answer depends a lot
on the application. My opinion is:

- An assembler programmer can, given sufficient time, always make his
program smaller, faster, etc. than a programmer that uses C or another
high level language.

- Given insufficiently time the reverse is true. (If you are a
professional programmer: What was the last time you were given enough
time to write an application? If so you are probably in an industry
where the size of a production run is measured in the thousands, if not
more.)

My conclusion is be that for large series assembler should be used and
for small series a high level language, but that leaves the question
open how large or small the series must be, and it leaves a large gray
area. A good middle road is often to use a high level language for most
of your code and inline assembly for the parts that are very
timing-critical.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\10\14@173105 by mike

flavicon
face
On Mon, 14 Oct 2002 11:45:34 -0700, you wrote:

>Hi to all,
>
>Sorry if the tag isn't right.
>I always use assembly and I noticed that
>I am not moving fast enough it takes months to get it
>done. I think it is time to start thinking in C. I was wondering
>How many engineers in this list use C. Is
>There any engineer that knows asm and C but
>Still uses asm? If yes why?
>
>Andre
I use both, depending on the nature of the project.
Small, bit-twiddly stuff is way easier in assembler, stuff with maths
or complicated flow-control is easier in C.

There is no 'right' answer.

Whatever language you use, time spent in careful design of how the
software will work will save itself many many times over.
.
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\10\14@174312 by Wagner Lipnharski

flavicon
face
Wouter van Ooijen wrote:
>> There any engineer that knows asm and C but
>> Still uses asm? If yes why?

Ze gud vorker vil vork vit zame performance vit ze hamar or ze nife.
Assembly or C iz a kuestion of chooz ze rit tool for ze target jab.
Ze gud programar wil do it aiter vay, vitout ani difikult.
I vil rekomend assembly onli if you know the procesor gutz veri vell.
Az iu kan zee, I'm on ze vay to ze nu european talkin.
prity eze hu?

Still being a non sense after so much talking about C vs ASM, we will see
it over and over, since new users will confront it day after day.  As you
can see, if the doubt always exist, it is because a serious fight still
burning.

VV46NER

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\10\14@174934 by Olin Lathrop

face picon face
> I always use assembly and I noticed that
> I am not moving fast enough it takes months to get it
> done. I think it is time to start thinking in C. I was wondering
> How many engineers in this list use C. Is
> There any engineer that knows asm and C but
> Still uses asm? If yes why?

This has been beat to death several times already, so let's not waste
bandwidth on it again.  Check the archives.  You will find 15 opinions for
every 10 messages on the subject.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\10\14@175144 by mike

flavicon
face
On Mon, 14 Oct 2002 12:59:09 -0700, you wrote:

>Hi Andre,
>
>First off-- whichever you use, your tools MUST BE ROBUST.  A bad
>assembler is bad enough, but a flakey C compiler can take MONTHS
>to code around.  Compare notes with other people working on the
>same processor as you, and get one that people trust.  This is
>worth mentioning, because one bad experience with an embedded C
>compiler can turn you off to the language for years, and it really
>shouldn't.  Anyway...
Totally agree - the Hitech PIC C, although not brilliantly
code-efficient always produces solid code in my experience.
>As a programmer who works on both microcontrollers and PC software
>systems, let me try to explain the strengths and weaknesses of each
>approach.  Keep in mind that most high-level language compilers
>will let you embed, or at least link with, assembly language
>routines where you need them.
>
>ASSEMBLY
>pros:
>   - potential for absolute maximum speed (if the designer really
>     knows the hardware)
..and absolutely PREDICTABLE timing

>cons:
>   - generally takes longer to develop applications in
ALthough for smaller I/O intensive stuff, the differemce is marginal.


>   - very cryptic unless careful documentation is kept (hard to
>     maintain)
The same can often be said of C - In my experience, C and ASM are
equally prone to bad commenting. Especially as on microcontrollers you
often need to write C in less than ideal ways to get efficiency.
>   - smaller market supply of suitable programmers for any one
>     particular device (higher development and maintenance costs)
I'd disagree here. I would think that nn experienced assembler
programmer can learn a new chip much faster than they can learn the
quirks needed to get a  new embedded C compiler to generate efficient
code. Experience of C on bigger systems is of limited use for low to
medium-end microcontroller work.
>   - assembler (generally, changes to macros) or linker updates can
>     break code
No more so than C compiler updates. Assemblers are MUCH simpler
animals than compilers, and so lees prone to updates and bugs, and
what bugs there may be can be easily spotted and worked around.

>   - very poorly suited to developing floating-point functions,
>     especially untested ones
Agreed, but how many embedded applications access real-world data that
has enough range to require floating point ?
>
>HIGH-LEVEL LANGUAGE (C, C++, ML, Modula, etc.)
>pros:
>   - portable between processors with similar capabilities, even
>     if they have dissimilar designs (RISC vs. CISC, for example)
>   - designer does not need intimate knowledge of the processor's
>     instruction set (though it's still a good idea)
Not often an issue with small-to-medium embedded systems.

>   - allows an object-oriented approach (can make some complicated
>     designs simpler to maintain and document)
Yeah, Right - how many PICs have enough resources to spare for this ?
>   - can be somewhat self-documenting (especially C++)
..or equally, if not more, obscure...!
>   - easier to maintain in general
Probably depends more on the quality of design and documentation than
language

>   - much easier to locate suitable developers to maintain project
>     (reduces development and maintenance costs)
Again, I'd disagree - I'd MUCH rather learn a new assembler than the
quirks of a new C compiler - been there, don't want to do it again!

>cons:
>   - exact size and execution time of a block of code is not readily
>     apparrent from the source, and will depend on the compiler, chip,
>     and compiler settings
..order of operations, phase of moon....:-)
>   - generally need to allocate about 50% to 2X more ROM and RAM than
>     the project would take in assembly (not all of it may be used;
>     some of it is just so the compiler can do things the way it likes)
..although compilers can be good at making good use of local
variables, but they usually burn some or all of this advantage in
other inefficiencies.
>   - minor modifications in source may radically change the output
>     instruction code (though it should execute "about the same")
>   - switching or upgrading compilers mid-stream may move things
>     around in memory or flat-out break things
>   - assembler bugs can make you scream, but compiler bugs can make
>     you commit a felony (ask about your compiler before you buy it!)
>   - you get this nagging feeling sometimes, especially during
>     debugging, that something is going on in hardware that you don't
>     know about (because it is, and you don't-- it's just usually not
>     that important =] )
..Compilers are usually a lot more expensive, especially if you need
to support a range of processors.
This can be a major issue for long-term maintainability - e.g. your
5-year old project needs an update and the compiler's parallel dongle
doesn't work on any of your new wizzo PCs.
>
>So, my suggestions for any given platform are:
>1. Get familiar with an assembler.
>2. Get familiar with a C compiler.
>3. Learn how to call routines in one from the other (assembly from C
>   being the major case).
How I'd love to easily be able to do the opposite - an assembler
program with odd bits of C....
>4. Learn how to make your C compiler generate ASSEMBLY OUTPUT in case
>   you have to do that to use a hardware debugger.
..and so you can see if it is doing stupid or inefficient things that
could be corrected by rearranging the code.  
>5. If a profiler is available for your platform, learn how to use it.
>6. NEVER upgrade or switch tools near a demo or ship date.
>7. NEVER switch from assembly to C or vice-versa unless your timeline
>   allows you to do so, or you are SURE that the switch will save more
>   development time than the port will require.
I'd say a reasonable approach would be to start in C, and then move
critical parts to assembly modules as space or speed constraints
become aparrent.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\10\14@175428 by mike

flavicon
face
On Mon, 14 Oct 2002 16:42:27 -0400, you wrote:

>Matt Heck wrote:
>
>> HIGH-LEVEL LANGUAGE (C, C++, ML, Modula, etc.)
>> cons:
>>    - generally need to allocate about 50% to 2X more ROM and RAM than
>>      the project would take in assembly (not all of it may be used;
>>      some of it is just so the compiler can do things the way it likes)
>>
>
>This popular myth is no longer  true with current good commercial compilers.
>
>C programs that are well written that regularily will beat hand written
>assembler
>in RAM usage and should be very competative in ROM usage. With a PIC
>compiler ROM within 5% or so.
>
>W..
Which compiler would that be then...?

My observations on the compilers I've used is that the  embedded C
market is not big enough to justify the development effort of building
and testing highly efficient compilers. Add to this the fact that C
has some inherent inefficiencies which will be there no matter how
good the compiler is, and I'd be surprised that the code overhead
would typically be anything like as low as that. Sure, compilers can be better at managing variable usage, but this can
be lost in other areas.

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\10\14@195925 by Dale Botkin

flavicon
face
On Mon, 14 Oct 2002, Andre Abelian wrote:

> There any engineer that knows asm and C but
> Still uses asm? If yes why?

I know both and use C...  because for *me* it works better. *I* can write
better code, much faster, and modify and maintain it much better, in C.
That may or may not hold true for you (but probably will).

Dale

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\10\14@201540 by Matt Heck

flavicon
face
My opinion on this issue is definitely more from PC experience than
microcontrollers, and a PIC is DEFINITELY a hell of a lot easier to
optimize for than a Pentium III, so Walter may be quite correct here.

It would be interesting to get some data on this.

Beware, however, that some compilers can get more "creative" than
you might initially like at dealing with low RAM situations-- for
example, using overlaid variables, if it's safe to do so.  Safe for
the program it may be-- sane for the programmer while debugging, it
often is not.  For this reason, I suggest you avoid getting in a
situation where you HAVE to use the optimizing options on your
compiler to make the code fit on the chip at all.

And Walter is right about one thing, either way-- my attitude about
compiler performance is largely an artifact of old grudges against
old compilers.  But you can still wind up having a lot more of the
Standard C Run-Time Library linked into your stuff than you would
expect, if you don't watch out for it.  And Windows programming--
well, no need to go there. =]

Cheers,
 Matt

> {Original Message removed}

2002\10\14@201551 by Shawn Mulligan

picon face
On Mon, 14 Oct 2002, Dale Botkin wrote:
>
>I know both and use C...  because for *me* it works better. *I* can write
>better code, much faster, and modify and maintain it much better, in C.
>That may or may not hold true for you (but probably will).

I agree with Dale, and would add that a knowledge of Assembly makes for a
better C programmer.  Shawn

_________________________________________________________________
Join the world s largest e-mail service with MSN Hotmail.
http://www.hotmail.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\10\14@201749 by William Chops Westfield

face picon face
One remaining reason to use ASM is that you can publish a "hobbyist" style
project, including source code, without requiring that everyone who wants to
make some minor modification shell out $$$ for a compatible C compiler.  (For
all the better compatibility of C, that doesn't mean that your software
written for a professional C compiler will work without significant
modification using some freeware C compiler (and still fit in the chip...)

BillW

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\10\14@202648 by Dale Botkin

flavicon
face
On Mon, 14 Oct 2002, Shawn Mulligan wrote:

> On Mon, 14 Oct 2002, Dale Botkin wrote:
> >
> >I know both and use C...  because for *me* it works better. *I* can write
> >better code, much faster, and modify and maintain it much better, in C.
> >That may or may not hold true for you (but probably will).
>
> I agree with Dale, and would add that a knowledge of Assembly makes for a
> better C programmer.  Shawn

Absolutely correct.  I would discourage anyone from using C until they
have learned enough essembly to know what they're doing and, more
importantly, what the PIC is doing.  And a quick look through the ASM
listing produced by the compiler is a good idea, if only to catch anything
you've done that has made an obvious huge impact.

Dale

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\10\14@231215 by sergio masci

flavicon
face
Matt Heck wrote:

[snip]

>
> ASSEMBLY
> pros:

[snip]

> cons:

[snip]

>    - very poorly suited to developing floating-point functions,
>      especially untested ones

The XCASM assembler supports floating point. So does the associated
XCSIM simulator.

Regards
Sergio Masci

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\10\15@153939 by Matt Heck

flavicon
face
> >    - very poorly suited to developing floating-point functions,
> >      especially untested ones
>
> The XCASM assembler supports floating point. So does the associated
> XCSIM simulator.

Sweet-- I'll have to look into it.  Do you happen to know if this
thing's IEEE compliant?  Converting values between two floating-point
packages to test things is an extra headache I'd like to avoid.

Thank you, Sergio!

--Matt

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\10\15@192247 by sergio masci

flavicon
face
Matt Heck wrote:

>>>    - very poorly suited to developing floating-point functions,
>>>      especially untested ones
>>
>> The XCASM assembler supports floating point. So does the associated
>> XCSIM simulator.
>
>
> Sweet-- I'll have to look into it.  Do you happen to know if this
> thing's IEEE compliant?  Converting values between two floating-point
> packages to test things is an extra headache I'd like to avoid.
>
> Thank you, Sergio!
>
> --Matt


Yep. IEEE 754 32 bit single format stored little endien order.

The assembler uses .df .dsf and .pic_df directives to initialise memory
and associate labels with floating point quantities (association allows
the simulator to display, monitor and edit multibyte quantities such as
floats, longs and words according to their type). The .pic_df directive
generates retlw statements suitable for PIC table lookup.

The floating point library supports IEEE 754 single format quite NaNs
(including +/- Infinity) and rounding is by simple truncation.

The assembler allows statements of the form:

fred    .dsf        0
jack    .dsf        0
bert    .dsf        0

      .let    fred = bert / jack

Here the assembler will generate all the code necessary to invoke the
floating point divide function with parameters bert and jack, and then
store the result to fred.

The assembler also allows embedded user functions
e.g.

      .let    fred = SIN(theta) * bert

where SIN is a user defined function

Regards
Sergio Masci

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...