Re: Evolution

From: Herbert Kleebauer (klee_at_unibwm.de)
Date: 11/19/03 

Date: Wed, 19 Nov 2003 14:46:38 +0100

hutch-- wrote:
 
> > 1. What is your definition of assembly programming? What makes
> > it different from HLL programming?
>
> Basically the choice to write code in whatever way you like. I am
> personally a dinosaur and I often write code in the old style because
> it well suits what I have to do. What I reject is the lack of choice
> in whether I can pelt something together fast or be forced through
> lack of flexibility to keep reinventing the wheel by coding something
> than does not change over and over again.

What you describe here is a HLL: you have the freedom to use all from
OOP, simple HLL constructs (like if for while do ..) down to
simple processor instructions. And that is surely the best way to
write applications. Use a C++ compiler to write the main part and
implement only critical sections in assembler (small parts with
inline assembler and larger parts by linking to an assembler
generated object file). But in these optimized assembler parts
you surely don't need HL constructs (otherwise it wouldn't have
been necessary to implement this part in assembler).

> Having the choice between direct mnemonic coding at the low end and
> combinations of libraries that I write myself and macros that I write
> myself is starting to give me the capacity I require when writing

The use of libraries has nothing to do with the way (low level
or high level constructs) the source for the main program (which
links to the library) or the library itself was coded. Macros
are a different thing. The use of macros may simplify the writing
of a program but is also dangerous: often you are not aware how
many code is generated when you use a macro (especially when
the macro is from a macro library which you have written a long
time ago). But if you would have to manually include the code
instead of using a macro, you would see, that sometimes it is
much better to use a subroutine and call this subroutine than
just inserting the same macro again and again. Because macros
are often as general as possible, you maybe can save one
or two instructions (e.g. save and restore a register) if you
don't use this general macro but insert the code directly.
So, either you have to optimize your code for every byte and
nanosecond, then don't use macros or there is no need for this
optimization, then don't use an assembler but a HLL.

 
> assembler. Effectively I want an assembler that is powerful enough to
> emulate other coding styles rather than restrict what I write to
> someone elses limited vision.

Why do you want to emulate other coding styles? Just use
this other coding styles (your C or Basic Compiler) and only
use assembler where this other coding styles are not appropriate.

> > 2. In these days, what is the reason to write an application in
> > assembler instead of using a HLL (for desktop systems, not
> > embedded systems)?
>
> Basically size and performance justify desktop applications written in
> assembler if the method of production is fast and efficient enough. If

Size:
Do you think it is a positive marketing argument, when you say your
new game fits on 3 floppies instead of 3 DVDs? And you can only
reduce the size of the code and not the size of the data by programming
in assembler. How many percent of a big Windows application (game,
compiler or office packet) do you think is code resp. data? Even if
you can reduce the code size by 20% how much would reduces this the
overall size?

Speed:
You must be a very good assembly programmer to compete with the
code generator of a modern compiler. And "good assembly programmer"
means, that you know the processor architecture very well (which
instructions can be executed in parallel, how to avoid pipeline
conflicts or cache misses and so on) and not that you have a good
grasp of the assembler syntax. And I doubt, that somebody who try to
learn assembly programming with HLA will become a "good assembly
programmer" in that sense.

So if you want fast code, write all the parts which are not time
critical in a real HLL (and not in a "want to be HL" language like
HLA or MASM) and use the saved time to optimize the time critical
parts by using low level assembler code.

> assembler programming was restricted to middle 80s style assembler
> programming, the answer would be that there is no reason as a decent C
> compiler is a reasonably good performer in the low level area.
> Fortunately 21st century assembler is not crippled and restricted to
> middle 80s style coding and can routinely do things like reusable code
> in libraries, emulate aspects of high level coding with macros and
> some of the built in control structures.

Yes, the "21st century assembler" is called C++ or Delphi or ....
But if you need uttermost optimized code (either size or speed)
you still have to do "middle 80s style coding" by using processor
instructions and nothing else in your source code.

> > 3. Why should somebody nowadays still learn assembly programming?
> > Only to be able to write the programs of 2. or are there other
> > good (or even much better) reasons?
>
> A couple of reasons here. Size and speed still mean something to most
> programmers and while they may have had to suffer garbage generators,
> they can and do write smaller faster code if they have the chance. The

See my answer to 2.

> other aspect is that the programmer who bothers to learn assembler
> writes better high level code after as they know far more about the
> code they are writing.

I think, this is the main reason to learn assembly programming.
So you have to differentiate between an assembler optimized for
learning assembly programming and an assembler for writing
applications. To learn assembly programming in the first place
you don't even need an assembler, the processor user manual is
sufficient (but the other way around is not possible: you can't
be a good assembly programmer without reading the processor manual).
But it is very boring to only read the manual without practical
testing. But you should only use processor instructions as
outlined in the processor manual and no HL constructs. You should
directly write instructions for the processor and not instructions
for the assembler which are used by the assembler to generate
instructions for the processor.

You also need an operating system which allows you to experiment
with all the processor instructions, so Windows is inappropriate.
You need the processor in real mode, so best is to use DOS without
EMM loaded. DOS isn't obsolete to learn assembly programming, which
is the generation of a sequence of processor instructions and has
nothing to do with operating system (the processor knows nothing
about the running operating system, a call to the operating
system is nothing but a INT or CALL processor instruction).

> The success of MASM in 32 bit Windows has had a
> lot to do with programmers being able to leverage their existing
> skills in a pure assembler environment.

Now we are by assemblers for writing applications. It is hard to
write a real application with a real assembler. To make it easier
you can add macro support and/or some simple HL constructs. But
it would be stupid to stop here. Just go on and you will end by
a HLL like C or C++. There is no need and no market for an assembler
for writing applications (I'm not speaking from embedded systems
or driver programming, but applications for desktop systems).
I also can't see a "success of MASM in 32 bit Windows". Show me
the Windows applications written in MASM (which are not only written
just for fun). If there were a market for such an assembler, you
can be sure MS wouldn't give it away for free.

 
> > 4. What is the difference of obsolete DOS programming and Windows
> > programming in respect of learning assembly programming? (Or did
> > you include the words "operating system" in your assembly
> > programming definition in 1.)
>
> Basically the task the user has in mind. If you need to write process
> control that requires real mode hardware access, DOS coding is not
> obsolete and can do things that protected mode operating system find
> very difficult to do well. Where Windows coding has its advantages is
> in the sheer volume of people who use Windows. 32 bit assembler is a
> lot clearer and certainly faster as it can access far larger blocks of
> memory, it has more instructions available and it is not cursed with
> segment arithmetic.

I fully agree, writing DOS applications is obsolete. But I asked
about learning assembly programming. And for this purpose there
is no better operating system than DOS (it is great if you can
use hardware breakpoints by using the processor debug registers
in your debugger).

 
> Now I have a question as the response by many people to the
> contribution that Randy Hyde has made over many years has never made
> sense. I saw his work on the internet as early as 1996 and he helped
> to keep alive one of the ancient black arts when fashion dictated
> bloated garbageware. I had to learn assembler that hard way from
> Microsoft documentation in the pre-internet era by writing test pieces
> so i well understand the advantage of well documented tecnical data
> being available.

I never understood why people want to read second level documentation.
If you want to learn assembler programming, forget about all the
assembler books and read the x86 processor manual (or better read it
twice). Then select a simple assembler (or better write your own,
if you do it without macro support and without FPU, MMX, SSE instructions
then you only need a few lines of C code and you will learn much
more about the instruction set than just using an existing one)
and start writing your first program. All you need for this is the
documentation how to read from the keyboard and stdin and how to write
to the screen and stdout (and that is much easier in DOS than Windows).
 
 
> His later work in HLA is certainly different but it is not without
> purpose or design. Randy has a backround in teaching and that gives
> him some advantages in terms of what a student can reasonably learn in
> a semester or two.

As I see it:
Randy has to give an assembler course at the university. Nowadays
students are not interested in learning assembly programming. So
what can he do? He designs a simple HLL with good inline assembler
support and calls it "High Level Assembler". Now all are happy,
the students don't need to learn assembly programming, he gets
enough students for his course and his employer still thinks the
students learn assembly programming (because of the name HL Assembler).
That isn't a problem at all, but sometimes there are people who
really want to learn assembly programming (e.g. in this group).
And if these people use HLA then in the best case this is just a
waste of time but in the worst case they really believe, that the
have learned assembly programming and will become much trouble
later, when they need assembly programming in there job.

> I have seen C compilers that convert their high
> level code to assembler before assembling it so the concept is not
> without precedent and it appears to yield results in terms of
> comprehension.

No problem if he call his tool SHLL (Simple High Level Language)
instead of HLA. Then it is clear, that you learn just an other
HL language (which is simple and therefore can't compete with
a real HLL) and nobody will have the wrong presumption that he
now is a good assembly programmer.

 
> I am personally a fan of diversity and this has its range from direct
> low level coding in mnemonics, libraries, macros, DLL access and more
> ambitious projects like HLA.

I fully agree, but you shouldn't use the name "assembly programming"
for this diversity.

> I suggest that assembler programming is poorer when this diversity is not present.

No. Programming is poorer when this diversity is not present. Assembly
programming (the art of generation an optimized sequence of processor
instructions) is just one method of this diversity.

Herbert

Relevant Pages

  • Re: Trivia Question
    ... This is what I meant by "ignorance". ... people's *existing* HLL knowledge to learn assembly language programming? ... Which I had such an assembler when starting with Delphi. ... After working with the needed instructions some times, repleatly, they tend to stick around in your memory. ...
    (alt.lang.asm)
  • Re: HLA Stdlib v2.2 is now available.
    ... Its a generalization of the whole asm community based on the results of a single man. ... You dont get it. ... Because it is an assembler, and a very good one, showing the way for other spesific assemblers. ... As they both are needed for doing programming, I see no reason to seperate them. ...
    (alt.lang.asm)
  • Re: "We Never Use Assembly Language"
    ... Use an array incorrectly in RosAsm, ... And that's one of the reasons HLL programming is generally more ... same applies to assembler speed. ...
    (alt.lang.asm)
  • Re: Future of programming
    ... but again, let's not forget in my opinion the main purpose of programming, ... the more abstract the programming language ... code-generators, or even efficient compilers, which is not the case ... > fastest solution to the problem, then assembler is still needed. ...
    (alt.lang.asm)
  • Re: HLA History
    ... >> sequence of processor instructions to solve a given problem. ... I have written my trivial assembler ... >> programming. ... pupils to learn to write with 10 fingers. ...
    (alt.lang.asm)