Re: C or Assembly

On Tue, 07 Mar 2006 00:36:59 +1300, Andrew Merton <nobody@xxxxxxxxxxx>
wrote:

I think one point is that Assembler *needs* more comments.

No language *needs* comments. People need comments.

In C, you
have (I think) at least 32 characters for each variable or function name
(anyone got K&R somewhere?); in Assembler you get 6-8 and no lowercase,
so a function can't be "Build_Gear" - it has to be "GEAR", and therefore
requires a comment.

My assembler allows 256-character symbols. I just don't like typing
long things filled with case shifts and underscores. I like any label
or variable name to be easily pronuncable.

Again, the code tells what was done, and the comments tell why.

Actually, I'd use "BuildGear()" these days (I've been Java-fied), and I
just realised that C-style would dictate "build_gear()" anyway, I think.
Oh well...

Why not

Build_Gear_Waveshape_Into_Wave_Table_With_Programmable_Missing_Teeth

That's what it does.

But then, the comments at the header of the GEAR routine explain it in
detail.




; WE'LL TRY TO EXECUTE THE MACRO, AND WILL RETURN STATUS
; IN D7. B15 WILL BE UP IF WE DETECT AN ERROR.

XMAC: CLR.W AFLAG.W ; NUKE 'ADD WAVE' REQUEST

MOVE.W # 0FF00h, D7 ; ERROR CODE 255 WILL BE 'BAD MACRO'

"D7" makes my point for me (I believe it's a register?) - it *needs* to
be commented for the reader to have any idea what's going on. Same with
the other registers...

There is no point in describing D7 is a 32-bit register; that's
obvious to anyone who knows how to program a 68K in assembly. I
haven't seen an "Introduction to the C language" embedded in any of
the C programs I've read. Do you explain the meaning of "int" each
time before you use it? (Actually, "int" is a lot more ambiguous than
"D7") Again, comments shouldn't be used to explain the language;
that's a given, and it's in the books. Comments explain *why* we're
doing things.


BTW - I apologise for not noticing the form-feeds(?) in the code I quoted...

All my programs are paged for easy reading. And there's a table of
contents at the beginning of the program listing, based on the
embedded .SBTTL directives (this idea cribbed from MACRO-11.) So the
entire program can be seen in one beautiful, indexed, heavily
commented fanfold paper listing. I take it to bed, chocolate at hand,
and *read* it a couple times before I ever run it. Most of the stuff,
hardware-intense deep-embedded stuff, runs first-time.

Of course, I'd never program an accounting application, or anything on
a PC, in assembly.



Ignoring everything except the actual XMAC function and its equivalent,
there are 6 lines (*including* braces) where something is executed in
the C version. (Some of the braces could be removed, but this is the
style I like; others have only syntactical use).

Comparing this to 15 lines (17 if I should be including the OKAY group)
where something can go wrong in the assembler version - how can it
possibly be quicker to develop and test the latter?


You assume that fewer "lines" correlates to fewer errors. That doesn't
make sense to me. It seems to me that clean, visible, *carefully
thought-out* logic will have the fewest errors. *Adding* lines will
often make the flow clearer and safer. I type very slowly, which is
another reason my code has few bugs. *Thinking* about what you're
doing makes it more reliable, as compared to touch-typing hairy code
at blinding speeds. Commenting my code makes me think about it; I
review it on the spot, then again as I proofread it.

Since most programmers spend several times as long debugging their
code as typing it, and typically only find most, not all of the bugs,
clearly they should slow down and think. Commenting is one way to slow
down and think.

I program hard embedded stuff in assembly because I like it, and
because I finish sooner, with far fewer bugs, than the typical C
programmer, and because the result is a beautiful document that I can
come back to years later and understand immediately without having to
"decode" it.

They don't call programs "code" by accident.

I wind up programming a *lot* faster than most C programmers, if you
include "programming" to mean "fielding a bug-free program."

Possibly you're one of the few programmers who are just more productive
than the average - there's a measured difference in productivity of
something like 10x(?) between the worst and the best (I think in
Peopleware, by Tom DeMarco)

Well, one of the reasons I'm a productive programmer is because I'm an
engineer, not a programmer.

John


.

Relevant Pages

  • Re: Evolution
    ... > inline assembler and larger parts by linking to an assembler ... in the HLL. ... language, particularly in smaller projects. ... > or two instructions if you ...
    (alt.lang.asm)
  • Re: HLA StdLib2 criticism
    ... HLC.EXE with an already existing C compiler and calls it HLC system. ... Suppose someone creates a new language and calls it "High Level ... Assembler" (HLA). ...
    (alt.lang.asm)
  • Re: What is an assembly language?
    ... HLA is an assembler. ... So what is this essential ability of an assembly language that is ... > that Randy-HLA isn't an x86 assembler. ...
    (alt.lang.asm)
  • Re: What is an Assembler
    ... > Salomon offers the following definitions for a High Level Assembler (or ... > A high-level assembler language is a programming language ... > Here you use the same abbreviation (HLA) for two total different ... refer to these languages by the name of the compiler. ...
    (alt.lang.asm)
  • Re: BethTool ?
    ... drawing Mickey Mouse is easier but that's not actually so...when ... > assembler author ought to aspire towards. ... a Forth-like way that defining your language is actually hand-in-hand ... inconsistencies;)...and NOT by simply "adding more features" - you ...
    (alt.lang.asm)