Searching \ for ' HLLs vs. ASM' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page:
Search entire site for: 'HLLs vs. ASM'.

No exact or substring matches. trying for part
PICList Thread
2002\04\17@180640 by Matt Heck

Hello Timothy,

The typical reasons and criteria for selection of a high-level language for
an embedded
project (PIC, 8051, what have you) are:

1. You can afford the cost of a good compiler for the target platform
2. You want reduced development time
3. You want reduced debugging time (page/bank issues, etc.)
4. Your target processor may change somewhat (example: bank and page size
changes between parts are just a recompile in C, but a major nightmare in
5. You feel confident that if you did the project in fairly tight assembly
you'd still have 30-40% of your program ROM free.
6. You want to reuse existing C, Java, etc., code with minimal
7. You want to be able to port a standard library (for example, an IEEE
compliant floating-point package) without worrying about the implementation
8. You want to be able to port and test the code on another platform (such
as a PC) natively.
9. Performance isn't an issue, or at least not a major issue.
10. You have multiple people working on the code at once.
11. You have at least one person on the team who is new to the target
assembly language, and at least one other person who rarely comments
anything.  This is a really strong argument to use a compiler (as well as
revision control).

Now, that said, not all compilers deliver all those things or have all those
requirements on all platforms.  For example, not all microcontroller
compilers use IEEE floating-point.  (Don't buy one that doesn't, by the way,
unless you're sure you know what you're doing, or you won't be using
floating-point math.)

Likewise, typical reasons and criteria to use assembly instead of a
high-level language include:
1. You cannot afford the cost of a good compiler for the target platform
2. You're not in a hurry
3. The processor is easy to debug on (NOT necessarily true for the PIC,
unless you're already familiar with troubleshooting Page and Bank issues) or
already very familiar to you
4. Your target processor is fairly well locked down
5. You're not even sure you're going to be able to cram everything onto the
chip in assembly
6. You're writing everything from scratch and don't expect to reuse any of
it on another chip
7. You don't care about interfacing with other "standard" functions or
protocols, or if you do, you are willing to write or test the implementation
8. You can do all your testing on the device, with an ICE, or with a
processor-level simulator.
9. Performance is critical.
10. You're the only one working on it and you can keep track of any "clever"
things you do in assembly that optimize down better than they would in C.
11. Your whole team is using a revision-control system, everyone understands
the processor well, and all code is well-documented.

Regardless of which approach you pick, let me strongly suggest:
1. Acquire, learn to use, and use religiously, CVS, Sourcesafe, or some
other revision control system.  Even if it's just you, you'll appreciate the
ability to roll back.
2. Split projects into multiple modules, instead of having huge, monolithic
assembly files.  It makes it easier to roll back changes, add new features,
and change where things go in memory at link-time.
3. Document the hell out of everything.  If you see documentation in your
code that is no longer correct, replace it.  If you don't have time to do
that, at least add an "[OBSOLETE]" above and below it to warn people--
including your future self.
4. Get the best debugger you can afford.  If you can't afford an in-circuit
emulator (ICE), you should also find a hobby that helps you relieve stress
extremely well.

Best of luck,
  Matt Heck

{Original Message removed}

2002\04\17@200712 by Benjamin Bromilow

I was very interested in the HLL vs LLL argument a few years ago when I was
programming mainly on x86 platforms. To test the HLL vs LLL problem I wrote
the same program in TPascal and A86 assembly language. The Tpascal version
had about 1/10 the R+D of the x86 version. It was much bigger (though
partially as it was an .exe rather than a .com, and was slightly slower....
The findings can be found at
(which BTW is frozen in time as I've forgotten the password!!!, hence the
new HP at
I found that, while programming using x86 assembly was an intellectual
challenge and resulted in faster programs, for everyday usage, and for big
programs (where user input tends to be the greatest source of program delay)
a HLL is more practical, especially when cross-platform compatibility is
concerned. I still like to (and still do) program in PIC assembly


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

2002\04\18@120945 by Sergio Masci

picon face
Having read many points of view on this subject over the years and having
some experience of my own to draw upon, I asked myself how I could improve
an assembler to give it some of the benefits of a HLL while retaining the
original benefits of the assembler. The answer seems quite obvious in
retrospect, take away the mundane boring error prone high level to low level
expression conversion chore, take away the multi word arithmetic chore, take
away the juggling of accumulators and index registers chore and take away
the juggling of temporary RAM chore. These are all the things that a
compiler does for you and it seems they would be a real benefit to anyone
using an assembler if only the rest of the HLL baggage could be left behind.
The assembler programmer does not want to be told to use a HLL and
continually break out into assembler. The programmer may not even be in a
position to use a HLL regardless of personal preferences (possibly having
inherited a legacy system to maintain that was originally written in
assembler). What seems to be required is the ability to add the occasional
high level statement to the assembler source without all the fuss of
declaring RAM locations in a special way or special support statements to
open and  close HLL mode. These new high level extensions to the assembler
must provide a transparent mechanism wherein the high level statements can
interact with the rest of the assembler source without imposing on it. They
must generate multi word arithmetic when the assembler notices the use of a
multi word RAM variable without the need to explicitly declare the RAM
variable in some strange way so that it can be exported to a third party
compiler. The assembler programmer should be free to add and remove high
level statements without hunting around and changing definitions. XCASM is a
meta assembler that does all this and more. It also provides aggressive
optimisation of high level expressions. An online interface to this
assembler is provided at

Sergio Masci

-- hint: The list server can filter out subtopics
(like ads or off topics) for you. See

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