Re: Ten years later


Randy wrote:

I know that one may learn asm with the HLA-detour, but the influence
of the HLL-style will remain even later using FASM or else.

As well it should. There is absolutely no reason why all, or even
most, assembly language source code should be written in a completely
unstructured programming style. Assembly's reputation as an unreadable
mess, not to be considered by any reasonable software engineer, is
exactly due to the attitudes of a few assembly programmers such as
yourself. There *are* times when destructuring one's code to achieve
some goal is a reasonable thing to do. By and large, however, one
would hope that the influence of a HLL-like programming style will
remain with those students. Because only once people start writing
readable assembly code will assembly's reputation as an unreadable
language ever change.

My code style use data stuctures and cache-aligned code modules,
so there is nothing 'unstructured' by any means.

Readabilty depends just on what tool one like to view it.

Most of your students give up ASM right after they passed examina.
Most students give up ASM right after the complete the course.
What's your point?

The question is then "why all the endeavour ?"
Just waste time to satisfy the professor ?

ASM-coding is not prone to easy earn money, it is the rare used
special language to write OS-parts, BIOS and hardware-drivers.

What does that have to do with anything? Are you saying that BIOSes
have to be written using unreadable code? Or that parts of OSes that
use assembly have to be written in unreadable code?

BTW, you do realize that many BIOSes today are being written in C,
right?

Unfortunately, but by any luck just the display/msg-section and
not at all in the hardware related part.


HLL and HLA is perhaps good for fast but dirty mass-production,
because the end-user wont care much about performance as (s)he
don't know better anyway. I see this as 'betray customers'.

What does performance have to do with anything? Are you saying that
all assembly language code must be written with nothing but
performance in mind? If so, go an criticize some of the other
assemblers around here. Take a look at RosAsm, for example. That code
was *not* written to be fast; it's performance is due more to the
power of today's processors than any clever assembly coding that Rene
has done. The same can be said for FASM. These guys were obviously
*not* counting cycles when they wrote their code (indeed, Rene
constantly *brags* about the fact that he doesn't count cycles in his
code). And RosAsm was certainly written in a HLL-like style. I don't
care if Rene wants to argue about macros versus native implementation,
when you see a bunch of IF and WHILE statements in the source code,
that tells me it was written in a HLL-like style. What do you have to
say about that?

First, RosAsm is a 'windoze only' ASM-tool.
Rene never said his code is fully optimized (except for Equates).
But it is only on the programmer how the final application
performs as (s)he isn't bound to any std.lib or other unwanted stuff.

It is amusing ...
I miss the sense in the above.
IOW, you don't like the fact that people *are* learning assembly
language using AoA, it upsets your little "world view." See you keep
poking around hoping to find some little nit to pick on (like the
stack frame nonesense) so that you have something to complain about.
In the meantime, you're missing the big picture -- people *are*
learning assembly language using AoA.

I can see it and this make me feel very sad.
You took the correct term "stackframe nonsense" (=).

As HLA is a *machine* specific language. I don't see any HLA code
running on a PowerPC, for example. Now if you're going to claim that
programs written in a specific assembly language syntax cannot run
across different operating systems (which is the "portability" that
HLA supports), then I guess we've got to strike NASM, FASM, and Gas
from the list of assemblers, eh?

All assemblers (except RosAsm yet) will be able to create code
for any OS (just CPU compatible) as long they are not bound to a LIB.
Your attempt to support other OS with new LIBs is one more detouring
step towards HLL. I know, you will sell this as feature ...

No, the fact that most decent assemblers got HLL-styled features
in addition to plain ASM wont change the definition of ASM.

So then, why does the fact that HLA have them change the definition of
ASM?

You always tell everybody that HLA is an assembler,
if one could produce a single byte '.com' file with it (like FASM)
then I would rank your tool as an assembler even it's just a front-end.

If I look on Wannabee's code it's already (his own created) HLL,
but he wouldn't write system-software that way.

How would you know? Has Wannabee claimed he wouldn't write system
software that way?

Look at his code: time-critical sections are less HLL-styled :)


And one other point -- the portability that HLA achieves is
accomplished via a set of library routines that people can call.
That's not part of the assembly "language". Again, consider Vid's
FASMLIB. Portable code across Linux and Windows. Are you saying that
FASM is not an assembly language because people can do this?

As above, these are additional features.

So they are additional features for FASM, but not for HLA?

The opposite is what I mean, HLA wont come without this addons!

What's wrong? look at your own code and find out yourself how
many redundant PROC's could be replaced by single instructions.
[HLAStrs]

No, you tell *me*. You're the one making the accusations. Why don't
*you* tell me how many procedures can be replaced by single
instructions? I doubt you'll find too many in the HLA stdlib, or the
strings package for that matter.

Ok, I'll do it. May take a while as I'm busy with 'real' things.
I will start a new thread when conversion into readable ASM is done.

Oh, and BTW, yes, a string comparison function *ought* to use a whole
bunch of instructions that semantically could be replaced by a single
rep.movsb or rep.cmpsb instruction. However, one who is so concerned
about performance as you seem to be *surely realizes* that those
string instructions tend to be quite slow and that a discrete sequence
of instructions is usually faster. Such is the beauty of macros and
procedures -- they let you abstract things like this away so that you
can easily swap in a faster way of doing things as the processor
technology changes. At one time, the string instructions were the fast
way to do things. Today, they are not. Tomorrow, they may well be
again. Putting this type of code into a procedure or macro is the best
way to insulate yourself from such changes.

Sure, but macros aren't at all bound to PROC and stack frames.

It's not the start/end mark I'm against,
it's the coding style in general.
PROC are anchient standard, detouring, delaying and often just
useless stack-pollution.

HLA procedures simply mark the beginning and end of a procedure.
Automatic generation of stack frame is an *optional* thing that you
can easily turn on or off depending on your requirements.
The fact that *you* don't use stack frames doesn't mean that
*everyone* should avoid them. For people like you, two statements at
the beginning of an HLA source file turn off all the automatic stack
frame generation. Now you can write code to your heart's content the
way you want to. And still use procedures to help make your code more
readable.

Good, but why should I use the term PROC(no-arg..) when CALL is enough?

My disassembler can read the header of your files.
And I used (many years ago) TA and PB as well.
Obviously, you were not disassembling any HLA code.

See my answer to Frank on this one.

__
wolfgang


.

Relevant Pages

  • Structures in Assembly Language
    ... implementation in assembly language. ... Structures, or records, are an abstract data type ... decades, or so), and many assemblers still do not ... "old-timer" assembly language programmers attempt ...
    (alt.lang.asm)
  • Re: HLA v1.86 is now available
    ... I believe there was a book written for the early IBM assemblers ... Windows program in assembly. ... So no one has learned Win32 programming in assembly language since I ...
    (alt.lang.asm)
  • Re: Which Assembler?
    ... Having used none of the 'assemblers' listed below, ... programming in assembler for 35 years a couple of points can be made. ... have to know more than one assembly language. ... Most of the comments about NASM being slow/limited are very outdated. ...
    (comp.lang.asm.x86)
  • Why people perceive ASM to be hard to read
    ... > Its much the same comment as I made to Robert, horses for courses, ... because most people perceive that assembly language programs are *hard* ... assemblers that attempt to simulate these features. ... existed because *most* assembly language programmers weren't using ...
    (alt.lang.asm)
  • Re: Hey Mr. Hyde!
    ... fewer and fewer students get introduced to assembly language ... programming and, in fact, wind up with four years' of instructors telling ... It really isn't Randy Hyde, Universities, OSes, or high-level assemblers ...
    (alt.lang.asm)