Re: HLA Stdlib v2.2 is now available.

On Sep 16, 11:33 pm, Frank Kotler <fbkot...@xxxxxxxxxxx> wrote:

Windoze *and* Loonix, is how I'd put it. BSD and MacOS are promised. I
don't think there are plans to port it to KESYS. If you wanted it to
work on KESYS (don't look so horrified, this is only make-believe),
you'd make a "kesys" directory, and provide "read", "write", "open",
"close", et endless cetera - don't forget "exit"!!! (Randy - in the
older v2 code I'm looking at... "linux/brk.hla" - no problem with the
code, but the comment refers to "times"??? You've probably already got
that one).

Cut & Paste strikes again!


Randy says "POSIX-like"... How would I do "hello world" in KESYS? The
library kinda expects you to use "write", with "stdout" as a "file
descriptor". If KESYS does it some radically different way, maybe the
HLA library *wouldn't* work on KESYS, or would be unbearably painful to
port.

Not at all. There is a stdout.write, a stderr.write, and a
fileio.write function. Currently, stdout.write and stderr.write are
written in terms of fileio.write using a file handle. If you had a
separate API for writing stuff to the console, you'd just modify
stdout.write and stderr.write to call those.

Basically, as long as you have a "putc" routine that writes a single
character to the console device, you can port all the stdout and
stderr code.

Seems to me that MenuetOS might be a tough port - it's pretty much
"all GUI all the time", and may not have the concept of "stdout".

But, no doubt, it wouldn't be that hard to write a little "terminal
emulator" application that gets linked in whenever you call
stdout.write or stderr.write (or any function that ultimately calls
these two).

If
that's what you're calling "C conventions"... not strictly accurate, but
I'll go along. But how 'bout OS/2? Can't call *that* a "C OS", but I
think it would be possible to port the HLA library to OS/2, if anyone
wanted to (Bernhard followed Laura off to the Madonna NG and doesn't
come to see us any more, so no one does...).

In theory, there is no reason you couldn't port much of the HLA stdlib
to a 32-bit protected DOS. Sure, you'd probably lose some of the more
exotic file system function calls, but it wouldn't be that hard.


The beauty of the library, for Lindows or Windix, is that Randy's
already done the work!

And that's the beauty of the Stdlib v2.x -- it's being organized so
that it's really easy to port the code to different operating systems.


and only for compilers which accept the compiler switches,

The only compiler involved in the library is HLA, and it accepts the
switches it needs. If you're talking about building HLA, the
executable(s), on NotCOS, yeah you need a compiler - Bison, too - to
build version 1.x. Version 2, if and when, will build itself, using
nothing but HLA. That's the point of porting the library *first*. Once
you've got the library ported, you can use hla or hla.exe on Nixdows or
Linwin as a cross-compiler to produce an executable for your new OS.
From then on, HLA will run on the new OS... no C anywhere.

I have no idea what Wolfgang means by "it runs on C." That's a totally
meaningless statement. Obviously a derogatory statement made in
ignorance to try and make something sound bad about the stdlib.


But HLA was written so Randy could teach assembly language (with AoA)
the way he *wanted* to teach it - starting with the HLLisms, which the
newbie is presumed to know (this doesn't describe all newbies to
assembly language, but that's Randy's primary target), and working down
to "real assembly language"... about chapter 7, I think. (seems like a
long time to wait) If not all students make the "descent"... well, they
might not have gotten far starting at the bottom, either...

One comment about "long time to wait". The purpose of most "assembly
language" courses at the university level is to teach "MACHINE
ORGANIZATION and Assembly Language". Indeed, the "maching
organization" component is the main reason assembly language is still
taught -- schools certainly aren't interested in cranking out assembly
language programmers.

Let's consider those first six chapters:

1 - Hello World
This chapter provides a basic introduction to the machine.
Registers,
basic machine data types, stuff like that.

2- Data Representation
An in-depth discussion of things like numbering systems,
bits, bytes, words, dwords, arithmetic and logical operations,
signed vs. unsigned representation, integer vs. floating-point
representation, BCD, etc.

3- Memory Access and Organization
Things like addressing modes on a CPU, how memory is laid
out in the system, how data is organized in an application,
segments/sections, the stack, and the heap.

4- Constants, Variables, and Data Types
The difference between how a constant is represented and
variables are represented. How to define and use constants
(equates) in a program. Different data types including
characters, strings, character sets, arrays, records/structs,
pointers, unions, namespaces, and so on.

Note that the discussion up to this point is completely independent of
assembly language. Indeed, there really isn't much *programming* to
discuss -- this is just all "core knowledge".

5- Procedures and Units
This chapter provides a discussion of procedures, local and global
objects,
parameters, ways of passing parameters, and recursion.

This is the first chapter where the coding starts to get serious. BTW,
the characterization that students don't see low-level assembly
language until chapter 7 is wrong. What the students don't see until
Chapter 7 is how to implement certain HLL-like control structures like
IF, WHILE, FOR, etc., in low-level assembly. Throughout these first
five chapters the student is being introduced to a large number of
pure machine instructions. Section 5.11, for example, is entitled "Low
Level Procedures and the CALL instruction." It completely describes
how to write low-level procedures (e.g., "@noframe; @nodisplay") style
procedures and functions, so that HLA doesn't generate any "hidden
code" for the student. This is, undoubtedly one of the more complex
things that students get taught in a 10-15 week course, and there it
is in the fifth chapter.

6- Arithmetic
Once again, like chapter five, this chapter is all about low-level
assembly coding. The student is taught how to convert various
arithmetic expressions into their low-level machine code equivalents.

Finally, we get to Chapter Seven:

7- Low-level Control Structures
Where the student is taught how to write low-level equivalents of
IF, WHILE, etc.

Now let's look at the journey the student has made-
The first four chapters really aren't about programming. They're about
machine organization. Because an assembly language programming course
is about *programming* I like to ensure that the students are doing
programming throughout the course, even if the subject matter they're
covering is of a "more theoretical in nature" form. Therefore,
throughout those first four chapters, the students are introduced to
various machine instructions that allow them to learn the basic x86
instruction set at a measured pace. For example, the students learn
about the MOV, ADD, and SUB instructions in Ch1. They learn about the
AND, OR, XOR, NOT, NEG, CBW, CWD, CDQ, CWDE, MOVSX, MOVZX, SHL, SHR,
SAR, ROL, ROR, RCL, RCR, CLD, STD, CLI, STI, CLC, STC, CMC, SAHF, and
LAHF instructions in Ch2. In Ch3, besides all the 32-bit addressing
modes, they learn about the PUSH, POP, PUSHA, PUSHAD, PUSHAW, PUSHF,
PUSHFD, POPA, POPAD, POPAW, POPF, POPFD, INC, DEC, and LEA
instructions. In Ch4, they learn about the INTMUL (imul), BOUND, INTO,
and BT. In Ch 5 they learn about CALL and RET. In Ch6, they're
introduced to MUL, IMUL, DIV, IDIV (and MOD/IMOD - synonyms for DIV/
IDIV), CMP, SETcc, TEST, FLD, FST, FSTP, FXCH, FSQRT, FILD, FIST,
FISTP, FBLD, FBSTP, FADD, FADDP, FSUB, FSUBP, FSUBR, FSUBRP, FMUL,
FMULP, FDIV, FIDVP, FDIVR, FDIVRP, FPREM, FPREM1, FRNDINT, FABS, FCHS,
FCOM, FCOMP, FCOMPP, FTST, F2XM1, FSIN, FCOS, FSINCOS, FPTAN,
FPATAN,FYL2X, FYL2XP1 FINIT, FNINIT, FLDCW, FSTCW, FCLEX, FNCLEX,
FSTSW, FNSTSW, FIADD, FISUB, FISUBR, FIMUL, FIDIV, FIDIVR, FICOM, AND
FICOMP.


"working down to 'real assembly language' .. about chapter 7" is a bit
of a gross mischaracterization of what is taking place in the first
six chapters. What additional instructions to they learn in Chapter
7? Well, that would be JMP and Jcc - the conditional jumps.

Now you could make an argument that students should be taught these
conditional jumps sooner in the text just to be able to do away with
the HLL-like control structures introduced in Ch1; but what purpose
would that serve? To introduce those instructions (and the concepts
behind time) would require you to push off some other instructions
"until chapter seven". What is that going to accomplish in the long
term? Absolutely nothing.

You may fear that some students won't get as far as Chapter 7 and,
therefore, "won't really know assembly language." I think that's
pretty obvious. Ch 7 is, by no means, the "epoch" that divides
"knowing assembly" from "not knowing assembly. Ch 10, "Advanced
Arithmetic" is pretty important, too (as it teaches one of the few
things you cannot do well in a HLL -- extended precision arithmetic);
Ch 11, on "Bit Manipulation" is another classic "assembly language"
subject most people expect assembly language programmers to know. Let
us not forget the string instructions, described in Ch 12; though
they've fallen out of favor because of lackluster performance, I don't
think anyone can seriously call themselves an x86 assembly language
programmer without knowing what these instructions do.

Now I *do* believe that the remaining chapters contain optional
material (MMX, classes and object-oriented programming, and mixed-
language programming) that someone doesn't have to absolutely know in
order to call themselves an assembly language programmer, and you can
probably get by without chapter 8 (File I/O), but I pretty much argue
that all the rest of the material in the book is required reading if
you want to call yourself an "assembly language programmer."
Understanding how to write low-level control structures is certainly a
necessary condition to join the ranks of assembly language
programmers, but it is not a sufficient condition. Again, describing
Ch 7 as some epoch is a mischaracterization -- both in terms of the
material covered before Ch 7 and in terms of the material that
follows.

Yes, a beginner can elect to stop learning the instruction set prior
to learning enough to justify the title "assembly language
programmer". Moving the material in Ch 7 earlier into the textbook
won't change that one bit. Indeed, as I've pointed out already, I
would argue that getting *to* Ch 7 doesn't justify the title.

I think it should be obvious to anyone who has been around a while
that AoA has had a lot of pedagogical research and testing put into
it. Unlike certain other "tutorials" and "lessons" that have appeared
recently, AoA has been around in one form or another since 1989. And I
would also point out that it wasn't the first book on assembly
language programming that I wrote. Compare the organization of the 16-
bit edition of AoA with the 32-bit edition sometime. You'll discover
that I *used* to teach the conditional jumps a lot earlier on. They
got moved because I discovered a *better* way to teach the stuff. Just
because I learned it some other way (which is the way I originally
taught the subject) doesn't mean that the way I learned it was the
best way to teach it. That is the problem most people in this
newsgroup have -- they figure that the *best* way to teach a subject
is the way *they* learned it. They've never bothered trying to teach
the subject in several different ways and pick the way that works
best. I've been around long enough, and I've been blessed with having
had 1000s of students go through my courses, so I could try out lots
of different approaches before settling on the one I use in AoA.

hLater,
Randy Hyde

.

Relevant Pages

  • Re: Teaching Assembly Language Programming
    ... focusing on learning assembly language. ... distraction for many students: nightly keggers. ... programming projects around the things I wanted the ... The chapter on floating-point instructions would deprecate the use ...
    (alt.lang.asm)
  • Re: HLA v1.86 is now available
    ... because during that first week the students probably don't even ... Let's start with the instructions Evenbit used in his example: ... language course -- they can call a subroutine using syntax that is ... you have no experience teaching students assembly language ...
    (alt.lang.asm)
  • Re: Ten years later
    ... antiquated programming styles, be prepared to face a little criticism ... The outcome would not *define* what "assembly language ... programming style no more defines what "assembly language programming" ... I apologize that I didn't write a book to teach students to make code ...
    (alt.lang.asm)
  • Re: ping Purl Gurl? Beginner Level Perl
    ... arguing for years that anyone learning computer programming should have ... assembly language is an EE subject, and that, among other ... it doesn't match the mindset and skill set of CS students. ... "How I Discovered the Difference between Windows and a Real Operating ...
    (alt.usage.english)
  • Re: ping Purl Gurl? Beginner Level Perl
    ... arguing for years that anyone learning computer programming should have ... assembly language is an EE subject, and that, among other ... it doesn't match the mindset and skill set of CS students. ... "How I Discovered the Difference between Windows and a Real Operating ...
    (alt.usage.english)