HLA question

[Hugh Aguilar]

In my CONST section I have this:

dummy: uns32 := $deadbeaf;

In my code I tried this unsuccessfully:

mov( dummy, [ebp] );

Why didn't that work? That is a legal x86 instruction (opcode C7), but
the assembler choked on it. The error message said: "unexpected [".I
had a similar problem when using ADD rather than MOV, which is also
legal.

The following kludge works okay:

mov( dummy, eax );
mov( eax, [ebp] );

[Nathan Baker]

"Hugh Aguilar" <hughag...@yahoo.com> wrote in message
news:c222f9ea-fa76-4a06...@f35g2000yqm.googlegroups.com...

> In my CONST section I have this:
>
> dummy: uns32 := $deadbeaf;
>
> In my code I tried this unsuccessfully:
>
> mov( dummy, [ebp] );
>
> Why didn't that work? That is a legal x86 instruction (opcode C7), but
> the assembler choked on it. The error message said: "unexpected [".I
> had a similar problem when using ADD rather than MOV, which is also
> legal.
>

Ah... you've stumbled on 'proof' that "HLA is not an assembler"... er, so
certain 'someones' may argue. ;)

It has been a while since I have been 'intimate' with the depths of HLA
nuances, so I'm not sure if this is a supposed "feature" or just an
over-looked bug. As you probably realise, HLA's *default* state is to
handle a lot of details "behind the scenes" so that a 'newby' need not know
anything about stack manipulation, ABI, calling conventions, and the like.
However, many of these "features" may be dissabled via command-line switches
and a variety of keywords. For instance, one can use the "@noframe;
@nodisplay;" sequence to dissable the automatic generation of a stack frame
and display when declaring a procedure. Something like:

procedure KickHLLbutt(); @noframe; @nodisplay;
begin KickHLLbutt;
...
...
...
ret();
end KickHLLbutt;

Also, I believe the lowest level (very close to the way traditional
assemblers behave) is to compile a Unit:
http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/www.artofasm.com/Windows/HTML/ManagingLargePrograms.html#999913

It has been a while since I've played a "how low can you go" game with HLA,
so I don't remember if other keywords/switches/nuances are needed to dance
the Limbo. In the event that you've actually uncovered a bug, there exists
a tracker for reporting such items:
http://sourceforge.net/tracker/?group_id=287373&atid=1217516

I don't expect Randy to address the issue until after the busy Christmas
season is over.

Happy Assembling!

Nathan.
http://clax.inspiretomorrow.net/

[wolfgang kern]

Nathan Baker mentioned:
...

> Ah... you've stumbled on 'proof' that "HLA is not an assembler"... er, so
> certain 'someones' may argue. ;)

One of this 'someones' is me in person as a matter of fact :)

Even I have to grant that a few HLA-lectures may be informative for a
couple of Computer-Science students (aka plain C-coders) in some aspect,

I'd never would recommend HLA as a platform to learn how hardware really
work, and HLA is for sure not recommendable as a beginners tool for all
who prefer reality over heavy bloated detouring abstractions.


Macros may be of help, but I daubt that they help on performance or
transparency...
__
wolfgang

[Rod Pemberton]

"Nathan Baker" <nathan...@gmail.com> wrote in message
news:BsmdnQ5fG84Gt0TT...@giganews.com...

> "Hugh Aguilar" <hughag...@yahoo.com> wrote in message
> news:c222f9ea-fa76-4a06...@f35g2000yqm.googlegroups.com...
> > In my CONST section I have this:
> >
> > dummy: uns32 := $deadbeaf;
> >
> > In my code I tried this unsuccessfully:
> >
> > mov( dummy, [ebp] );
> >
> > Why didn't that work? That is a legal x86 instruction (opcode C7), but
> > the assembler choked on it. The error message said: "unexpected [".I
> > had a similar problem when using ADD rather than MOV, which is also
> > legal.
> >
>
> Ah... you've stumbled on 'proof' that "HLA is not an assembler"... er, so
> certain 'someones' may argue. ;)
>

I just thought he might've had the wrong syntax or be missing a keyword.

E.g., ...
Does HLA use brackets for memory references?
Does HLA need a memory size keyword on [ebp]?
Does HLA need the arguments as parameters?
Are his parameters in the correct order for HLA?

The first two of those three seem plausible to me for the "unexpected ["
error.

If I was attempting to determine not well documented syntax for some
assembler, I'd first check to see if that assembler has a disassembler, or
disassembler mode. If it does, I'd edit a binary file, placing the needed
instruction in it. Next, I'd disassemble, use the disassembly syntax, and
hope that that produces the correct results when reassembled, but checking
it, of course. Alternately, I'd attempt to find examples of other
instructions, with similar syntax, that work, by looking at code in HLA or
reading the manuals for HLA examples. Most assemblers have instructions or
syntax that isn't supported when it should be or is supported when it
shouldn't be.

But, I must thank you - as an HLA user - for (re)confirming our beliefs
about HLA ... ;-)


Rod Pemberton

[Nathan Baker]

"Rod Pemberton" <do_no...@noavailemail.cmm> wrote in message
news:jbc07r$bdo$1...@speranza.aioe.org...

> "Nathan Baker" <nathan...@gmail.com> wrote in message
> news:BsmdnQ5fG84Gt0TT...@giganews.com...
>> "Hugh Aguilar" <hughag...@yahoo.com> wrote in message
>> news:c222f9ea-fa76-4a06...@f35g2000yqm.googlegroups.com...
>> > In my CONST section I have this:
>> >
>> > dummy: uns32 := $deadbeaf;
>> >
>> > In my code I tried this unsuccessfully:
>> >
>> > mov( dummy, [ebp] );
>> >
>> > Why didn't that work? That is a legal x86 instruction (opcode C7), but
>> > the assembler choked on it. The error message said: "unexpected [".I
>> > had a similar problem when using ADD rather than MOV, which is also
>> > legal.
>> >
>>
>> Ah... you've stumbled on 'proof' that "HLA is not an assembler"... er, so
>> certain 'someones' may argue. ;)
>>
>
> I just thought he might've had the wrong syntax or be missing a keyword.
>
> E.g., ...
> Does HLA use brackets for memory references?
> Does HLA need a memory size keyword on [ebp]?
> Does HLA need the arguments as parameters?
> Are his parameters in the correct order for HLA?
>
> The first two of those three seem plausible to me for the "unexpected ["
> error.
>

Well by-golly, you are correct! The correct syntax is:

mov( dummy, (type uns32 [ebp]) );

> If I was attempting to determine not well documented syntax for some
> assembler, I'd first check to see if that assembler has a disassembler, or
> disassembler mode. If it does, I'd edit a binary file, placing the needed
> instruction in it. Next, I'd disassemble, use the disassembly syntax, and
> hope that that produces the correct results when reassembled, but checking
> it, of course. Alternately, I'd attempt to find examples of other
> instructions, with similar syntax, that work, by looking at code in HLA or
> reading the manuals for HLA examples. Most assemblers have instructions
> or
> syntax that isn't supported when it should be or is supported when it
> shouldn't be.
>

Well, HLA doesn't *do* disassembly; nor is there an associated disassembler.
However, OllyDbg natively supports HLA syntax:
http://www.ollydbg.de/

> But, I must thank you - as an HLA user - for (re)confirming our beliefs
> about HLA ... ;-)
>

Consider it an early Christmas present.

Nathan.

[Fritz Wuehler]

> > Ah... you've stumbled on 'proof' that "HLA is not an assembler"...

I believe IBM changed the name of their z/OS assembler to HLA before Randall
Hyde came up with his Jekyl and Hyde version of an Intel assembler. The IBM
version is just assembler with some high level constructs built in. It is
still easily readable and doesn't require you to use the new features. The
Hyde version looks ghastly and it's surprising since Dr. Randy is one of the
top Intel assembly gurus aside from Rod and Wolgang ;-)

[Nathan]

On Dec 3, 2:15 pm, Fritz Wuehler

<chuckle> Rod and Wolfgang are "top ASM gurus"??? HarHarhahaha...
I'm sure glad that I put my hip-waders on today. Tell me another tall
tale. LOL!!!

Nathan.

[Frank Kotler]

Nathan wrote:

> <chuckle> Rod and Wolfgang are "top ASM gurus"??? HarHarhahaha...

Right. I don't think either one of them ever wrote a .pdf!

Best,
Frank

[Rod Pemberton]

"Frank Kotler" <fbko...@myfairpoint.net> wrote in message
news:jbeenp$rai$1...@speranza.aioe.org...

> Nathan wrote:
>
> > <chuckle> Rod and Wolfgang are "top ASM gurus"??? HarHarhahaha...
>
> Right. I don't think either one of them ever wrote a .pdf!
>

No, but I do have 200KB+ of programming related text files I've written.
Maybe, I'll put them online someday. They are mostly DOS, C, and DJGPP
and/or OpenWatcom related. My main personal utilities in C directory has
160+ programs. My main personal utilities in assembly directory has almost
300 programs. Many are trivial or very specialized, but some are larger or
more generic and could be useful by non-programmers. That doesn't include
code and utilities for my other personal projects, which are slightly larger
projects like: an OS, assemblers, compilers, interpreters. That also
doesn't include ports, disassemblies, and updates to various publicly
available programs. Most of this was coded post '02, the handful of stuff
before that was lost or destroyed, and minimal anyways.


Rod Pemberton

[Rod Pemberton]

"Nathan" <nathan...@gmail.com> wrote in message
news:e23de203-a773-4177...@4g2000yqu.googlegroups.com...

On Dec 3, 2:15 pm, Fritz Wuehler
<fr...@spamexpire-201112.rodent.frell.theremailer.net> wrote:

> > [...]

> > Hyde version looks ghastly and it's surprising since Dr. Randy is one of
> > the top Intel assembly gurus aside from Rod and Wolgang ;-)
>
> <chuckle> Rod and Wolfgang are "top ASM gurus"??? HarHarhahaha...
>

Nate, Nathan ... I'm *really* surprised you went straight for that! I know
we usually see things slightly different. But, his vague, provocative
comments could be understood in a quite a few ways:

1) Randall flat out 'sux' since he's no "top Intel assembly guru" (fill in
the blank with whomever), e.g., "x86 status names" such as Michael Abrash,
Paul Hsieh, John Carmack, Terje Mathison, H. Peter Anvin, etc.

2) Rod and Wolfgang are far better at x86 than everyone else here in a.l.a
... I.e., Nathan and Frank and others here sux for using HLA, hutch-- for
MASM, Betov for Rosasm, or whomever we can pick on ...

3) "IBM is superior to everything else esp. z/OS assembly, ignoring my
overcompenstaing ego ''I'm'' (guy posting via remailer alias Fritz Weuhler)
still an IBM assembly 'god' despite being retired for some years, and you
all are nothing but pitiful, lowly, x86 coders. Man, ''I'' coded
mainframes! During their prime! Usually, to find primes ... :-( "

See?


Rod Pemberton

[Rod Pemberton]

"Fritz Wuehler" <fr...@spamexpire-201112.rodent.frell.theremailer.net> wrote
in message
news:39dee2af09d0da46...@msgid.frell.theremailer.net...

There are Dr. Randall Hyde's out there, but apparently the guy who wrote HLA
isn't one of them. Mr. Hyde, apparently "just" an MS of CS, author of HLA,
created what I would describe "C-like inline x86 assembler which uses a
mostly C-like syntax but not enough C syntax that it's useful in a C
environment".

I don't have a problem with HLA as long as no one claims it's actually an
x86 assembler. It's not x86 assembly. It's not even assembly. It's a high
level language that mimics assembly's functionality and syntax. Deluding
naive college students such as CS major's inexperienced in programming into
thinking that HLA is assembly, is a bad idea IMO. As is, it's good for
teaching high-level programming concepts. With some changes, i.e., a pure C
syntax, it could be useable as an inline assembler for C projects.
Basically, I've not looked at the code, but from various descriptions from
Nathan, Frank, and Betov, etc it's rather bloated.


Rod Pemberton

[Nathan]

On Dec 3, 8:38 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "Nathan" <nathancba...@gmail.com> wrote in message

>
> news:e23de203-a773-4177...@4g2000yqu.googlegroups.com...
> On Dec 3, 2:15 pm, Fritz Wuehler
>
> <fr...@spamexpire-201112.rodent.frell.theremailer.net> wrote:
> > > [...]
> > > Hyde version looks ghastly and it's surprising since Dr. Randy is one of
> > > the top Intel assembly gurus aside from Rod and Wolgang ;-)
>
> > <chuckle> Rod and Wolfgang are "top ASM gurus"???   HarHarhahaha...
>
> Nate, Nathan ...  I'm *really* surprised you went straight for that!  I know
> we usually see things slightly different.  But, his vague, provocative
> comments could be understood in a quite a few ways:
>

I meant *my* comments to be understood as friendly bar-room ribbing.
People don't pick on you if they don't like you. An obviously
facetious "protestation against what was said" is *actually* a
humorous way to concur with the speaker. Thus, I was affirming that
both Wolfgang and you *do* belong to the "guru"/"status names" group.
Take your compliments with a rum chaser. ;)

> 1) Randall flat out 'sux' since he's no "top Intel assembly guru" (fill in
> the blank with whomever), e.g., "x86 status names" such as Michael Abrash,
> Paul Hsieh, John Carmack, Terje Mathison, H. Peter Anvin, etc.
>
> 2) Rod and Wolfgang are far better at x86 than everyone else here in a.l.a
> ... I.e., Nathan and Frank and others here sux for using HLA, hutch-- for
> MASM, Betov for Rosasm, or whomever we can pick on ...
>
> 3) "IBM is superior to everything else esp. z/OS assembly, ignoring my
> overcompenstaing ego ''I'm'' (guy posting via remailer alias Fritz Weuhler)
> still an IBM assembly 'god' despite being retired for some years, and you
> all are nothing but pitiful, lowly, x86 coders.  Man, ''I'' coded
> mainframes! During their prime!  Usually, to find primes ... :-( "
>
> See?
>

I suppose so. But there's certainly no need to dull the Yule-time
cheer by over-thinking UseNet's off-handed commentary. I'd order you
a boilermaker if we found ourselves in a pub -- you seem like you
could use one, good sir.

Nathan.

[wolfgang kern]

Frank and Nate in good mood:

>> <chuckle> Rod and Wolfgang are "top ASM gurus"??? HarHarhahaha...

> Right. I don't think either one of them ever wrote a .pdf!

Oh yes, right! :)

I never did nor planned to create double encripted books.
And I'm a machine-code-man rather than an ASM-guru ...

I need to know all details on every bit from my fully paid hardware.
So even my hexedit coding style isn't slow at all, I waste(?) much
time in study and test in deep detail. kinda diletantism ? :)

__
wolfgang

[Fritz Wuehler]

"Rod Pemberton" <do_no...@noavailemail.cmm> wrote:

> 3) "IBM is superior to everything else esp. z/OS assembly,

Correct as understatedly written ;-)

> still an IBM assembly 'god' despite being retired for some years

Hey man I'm still cashing in while the cashing is good. Won't retire until
the lights go out at the last IBM datacenter

> and you all are nothing but pitiful, lowly, x86 coders.

x86 does suck hard but I admire you guys who know how to beat it into
submission. I should have included Frank in the list of gurus, my bad. I
hope ARM or at least some other more reasonable design than x86 (and that
would be just about anything) slams the door on x86/x64 but I don't see it
happening as predicted.... maybe if Microsoft goes under or Longsoon takes
over the world we'll all be coding MIPS assembly

[Nathan Baker]

"Frank Kotler" <fbko...@myfairpoint.net> wrote in message
news:jbeenp$rai$1...@speranza.aioe.org...

> Nathan wrote:
>
>> <chuckle> Rod and Wolfgang are "top ASM gurus"??? HarHarhahaha...
>
> Right. I don't think either one of them ever wrote a .pdf!
>

Well, hot dog! There ya go... at least I got my name on the publisher's
page and in the acknowledgements. ;)

http://www.amazon.com/gp/reader/1593272073/ref=sib_dp_pt#reader-link

Better not keep our hip-waders on too long, we don't wanna accidentally
contribute to today's sermon.

Nathan.

[Robert Redelmeier]

Fritz Wuehler <fr...@spamexpire-201112.rodent.frell.theremailer.net> wrote in part:
> x86 does suck hard but I admire you guys who know how
> to beat it into submission.

x86 may indeed suck, but the moment you believe this,
you have beaten yourself and it has won.

The irregularities of x86 definitely pose a challenge. But in
all challenges there is both trouble and reward. Finding the
right allocation of registers, memory modes and instructions
is very gratifying, both in performance and personal terms.

x86 will be frustrating for someone who wants to grind
like a compiler on a RISC chip. It is the poor workman
who blames his tools. While setup goes much faster, for
key optimized x86 loops, 1.0 LoC/hr is excellent progress.


-- Robert

[Frank Kotler]

Fritz Wuehler wrote:

...

> I should have included Frank in the list of gurus, my bad.

No, I am merely an "experienced beginner".

Just to be clear, I don't actually *use* HLA - I think it's absolutely
horrid! But as Robert points out, "It is the poor workman who blames his
tools." HLA "is what it is."

For those newer to a.l.a., Betov - author of RosAsm and one of HLA's
more "colorful" detractors - used to refer to Randy as "Master PDF". The
bit about "never written a .pdf" was intended as a little joke for those
who get it, and no "attack" on Rod or Wolfgang!

Best,
Frank

[Fritz Wuehler]

Robert Redelmeier <red...@ev1.net.invalid> wrote:

> Fritz Wuehler <fr...@spamexpire-201112.rodent.frell.theremailer.net> wrote in part:
> > x86 does suck hard but I admire you guys who know how
> > to beat it into submission.
>
>
> x86 may indeed suck, but the moment you believe this,
> you have beaten yourself and it has won.

Nah, I have other choices. I figure I win by using a good architecture and
good development tools and most of all good hardware, which is all but
impossible to obtain with anything Intel-related. I leave the Intel crap to
Microsoft and guys who have no choice of what to work on.

> The irregularities of x86 definitely pose a challenge. But in
> all challenges there is both trouble and reward. Finding the
> right allocation of registers, memory modes and instructions
> is very gratifying, both in performance and personal terms.

Maybe, but I'm not the kind of guy who enjoys creating works of art out of
horseshit, used tampons and crazy glue. I know people can do that but it
isn't my thing. No offense btw, just answering your post. ;-)

> x86 will be frustrating for someone who wants to grind
> like a compiler on a RISC chip. It is the poor workman
> who blames his tools.

True, but it's an unhappy workman who chooses shitty tools. My dad always
taught me to buy the best tools I could because they produce the best
quality work and they last. Totally opposite of the Intel view of an ISA as
a garbage dump/techno junkyard.

[Robert Redelmeier]

Fritz Wuehler <fr...@spamexpire-201112.rodent.frell.theremailer.net> wrote in part:

> Robert Redelmeier <red...@ev1.net.invalid> wrote:
>> x86 may indeed suck, but the moment you believe this,
>> you have beaten yourself and it has won.

> I leave the Intel crap to Microsoft and
> guys who have no choice of what to work on.

Some of us like the challenge.

>> x86 will be frustrating for someone who wants to grind
>> like a compiler on a RISC chip. It is the poor workman
>> who blames his tools.

> True, but it's an unhappy workman who chooses shitty
> tools. My dad always taught me to buy the best tools I could
> because they produce the best quality work and they last.

Often true, but not always -- there is such a thing as
excessive quality (see "power of compound interest" [Einstein]).
Also "Better is the enemy of the good" [Voltaire]

> Totally opposite of the Intel view of an ISA as a garbage
> dump/techno junkyard.

Ah, but a phenomenally successful and long-lived ISA. Whatever x86
inelegance, it has blown away all competitors for ~30yrs . Even
Apple has not merely gone x86, but also largely ISA -- MS-Windows
will run on Apple hardware, and Apple OS/X on PC hardware.
Such dominence indicates abiding, if unacknowledged, advantages.

x86 is only now being seriously challenged in the low-power
arena by ARM/Linux/Android. Intel Atom is miserable,
VIA Eden old and slow, AMD Geode the best of a bad lot.
SubWatt CPU has not yet been worked by Intel/AMD. They will,
if smartphone/tablets are seen as taking over.


-- Robert

[Rod Pemberton]

"Fritz Wuehler" <fr...@spamexpire-201112.rodent.frell.theremailer.net> wrote
in message
news:bbaba792e718f851...@msgid.frell.theremailer.net...

>
> True, but it's an unhappy workman who chooses shitty tools. My dad always
> taught me to buy the best tools I could because they produce the best
> quality work and they last. Totally opposite of the Intel view of an ISA
> as a garbage dump/techno junkyard.
>

I've posted on the on the fallacy of the "you're only as good as your tools
philosophy" previously. Skills, experience, and knowledge do count, and not
just for a little bit. E.g., from a more recent post describing a situation
where my tools were "bad tools" ...

``Many years ago, the employees of a small company I worked for constantly
espoused the: "You're only as good as your tools philosophy," repeatedly.
They had tools for everything. One day, one of our electrical engineers
(EE), saw me starting to replace damaged QFP chip (It looks like it was
BQFP). A number of circuit boards like these needed to be fixed. He was a
bit shocked as to how I was doing things. He reiterated the "tools"
philosophy. He the said he could do better. I said I bet he couldn't. He
lost. It was a method I had perfected to avoid use of the machine I'll
describe next, which he-in his wisdom-decided to use. We had a machine,
sort of like an industrial clothes press which opened and closed, and that
heated, gripped, and pulled QFP chips off the circuit board, once they were
heated enough that the solder melted. Two hours later, he still hadn't
managed to remove and replace one chip. The problem with the machine was
that it couldn't heat all sides of the chip evenly and consistently enough
to remove the chip. When it did, it would destroy the chip by excessive
heat. In this case, that didn't matter since the chips were damaged. The
method I was using, which shocked him, uses an X-acto knife, a flux pen,
professional desoldering iron and standard sized professional soldering
iron. I cut the chip's legs off flush to the QFP using an X-acto, heated
and removed the pins with a flick of the iron, desoldered the contact pads,
placed a new chip, fluxed it, soldered it using an iron that was "way too
large" for the small pins *without* bridging the pins with solder. You
couldn't tell the chip had been removed and replaced when I was done. This
takes about 2 minutes.``

http://groups.google.com/group/comp.lang.misc/msg/486e1683459a9dee

A skilled programmer can do much with limited tools too.


Rod Pemberton

[Rod Pemberton]

"Nathan Baker" <nathan...@gmail.com> wrote in message

news:e7GdnVAiQ8LNCEbT...@giganews.com...

> "Frank Kotler" <fbko...@myfairpoint.net> wrote in message
> news:jbeenp$rai$1...@speranza.aioe.org...
> > Nathan wrote:
> >
> >> <chuckle> Rod and Wolfgang are "top ASM gurus"??? HarHarhahaha...
> >
> > Right. I don't think either one of them ever wrote a .pdf!
>
> Well, hot dog! There ya go... at least I got my name on the publisher's
> page and in the acknowledgements. ;)
>
> http://www.amazon.com/gp/reader/1593272073/ref=sib_dp_pt#reader-link
>

Yes, it seems you can read, technically ... ;) C'mon that was funny!
Juxta-position of "technical reader" ...


Rod Pemberton

[Rod Pemberton]

"Fritz Wuehler" <fr...@spamexpire-201112.rodent.frell.theremailer.net> wrote
in message

news:55e205b9078c80d1...@msgid.frell.theremailer.net...

> "Rod Pemberton" <do_no...@noavailemail.cmm> wrote:
>
> > 3) "IBM is superior to everything else esp. z/OS assembly,
>
> Correct as understatedly written ;-)
>
> > still an IBM assembly 'god' despite being retired for some years
>
> Hey man I'm still cashing in while the cashing is good. Won't retire
> until the lights go out at the last IBM datacenter
>

"... and that, my liege, is how we know the Earth to be banana shaped."

> > and you all are nothing but pitiful, lowly, x86 coders.
>
> x86 does suck hard but I admire you guys who know how
> to beat it into submission.

It's not like we're native hunters clubbing seals ... Too soon?

The functionality is there for x86.

> I should have included Frank in the list of gurus, my bad. I
> hope ARM or at least some other more reasonable design
> than x86 (and that would be just about anything) slams the
> door on x86/x64 but I don't see it happening as predicted.

> maybe if Microsoft goes under or Longsoon takes
> over the world we'll all be coding MIPS assembly
>

The cpu wars are over. x86 won, or so we all thought. The ARM stole
everything else. I seriously thought that platform died, like circa '92.


Rod Pemberton

[Nathan Baker]

"Rod Pemberton" <do_no...@noavailemail.cmm> wrote in message

news:jbh6jb$5o6$1...@speranza.aioe.org...

>>
>> Well, hot dog! There ya go... at least I got my name on the publisher's
>> page and in the acknowledgements. ;)
>>
>> http://www.amazon.com/gp/reader/1593272073/ref=sib_dp_pt#reader-link
>>
>
> Yes, it seems you can read, technically ... ;)

That's the Yuletide spirit!

Nathan.

Nathan.

[Hugh Aguilar]

On Dec 3, 6:45 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

> There are Dr. Randall Hyde's out there, but apparently the guy who wrote HLA
> isn't one of them.  Mr. Hyde, apparently "just" an MS of CS, author of HLA,
> created what I would describe "C-like inline x86 assembler which uses a
> mostly C-like syntax but not enough C syntax that it's useful in a C
> environment".

HLA is based on Standard Pascal (it supports functions compiled within
other functions) and Icon (it supports generators) --- it doesn't look
like C at all, and the aforementioned features aren't available in C,
so it wouldn't make sense for HLA to be an inline assembler for a C
compiler.

When I first saw HLA, I turned a cold shoulder on it, because I hate
Pascal and it looked like more of the same. When I learned that HLA
had Icon-inspired features, my interest-level rose to lukewarm, which
is where it is currently --- this is enough to induce my to write a
simple test program in HLA, but not enough to induce me to become a
career HLA programmer (as if there even were such a thing, which there
isn't).

> I don't have a problem with HLA as long as no one claims it's actually an
> x86 assembler.  It's not x86 assembly.  It's not even assembly.  It's a high
> level language that mimics assembly's functionality and syntax.  Deluding
> naive college students such as CS major's inexperienced in programming into
> thinking that HLA is assembly, is a bad idea IMO.  As is, it's good for
> teaching high-level programming concepts.  With some changes, i.e., a pure C
> syntax, it could be useable as an inline assembler for C projects.

HLA is an x86 assembler. Only assembly language allows registers to be
defined globally --- this is why I'm using assembly language rather
than C for my Forth. I could have chosen FASM and NASM instead --- I
primarily chose HLA because it has a library supporting console-mode
programs that can assemble for either Windows or Linux without any
change to my source-code --- the Forth stuff would be essentially the
same with any assembler though. I am not using any of HLA's high-level-
language features in my Forth. I'm implementing low-level Forth words
such as DUP and SWAP in assembly language --- what possible use could
I have for OOP and thunks and generators within this context? This is
pretty basic assembly language --- implementing DUP and SWAP isn't
exactly rocket science.

I am well aware that you guys hate HLA for having high-level-language
features --- why don't you just do what I am doing and ignore those
features? I think that it is worthwhile to learn the basics of HLA
now, because I might have use for the advanced features in a future
project (like when I write the IDE for my Forth), so I'm glad that
those arrows are in the HLA quiver in case I eventually need them ---
but for now I am just using HLA as a simple assembler.

You have stated on comp.lang.forth that you are writing a Forth in C,
and I have told you several times that this is an incredibly bad idea.
C-based Forth systems are inherently under-powered and over-
complicated. Believe me, I know a lot more about Forth compiler-
writing than you do. I have also told you several times that it is a
good idea to write at least one small application in Forth before
delving into Forth compiler-writing, in order to first learn the
rudiments of the language from a user's perspective. The world is
already full of people who claim to be great experts at Forth because
they have written an interpreter for Forth (usually in C, but it has
even been done in Perl), but who in the next breath will state that
Forth is grossly inefficient, ugly and unreadable, completely lacking
in HLL features, and generally worthless for application programming
--- you are well on your way toward joining their ranks --- I can tell
you upfront that nobody will care; there is no point in going through
all of this effort just to make a negative contribution to Forth.

You currently know as much about HLA as you do about Forth, which is
something close to nothing.

> Basically, I've not looked at the code, but from various descriptions from
> Nathan, Frank, and Betov, etc it's rather bloated.

All of you guys' responses to my question about the MOV(dummy,[ebp]);
instruction have been comparable to the above --- informed by
ignorance, driven by arrogance and successful at nothing! I asked a
straight question about how to assemble a particular addressing-mode
in HLA, and I never got a straight answer --- if you guys are in doubt
about the answer to any question that I may ask, please don't hesitate
to shut the hell up.

I'm not championing HLA; I'm still a complete novice at it --- it is
just the assembler that I chose to use for my current project ---
whether this was a good choice or a bad choice, isn't really anybody's
business except my own.

[Nathan Baker]

"Hugh Aguilar" <hughag...@yahoo.com> wrote in message

news:98bd4be2-44ac-42d1...@l24g2000yqm.googlegroups.com...

> Basically, I've not looked at the code, but from various descriptions from
> Nathan, Frank, and Betov, etc it's rather bloated.

<--

All of you guys' responses to my question about the MOV(dummy,[ebp]);
instruction have been comparable to the above --- informed by
ignorance, driven by arrogance and successful at nothing! I asked a
straight question about how to assemble a particular addressing-mode
in HLA, and I never got a straight answer --- if you guys are in doubt
about the answer to any question that I may ask, please don't hesitate
to shut the hell up.

-->

Oh, please calm down. I gave you the correct answer. Sorry if it got
hidden in all the rabble-babble. The correct syntax you are looking for is:

mov( dummy, (type uns32 [ebp]) );

<--

I'm not championing HLA; I'm still a complete novice at it --- it is
just the assembler that I chose to use for my current project ---
whether this was a good choice or a bad choice, isn't really anybody's
business except my own.

-->

Quite true! Welcome to ALA! ;)

Nathan.

[Herbert Kleebauer]

On 05.12.2011 04:59, Hugh Aguilar wrote:
> On Dec 3, 6:45 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
>> There are Dr. Randall Hyde's out there, but apparently the guy who wrote HLA
>> isn't one of them. Mr. Hyde, apparently "just" an MS of CS, author of HLA,
>> created what I would describe "C-like inline x86 assembler which uses a
>> mostly C-like syntax but not enough C syntax that it's useful in a C
>> environment".
>
> HLA is based on Standard Pascal (it supports functions compiled within
> other functions) and Icon (it supports generators) --- it doesn't look
> like C at all, and the aforementioned features aren't available in C,
> so it wouldn't make sense for HLA to be an inline assembler for a C
> compiler.

Ok, here and old posting in this group:


Frank Kotler wrote:
> Assembly language? Or not? Perhaps not, in your view, but if you can
> find a C compiler that'll process it, I'll eat Wannabee's hat!

Must be a well tasting hat because everybody wants to eat it.
But maybe I can help you. First, let's remove all the comments
so we better see the code:

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

#include( "stdlibdata.hhf" )
#include( "../include/conversions.hhf" )

procedure _atoh; @nodisplay; @noframe;
begin _atoh;

push( ecx );

xor( edx, edx ); // Initialize EDX:ECX with zero.
xor( ecx, ecx );

movzx( (type byte [esi]), eax );

repeatUntilNotHexDigit:

mov( stdlib.hexConvTbl[eax], al );
cmp( al, $ff );
je convErr;

cmp( edx, $1000_0000 );
jae Overflow;
shld( 4, ecx, edx );
shl( 4, ecx );
or( eax, ecx );

NextChar;
cmp( eax, $80 );
ja illChar;
bt( eax, (type dword Delimiters ));
jnc repeatUntilNotHexDigit;

mov( ecx, eax );
pop( ecx );
ret();

Overflow:
raise( ex.ValueOutOfRange );

convErr:
raise( ex.ConversionError );

illChar:
raise( ex.IllegalChar );

end _atoh;

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

To get a executable C program we need a simple main(), just
to call _atoh and print the result:

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

#include "stdlib.hhf"

main(){
reg[5]=(int)"1234abcd"; _atoh();
printf("high word %x low word %x \n",reg[1],reg[2]);

reg[5]=(int)"cdef0123abcd5678"; _atoh();
printf("high word %x low word %x \n",reg[1],reg[2]);

}

int _atoh()
begin (_atoh);

push( ecx );

xor( edx, edx );
xor( ecx, ecx );

movzx( (type byte [esi]), eax );

repeatUntilNotHexDigit:

mov( stdlib.hexConvTbl[eax], al );
cmp( al, $ff );
je convErr;

cmp( edx, $1000_0000 );
jae Overflow;
shld( 4, ecx, edx );
shl( 4, ecx );
or( eax, ecx );

NextChar;
cmp( eax, $80 );
ja illChar;
bt( eax, (type dword Delimiters ));
jnc repeatUntilNotHexDigit;

mov( ecx, eax );
pop( ecx );
ret(0);

Overflow:
raise( ex.ValueOutOfRange );

convErr:
raise( ex.ConversionError );

illChar:
raise( ex.IllegalChar );
end (_atoh);

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Now gcc complains, that it doesn't find the include file "stdlib.hhf"
(had to rename it to DOS 8.3 format, the other include file
"../include/conversions.hhf" isn't necessary when compiled with gcc).

Because you didn't post it, here is "stdlib.hhf"

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

#define begin(x) {
#define end(x) }
#define ret return
#define je if (zero) goto
#define jae if (!carry) goto
#define jnc if (!carry) goto
#define ja if (!carry && !zero) goto
#define NextChar Next_Char()
#define raise myraise
#define type /**/
#define dword /**/
#define $80 0x80
#define $ff 0xff
#define $1000_0000 0x10000000

int eax=0, edx=1, ecx=2, ebx=3, ebp=4, esi=5, edi=6, esp=7;
int al=10, dl=11, cl=12, bl=13, ah=14, dh=15, ch=16, bh=17;
int zero,carry,Delimiters=0;
int byte[8]={0,1,2,3,4,5,6,7};
unsigned int reg[8];

typedef struct {int hexConvTbl[8];} stdlib_t;
stdlib_t stdlib;

typedef struct {int ValueOutOfRange,ConversionError,IllegalChar;} ex_t;
ex_t ex;

void push(int a){};
void pop(int a){};
void xor(int a, int b) {reg[b]^=reg[a];}
void movzx(int a, int b) {reg[0]=(*(char*)(reg[5]))&0xff;};
void Next_Char() {reg[5]++; reg[0]=(*(char*)(reg[5]))&0xff;};
void shld(int a, int b, int c) {reg[1]=(reg[1]<<4) + ((reg[2]>>28)&0xf);}
void shl(int a, int b) {reg[2]=reg[2]<<4;}
void or(int a, int b) {reg[b]=reg[a] | reg[b];}
void myraise(int a) {printf("error\n"); exit (0);}

void mov(int a, int b)
{if (b==10) {if (reg[0]>='0' && reg[0]<='9') reg[0]-='0';
else if (reg[0]>='a' && reg[0]<='f') reg[0]-='a'-10;
else if (reg[0]>='A' && reg[0]<='F') reg[0]-='A'-10;
else reg[0]=$ff;}
else reg[b]=reg[a];}

void cmp(int a, int b) {
if (b==0xff) {if (reg[0]==b) zero=1; else zero=0;}
else if (b==0x10000000)
{if ((unsigned int) reg[1] >= (unsigned int) b)
carry=0; else carry=1; }
else if (b==0x80)
{if (reg[0]==b) zero=1; else zero=0;
if ((unsigned int) reg[0] >= (unsigned int) b)
carry=0; else carry=1; } }

void bt(int a, int b)
{if (reg[0]==' ' || reg[0]==9 || reg[0]==0) carry=1; else carry=0;}

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

[Robert Redelmeier]

Hugh Aguilar <hughag...@yahoo.com> wrote in part:

> In my CONST section I have this:
> dummy: uns32 := $deadbeaf;

Sorry for the slow reply but I was waiting for those with
some HLA experience. Just guessing, but this looks like a
declaration for a memory location in a CONST section called
`dummy` that contains 0xDEADBEEF

> In my code I tried this unsuccessfully:
> mov( dummy, [ebp] );

This would then be a mem-mem move using addressing modes
the x86 does not possess.

> Why didn't that work? That is a legal x86 instruction
> (opcode C7),

Ah, looks like you are trying to get C7 46 00 EF BE AD DE
move an immediate to [ebp+0]

You will need to rework you declaration of `dummy` so that
HLA understands it is a program document compile-time constant
(macro) and not a constant stored in a memory location.

> but the assembler choked on it. The error message said:
> "unexpected [".I had a similar problem when using ADD
> rather than MOV, which is also legal.

> The following kludge works okay:
>
> mov( dummy, eax );
> mov( eax, [ebp] );

These of course works because the 1st is legal
when `dummy` is a memory location.

OTOH, if CONST works as a compile time constant, Nathan
may be right and you need to explicitly specify (cast)
how much of `dummy` gets moved to [ebp] . Ugh!



-- Robert

[Rod Pemberton]

"Herbert Kleebauer" <kl...@unibwm.de> wrote in message
news:jbiae0$bst$1...@speranza.aioe.org...

> On 05.12.2011 04:59, Hugh Aguilar wrote:
> > On Dec 3, 6:45 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> > wrote:
> >> There are Dr. Randall Hyde's out there, but apparently the guy who
> >> wrote HLA isn't one of them. Mr. Hyde, apparently "just" an MS of
> >> CS, author of HLA, created what I would describe "C-like inline x86
> >> assembler which uses a mostly C-like syntax but not enough C syntax
> >> that it's useful in a C environment".
> >
> > HLA is based on Standard Pascal (it supports functions compiled within
> > other functions) and Icon (it supports generators) --- it doesn't look
> > like C at all, and the aforementioned features aren't available in C,
> > so it wouldn't make sense for HLA to be an inline assembler for a C
> > compiler.
>
> Ok, here and old posting in this group:
>

> [Herbert's C preprocessor use proving my point that HLA is C like ... ]

Again, the master of preprocessor abuse speaks. It just doesn't
seem to matter to you what language a program was coded for ...


Rod Pemberton

[Nathan Baker]

"Hugh Aguilar" <hughag...@yahoo.com> wrote in message

news:98bd4be2-44ac-42d1...@l24g2000yqm.googlegroups.com...

<<<
I could have chosen FASM and NASM instead --- I
primarily chose HLA because it has a library supporting console-mode
programs that can assemble for either Windows or Linux without any
change to my source-code
>>>

As the following example demonstrates, one can just as easily hijack the C
stdlib to handle seemless cross-platform I/O.

; For Windows:
; nasm -f win32 --prefix _ -o prime.obj prime.asm
; gcc -o prime.exe prime.obj
;
; For Linux:
; nasm -f elf32 -o prime.o prime.asm
; gcc -o prime prime.o

section .data
msg: db 'Enter an integer: ', 0
chr: db '%d', 0
ispmsg: db 10, 'The integer %d is prime!', 10, 0
nopmsg: db 10, 'The integer %d is not prime.', 10, 0

section .text
global main
extern printf, scanf

main:

push ebp
mov ebp, esp
sub esp, $0c

mov dword [ebp-8], 1
push msg
call printf
add esp, 4

lea eax, [ebp-4]
push eax
push chr
call scanf
add esp, 8

cmp dword [ebp-4], 2
jge next
mov dword [ebp-8], 0
jmp continue

next:
jne nextt
jmp continue

nextt:
mov eax, [ebp-4]
cdq
mov ebx, 2
idiv ebx
cmp edx, 0
je nexttt

finit
fild dword [ebp-4]
fsqrt
fistp dword [ebp-$0c]

mov ecx, 3
jmp ccheck
floop:
mov eax, [ebp-4]
cdq
idiv ecx
cmp edx, 0
jne check
mov dword [ebp-8], 0
jmp continue
check:
add ecx, 2
ccheck:
cmp ecx, [ebp-$0c]
jle floop
jmp continue

nexttt:
mov dword [ebp-8], 0

continue:
xor eax, eax
cmp eax, [ebp-8]
jne isprime
mov eax, [ebp-4]
push eax
push nopmsg
call printf
add esp, 8
jmp endit

isprime:
mov eax, [ebp-4]
push eax
push ispmsg
call printf
add esp, 8

endit:
add esp, $0c
pop ebp
xor eax, eax
ret

Nathan.

[Rod Pemberton]

"Hugh Aguilar" <hughag...@yahoo.com> wrote in message
news:98bd4be2-44ac-42d1...@l24g2000yqm.googlegroups.com...

> On Dec 3, 6:45 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
> > I don't have a problem with HLA as long as no one claims it's actually
> > an x86 assembler. It's not x86 assembly. It's not even assembly.
>

> HLA is an x86 assembler.

Argh! "Run to the hills ..."

> I'm implementing low-level Forth words
> such as DUP and SWAP in assembly language

I use C for my primitives. That's ANSI standard C. While C has changed,
ANSI C hasn't and is still compileable by the modern C compilers.

Roughly (I have some development related code ...) 37 pre-compiled
primitives or low-level words, 39 pre-compiled high-level words, and (NEW!)
30 Forth words entirely as ASCII text. The words aren't new, but parsing
them using the other 37+39 words is. I finally fixed the C side code enough
that I could migrate them out and did so. Anyway, if the implemented words
needed for ANS were ANS compliant (they aren't), that would leave another
122 words needed to implement the ANS Core and ANS Core extentsion sets. I
hope to end up with mainly just my primitives in C, but that'll require some
creativity since the initial setup words, inner and outer interpreter, and
parsing words are now needed to parse. I.e., I'll need to create minimal or
dummy versions, so I can move out as much code as possible in pure text
Forth. Without comments, I'd say 1700 lines of C. That's quite a bit
larger than it was recently. I reimplemented the entire dictionary as
pre-compiled C with dictionary headers. The headers in C added quite a bit
of lines of code. Previously, I used a C function to compile headers into
the dictionary and link to the correct compiled definitions. That took much
less code, but was dependent on a C function. If I eliminate the dictionary
(high- and low-level), the C code that does the work is maybe 100 lines,
most of which is #defines or executed once ... I've named my ITC inner
interpreter NEXT (whether that is correct historical usage or not). In
terms of lines of C, NEXT is 12. ENTER is 2. EXECUTE is 5. EXIT is 1.
DOCON is 2. DOVAR is 1. DODOES is 2. etc.

> I have for OOP and thunks and generators within this context?

None.

> This is pretty basic assembly language --- implementing DUP
> and SWAP isn't exactly rocket science.

As mentioned before, they can very simple, or be more complicated depending
on how you implemented your Forth system. The quantity of stack items
cached in registers, the quantity of stacks, etc all affect your
implementation. E.g., if you have two stacks, most Forth's do, one for data
or parameter stack, and one for control-flow or return stack, then you'll
need code to switch stacks. This can be done with XCHG, or other
instructions depending on where your two stack pointers are located. E.g.,
if you have the top two stack items in registers, you could use XCHG. If
you have the top one stack item in register, you'll need some other
sequence. If you don't cache, then PUSH and POP will do.

> You have stated on comp.lang.forth that you are writing a Forth in C,
> and I have told you several times that this is an incredibly bad idea.

Why?

1) I'm not implementing an ANS Forth (at least, not yet ...). Mine is an
ITC Forth. C can do that. It works (or seems to so far ...). It's mostly
fig-Forth like, but has some features from other Forths or changes which are
better choices based on my programming experiences, e.g., true as -1, CELLS,
etc.

2) I don't need your non-approved by ISO memory words which apparently
aren't compatible with GForth (GNU Forth) in GCC syntax C. I'm not sure how
or where I'd use them anyway. Nor am I familiar with what limitations a
Forth that couldn't implement them would have. It seemed that those adept
in Forth on c.l.f. were questioning their purpose too ... If they don't
understand what they are for, how would I?

3) While Forth's syntax and use of a stack are poor choices, IMO, ITC code,
Forth's dictionary, ability to compile words, Forth's inner and outer
interpreter's, etc are very effective given their minimalism. They could be
re-purposed to other language interpreter's, and maybe with far greater
influence than Forth has had.

I posted a list of implemented words a while back on c.l.f. I've been
working on other issues with it, so not many more words have been added
since then. Do you want to see my list of implemented words? I broke a
couple of them when eliminating some of the C side code, but I'll re-fix
them, e.g., I broke DOES> since it messed with DP which was being sync'd by
the C code.

> C-based Forth systems are inherently under-powered and over-
> complicated.

AISI, if my system is underpowered, it's underpowered because ITC is
underpowered or because fig-Forth is underpowered or both. As I stated
above, there is not much actual C. Each of the primitives has a tiny bit.
Pre-compiled words are lists of addresses. Since it's still being
developed, I do have 3 to 6 "primitives" which shouldn't be implemented as
primitives ... However, I haven't rewritten them as Forth yet. I'm working
on it, but it is delayed until I fix the other issues.

> Believe me, I know a lot more about Forth compiler-
> writing than you do.

Since this is my first ever, I'd say that is probably true. But, I'm adept
with C (and GP x86 instructions). I've implemented the ITC interpreter in
C. I'm not coding a compiler for Forth in C. After implementing an ITC
interpreter, it's just a matter of implementing a Forth word set either as
arrays of addresses (pre-compiled high-level words), as primitives
(pre-compiled low-level words in C), or as text (for parsing). I've already
implemented roughly 136 words. Does my interpreter have a ways to go? Yes,
quite a bit, IMO. I've still got too much C side code. But, it's
progressively getting there, to my goals. As mentioned above, I broke a few
words. I also converted to line-oriented parsing from word-by-word. That
introduced a few more problems. I don't "see" any of these as something
critical. They just require my time.

> I have also told you several times that it is a
> good idea to write at least one small application
> in Forth before delving into Forth compiler-writing,
> in order to first learn the rudiments of the language
> from a user's perspective.

That may introduce some inherent bias. ISTM, that Charles Moore followed a
path very similar to the process I'm going through, but for different
machines and languages. Many of the "mystery comments" one reads about
Forth from CM, CH Ting, etc make sense now.

> The world is already full of people who claim to be
> great experts at Forth because they have written
> an interpreter for Forth

You mean Anton Ertl. Something seriously gets lost when he translates
to/from English. He seems to think if one does not have a degree then one
is not smart or can't understand what he knows, or he just doesn't like
justifying his claims. IRL, I know a few PHDs from HS who aren't as smart
as I am. Lack of a degree doesn't affect your intellect. It will affect
your pocket book and your exposure to experiences for which a degree is
needed, i.e., guys paid to drive taxi cabs are not being paid to solve
programming problems, foregone experiences ...

> (usually in C, but it has even been done in Perl)

...

> [...] but who in the next breath will state that

> Forth is grossly inefficient, ugly and unreadable,

Well, that is true. At least, that's my belief about the syntax chosen for
Forth. That belief has been strengthened through this process of
implementing an interpreter for Forth. Fortunately, one can discard the
Forth syntax, because there is none, and implement their own. But, no one
seems to do that ... Or, perhaps they did it too much and still called it
"Forth", and so perhaps that's why Forth got labeled "write once" ...

> [...] completely lacking in HLL features

It's as "turing complete" as any non-turing complete language
(all of them) can be. DOES> is definately a OOP like feature.

> [...] and generally worthless for application programming

I've not used it for that, but ISTM that many Forth programmers don't use
Forth in an advanced way. They prefer stack programming. Yet, it is
perfectly fine for using variables in memory. It is true that other
languages, like C, take care of many things for the programmer that Forth
does not.

> [...] --- you are well on your way toward joining their ranks --- I

> can tell you upfront that nobody will care; there is no point in going
> through all of this effort just to make a negative contribution to Forth.

Yes, I agree that there are many things for which there is "no point", i.e.,
"re-inventing the wheel". This evolved out of another project. But, if I
needed the approval of other people, I never would've done anything in my
life. I certainly wouldn't have chosen to write a Forth interpreter with so
many of them out there, i.e., I agree there is "no point" from that
perspective. How am I to know if I'm going to have time to complete it?
How am I to know if I'll release it someday or sell it or if it'll become
part of the property of a company or if I'll keep it private? How am I to
know if it'll be used if released to the public? There are too many
unknowns for you to sit around and not do something because there is "no
point". At some point, you must do something that has a point, even if it
leads you to a "no point" situation.

> You currently know as much about HLA as you do about Forth,
> which is something close to nothing.

I've seen enough of it's syntax. I know it's not an assembler.

> All of you guys' responses to my question about the MOV(dummy,[ebp]);
> instruction have been comparable to the above --- informed by
> ignorance, driven by arrogance and successful at nothing! I asked a
> straight question about how to assemble a particular addressing-mode
> in HLA, and I never got a straight answer --- if you guys are in doubt
> about the answer to any question that I may ask, please don't hesitate
> to shut the hell up.

Did I state that you were likely missing a size related keyword? (yes)

Did Nathan post the correct sequence? (yes)

> I'm not championing HLA; I'm still a complete novice at it --- [...]

> whether this was a good choice or a bad choice, isn't really
> anybody's business except my own.

Apparently, you made your choice. So, why did you take offense to some of
us not liking HLA? But, if you don't need "OOP and thunks and generators
within this context," as you stated, why not use a real assembler, without
that stuff, perhaps NASM?


Rod Pemberton

[Hugh Aguilar]

On Dec 4, 9:43 pm, "Nathan Baker" <nathancba...@gmail.com> wrote:
> "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message

> All of you guys' responses to my question about the MOV(dummy,[ebp]);
> instruction have been comparable to the above --- informed by
> ignorance, driven by arrogance and successful at nothing! I asked a
> straight question about how to assemble a particular addressing-mode
> in HLA, and I never got a straight answer --- if you guys are in doubt
> about the answer to any question that I may ask, please don't hesitate
> to shut the hell up.
> -->
>
> Oh, please calm down.  I gave you the correct answer.  Sorry if it got
> hidden in all the rabble-babble.  The correct syntax you are looking for is:
>
> mov( dummy, (type uns32 [ebp]) );

Okay, that worked --- thanks.

I had already tried putting the UNS32 in front of [EBP] but had not
put in the TYPE. I pretty much knew that I had to provide type
information of some kind because otherwise the assembler doesn't know
if [EBP] is a 32-bit dword or a 64-bit qword or whatever. It could
even be a 16-bit word, in which case the value would get truncated.
This would be true of any assembler --- I just didn't know how to do
it.

Learning any new language is a time-consuming process. I routinely get
dozens of error messages. Even when my code assembles and works
correctly, it is usually no good and has to be rewritten because it is
ugly and fails to use the language's features appropriately. That is
just the way that it goes. A person has to write programs in order to
be a programmer --- there is no way to avoid these kinds of problems,
although it does get easier with time.

The script kiddies do avoid these problems by pasting together blocks
of source-code that have already been tested by somebody else, but I
don't consider that to be programming.

> Welcome to ALA!  ;)

Thanks.

I got somewhat riled up --- I apologize for overreacting.

I get very annoyed at judgmental people. When Rod says that HLA isn't
an assembly language, that implies that I'm not an assembly language
programmer. I've actually been programming in various assembly
languages since the 1980s, but he would take my assembly-language card
away from me now because I am writing a program in HLA. I can imagine
myself saying: "But, but, I didn't even use most of HLA's features!"
Then everybody says: "It doesn't matter; the high-level features were
available whether you used them or not, so you are no longer an
assembly-language programmer!" This is similar to how people in
American nowadays get practically crucified for drunk driving. If they
complain that they didn't harm anybody, they are told that they have
to be punished for what could have happened (a trail of squashed
pedestrians), and that what did happen (nothing) is irrelevant. Its a
thought crime.

Rod complained that HLA wasn't similar enough to C to be useful as an
inline-assembly language for C compilers. That would only make sense
if Randy Hyde had intended HLA to be C-like and had failed in his
effort. There is no evidence to indicate that this is true, however.
As far as I know, there is no law that says that every language has to
be as similar as possible to C. I heard the same nonsense from the
Forth-200x committee. They said that my ALLOCATION word couldn't be
part of Forth-200x (it provides the size of the allocated memory block
given the block's address) because GLIBC doesn't have this feature and
they want GFORTH (written in C) to be Forth-200x compliant, and even
for assembly-language Forths they want to use the heap in GLIBC rather
than write their own heap --- this is despite the fact that
implementing a heap isn't particularly difficult --- this is
especially true on micro-controllers that don't have a data cache, but
it is not all that difficult even on the x86 that does do caching.

[Hugh Aguilar]

On Dec 5, 5:08 pm, "Nathan Baker" <nathancba...@gmail.com> wrote:
> "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message

>
> news:98bd4be2-44ac-42d1...@l24g2000yqm.googlegroups.com...
>
> <<<
> I could have chosen FASM and NASM instead --- I
> primarily chose HLA because it has a library supporting console-mode
> programs that can assemble for either Windows or Linux without any
> change to my source-code
>
>
>
> As the following example demonstrates, one can just as easily hijack the C
> stdlib to handle seemless cross-platform I/O.

I wasn't aware that GCC worked under Windows. I thought it only worked
under Linux and BSD and so forth. This definitely makes GCC more
interesting.

Does the library support moving the cursor to specific locations on
the screen and printing text or obtaining input there? What I remember
from C is that the library only supported scrolling text as used in a
command-line environment (like what GFORTH does). That wouldn't be
adequate for a text editor and/or IDE. Is there a Windows version of
NCURSES? So long as there is a terminal emulation program available,
this should work.

My goals are pretty pedestrian. I want to have an IDE and editor,
which GFORTH lacks, but I don't want to get involved in GUI
programming (too complicated for me to learn). A possibility though,
is to put the IDE on top of SciTE or Eclipse or some such thing. I'm
not even close to starting work on the IDE though, so this is all a
future consideration. I haven't given much thought to the subject at
this time.

[Nathan]

On Dec 5, 9:31 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
>
> I wasn't aware that GCC worked under Windows. I thought it only worked
> under Linux and BSD and so forth. This definitely makes GCC more
> interesting.
>

I believe that MinGW is a direct port:
http://www.mingw.org/

And then there are projects like Cygwin that provide a Linux-like
environment:
http://www.cygwin.com/

> Does the library support moving the cursor to specific locations on
> the screen and printing text or obtaining input there? What I remember
> from C is that the library only supported scrolling text as used in a
> command-line environment (like what GFORTH does). That wouldn't be
> adequate for a text editor and/or IDE. Is there a Windows version of
> NCURSES? So long as there is a terminal emulation program available,
> this should work.
>

I suspect that you would have to use Cygwin (or something heavier) for
NCURSES-like functionality.

> My goals are pretty pedestrian. I want to have an IDE and editor,
> which GFORTH lacks, but I don't want to get involved in GUI
> programming (too complicated for me to learn). A possibility though,
> is to put the IDE on top of SciTE or Eclipse or some such thing. I'm
> not even close to starting work on the IDE though, so this is all a
> future consideration. I haven't given much thought to the subject at
> this time.

You should talk with Sevag Krikorian. He used HLA to construct an IDE
for HLA:

http://sites.google.com/site/highlevelassembly/downloads/hide

Nathan.

[Rod Pemberton]

"Hugh Aguilar" <hughag...@yahoo.com> wrote in message

news:8fd6a587-fd81-4a8f...@x7g2000yqb.googlegroups.com...

>
> I get very annoyed at judgmental people.
>

So said one of the most judgemental people around ..

> When Rod says that HLA isn't an assembly language, that
> implies that I'm not an assembly language programmer.

No, it means you're not programming assembly using an assembler. You're
programming assembly using an HLL. If you coded an assembler in Forth
and you used it, I'd say the same thing. It's syntax, method of
programming, etc are all different from an actual assembler like MASM,
NASM, or GAS.

> I've actually been programming in various assembly
> languages since the 1980s, but he would take my assembly-language
> card away from me now because I am writing a program in HLA.

Wow, I don't know what to say to that ... Seek help? I.e., why is your
self-worth apparently based on what your perceptions of what others are
"implying" about you? Are you hyper-extroverted? Overly empathic?

> This is similar to how people in
> American nowadays get practically crucified for drunk driving.
> If they complain that they didn't harm anybody, they are told that
> they have to be punished for what could have happened (a trail of
> squashed pedestrians), and that what did happen (nothing) is
> irrelevant. Its a thought crime.

Since pedestrians frequently are killed by drunk drivers but almost never by
sober drivers, it seems correct to me to classify them as a direct threat to
pedestrians.

> Rod complained that HLA wasn't similar enough to C to be useful
> as an inline-assembly language for C compilers.

complained vs. stated ...

> That would only make sense if Randy Hyde had intended HLA
> to be C-like and had failed in his effort.

What? So, my statements only make sense, if they somehow fit into
Randall's reality? What if he's insane? That's just warped ...

> There is no evidence to indicate that this is true, however.
> As far as I know, there is no law that says that every language
> has to be as similar as possible to C.

You're correct that nothing has to resemble C. Forget about the fact that C
and Forth are the two most widespread and used languages, albeit C is far
more "popular." My point was that HLA would have some value if it had a
purely C syntax, i.e., as an inline assembler. RH, in old conversations you
weren't part of, frequently described HLA as a being a "teaching tool" for
assembly. That's it's purpose: teaching tool. Since HLA is not an
assembler, it doesn't actually teach assembly concepts. It teaches HLL
programming concepts. If you learned assembly with HLA, you won't be able
to use MASM, NASM, or GAS ...

> I heard the same nonsense from the Forth-200x committee. They
> said that my ALLOCATION word couldn't be part of Forth-200x
> (it provides the size of the allocated memory block given the
> block's address) because GLIBC doesn't have this feature and
> they want GFORTH (written in C) to be Forth-200x compliant,
> and even for assembly-language Forths they want to use the heap
> in GLIBC rather than write their own heap --- this is despite the fact
> that implementing a heap isn't particularly difficult --- this is
> especially true on micro-controllers that don't have a data cache, but
> it is not all that difficult even on the x86 that does do caching.

I know that what you keep claiming they said (on c.l.f.), but I don't what
they said, nor care ...

> (it provides the size of the allocated memory block given the
> block's address)

That is something that isn't supported in C. It's OS dependent. I can
easily assume that the Forth-200x committee - which has the job of
abstracting Forth from the underlying implementation - wouldn't want to
introduce that feature to Forth for the same reason.


Rod Pemberton

[Rod Pemberton]

"Hugh Aguilar" <hughag...@yahoo.com> wrote in message

news:f4445f23-7afa-4b46...@4g2000yqu.googlegroups.com...

>
> I wasn't aware that GCC worked under Windows. I thought it only
> worked under Linux and BSD and so forth. This definitely makes
> GCC more interesting.

No, it doesn't. That's only half the picture.

The ports (MingW, Cygwin, DJGPP) are just fine for developing your own
applications within their environments. I use DJGPP alot. However, they're
limited in their ability to compile code available for Linux. AIUI, the
ports of GCC (Mingw, Cygwin, DJGPP) use their own custom libraries instead
of GLIBC. AFAIK, GLIBC has never been fully ported to a non-Linux
environment. Unfortunately, to properly compile the Linux applications
you're likely to need, you'd need *both* GCC and GLIBC. Without a properly
implemented GLIBC, applications like Linux 'fdisk' and commands like 'dd'
won't work. They need direct device access.

> Does the library support moving the cursor to specific locations on
> the screen and printing text or obtaining input there? What I remember
> from C is that the library only supported scrolling text as used in a
> command-line environment (like what GFORTH does). That wouldn't be
> adequate for a text editor and/or IDE. Is there a Windows version of
> NCURSES? So long as there is a terminal emulation program available,
> this should work.

C doesn't support positioning text. Yes, ncurses or pdcurses or other TUIs
should be available for whatever C compiler you choose. You aren't
restricted to GCC based compilers on x86. You can use others like
OpenWatcom, LCC based (PellesC, LCC-Win32), Ladsoft, etc.


Rod Pemberton

[Hugh Aguilar]

I have another question about HLA, if anybody cares to take a swipe at
it:

Is there something like ENUM available except that instead of running
through the sequence 0,1,2,3,etc., it runs through the sequence:
1,2,4,8,etc.? This would be for defining flag-masks all unique.

Presumably this could be written in HLA's much ballyhooed CTL. I'm not
going to delay the whole project while I muck around with something
marginally useful such as this --- I'll take a shot at it later on if
there isn't anything already available --- I'll dig through the HLA
source-code and find ENUM and modify it.

[Nathan Baker]

Can't think of anything off the top of my head. However, I have a
better suggestion.

Write an HLA program that creates the enumerated list for you. Do you
know how to capture console output? It's simple -- just use the '>'
redirection operator. Example:

c:\> codegenerator.exe > program-section-1.hla

If you have an array, $Stars, containing all the labels and a variable,
$Stripes, containing the current enumeration value, then it is a simple
loop:

For each X in $Stars
Print( "Let ", $Stars[X], " = ", $Stripes, newline )
$Stripes = $Stripes + 3
End

I have used this method many times. It is especially useful for
building tables -- for instance, when coding an interpreter.

Hope that helps!

Nathan.

[Hugh Aguilar]

On Dec 7, 1:30 am, Nathan Baker <nathancba...@gmail.com> wrote:
> On 12/06/2011 10:32 PM, Hugh Aguilar wrote:
> > Is there something like ENUM available except that instead of running
> > through the sequence 0,1,2,3,etc., it runs through the sequence:
> > 1,2,4,8,etc.? This would be for defining flag-masks all unique.
>
> > Presumably this could be written in HLA's much ballyhooed CTL.

> ...

> Can't think of anything off the top of my head.  However, I have a
> better suggestion.
>
> Write an HLA program that creates the enumerated list for you.

I understand --- you are suggesting that I write a preprocessor of my
own. I think that is an excellent idea. I am actually opposed to
having the so-called CTL integrated inside of the assembler as done in
HLA. I would prefer to have the preprocessor be a separate program
written in a mainstream language such as Racket or Python or some
such. I don't understand why R.H. went to the trouble of writing his
own CTL using flex/bison when there are plenty of languages already
available that are plenty powerful, have abundant string-handling
facilities, and have the advantage of being widely known already.

Somewhat humorously, over on the FASM forum I suggested the idea that
I would write a preprocessor for FASM that would use the ^ as a tag to
pick out the preprocessor stuff from the FASM source-file, and then
generate a FASM source-file that FASM could digest --- and T.G. didn't
like that idea at all! He said that his built-in CTL was plenty
powerful enough for anything that I might want to do, and that I
should just learn it. I think he considered the idea of a separate
preprocessor to be a slam against his built-in preprocessor, although
I was not putting down his CTL which I know almost nothing about. He
might be right that his CTL is powerful and that I should just learn
it. I dropped FASM because I supposed that the HLA CTL would be better
(and mostly because the HLA libraries are much better), but now I'm
finding weaknesses in the HLA CTL and you are suggesting that I write
my own preprocessor, so I'm back where I started from. I never did
learn enough about the FASM CTL to know if it is powerful enough to do
what I want --- if T.G. says that it is though, then it most likely
is.

I actually like writing programs that generate source-code for other
languages. I've generated both CNC gcode and PostScript. I used Forth,
although that is not a very good language for this kind of thing --- a
more high-level language such as Racket or Python (or even HLA as you
suggest) would be more appropriate. I would think so anyway --- I
don't actually know any of these languages beyond the novice level ---
I generally just write everything in Forth because I know Forth inside-
and-out, even if it is not very appropriate for the task at hand. I've
worked in machine shops hand-writing CNC gcode for 5-axis lasers, and
I'm a big fan of the idea of generating that stuff from another
program (because hand-writing it is tedious and error-prone) --- this
idea doesn't go over well with most machinists though, as they are
proud of their ability to hand-write gcode, and they don't want to
learn Scheme or Python or Forth or anything else.

[Nathan]

On Dec 7, 7:18 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote:
>
> I understand --- you are suggesting that I write a preprocessor of my
> own. I think that is an excellent idea. I am actually opposed to
> having the so-called CTL integrated inside of the assembler as done in
> HLA. I would prefer to have the preprocessor be a separate program
> written in a mainstream language such as Racket or Python or some
> such. I don't understand why R.H. went to the trouble of writing his
> own CTL using flex/bison when there are plenty of languages already
> available that are plenty powerful, have abundant string-handling
> facilities, and have the advantage of being widely known already.
>

Well, the one "Achilles heel" of the CTL is that it is difficult to
debug. You never get to see the generated code. Trail-breakers like
Randy and Sevag have used it a good bit, but they also have a great
deal of experience with HLA itself. Also, if you browse the source of
their projects, you will see that they also sometimes rely on one-off
code generators when it simply makes sense to do so.

> Somewhat humorously, over on the FASM forum I suggested the idea that
> I would write a preprocessor for FASM that would use the ^ as a tag to
> pick out the preprocessor stuff from the FASM source-file, and then
> generate a FASM source-file that FASM could digest --- and T.G. didn't
> like that idea at all! He said that his built-in CTL was plenty
> powerful enough for anything that I might want to do, and that I
> should just learn it. I think he considered the idea of a separate
> preprocessor to be a slam against his built-in preprocessor, although
> I was not putting down his CTL which I know almost nothing about. He
> might be right that his CTL is powerful and that I should just learn
> it. I dropped FASM because I supposed that the HLA CTL would be better
> (and mostly because the HLA libraries are much better), but now I'm
> finding weaknesses in the HLA CTL and you are suggesting that I write
> my own preprocessor, so I'm back where I started from. I never did
> learn enough about the FASM CTL to know if it is powerful enough to do
> what I want --- if T.G. says that it is though, then it most likely
> is.
>

Well, using someone's CTL means you are confined to their design goals
and are somewhat reliant on them to fix any bug you might discover in
it. You only have to fight yourself if you make your own tool.

> I actually like writing programs that generate source-code for other
> languages. I've generated both CNC gcode and PostScript. I used Forth,
> although that is not a very good language for this kind of thing --- a
> more high-level language such as Racket or Python (or even HLA as you
> suggest) would be more appropriate. I would think so anyway --- I

Some languages are difficult to write an auto-gen for. Python, for
instance, makes 'white space' syntactically meaningful. Keeping the
indention at the proper hierarchy level can become painful in complex
code.

Nathan.

[Hugh Aguilar]

On Dec 7, 9:41 pm, Nathan <nathancba...@gmail.com> wrote:
> Well, the one "Achilles heel" of the CTL is that it is difficult to
> debug.  You never get to see the generated code.

HLA does have an option of generating pseudo-HLA (HLA can't compile
it, but it looks like HLA so you can see what your macros generated).
Also, it is possible to make HLA generate FASM, NASM etc., as an
intermediate source-file that is then assembled to generate the object
file, rather than have HLA generate the object file directly. HLA
apparently started out as a preprocessor for NASM, but then got
upgraded to be an assembler in its own right.

None of this matters to me though. I have no intention of becoming an
HLA expert by boosting HLA's capability with my own preprocessor and/
or learning the intricacies of HLA's CTL. In my experience, what makes
debugging easy is interactive development --- that is why I'm writing
a Forth system --- the capability of the language only helps in
simplifying complicated programs, which only indirectly helps to make
debugging easier. Productivity is mostly boosted by giving the
programmer an interactive development system --- that is why people
like Forth (it definitely isn't for the efficiency, which is usually
horrible).

Also, I'm not interested in HLA because it is limited to the x86 ---
I'm interested in micro-controllers such as the ARM and TMS430 and so
forth. The whole point of this Forth system is to be a platform for a
Forth cross-compiler. The world doesn't really need another Forth
compiler for the x86, or actually another compiler for any language
for the x86 --- micro-controllers are the only interesting kind of
programming remaining --- nobody cares about desktop software, which
is almost always given away for free (as in free beer). I'm not an
altruist though --- it is not my job to provide the world with free
software, or free cab rides.

> Some languages are difficult to write an auto-gen for.  Python, for
> instance, makes 'white space' syntactically meaningful.  Keeping the
> indention at the proper hierarchy level can become painful in complex
> code.

You are thinking of a Python program that contains function calls that
generate assembly source-code. I was thinking of the opposite --- an
assembly program that contains tags (marked by ^ or some other unused
character) that the preprocessor program picks out and expands.

What I'm thinking of is similar to frameworks such as Ruby on Rails or
Pylons. In those systems, you write HTML that has tags that the
framework picks out and expands. They do it this way because there is
generally a lot more HTML than high-level code, and people are already
familiar with HTML. Similarly, there is generally a lot more plain
assembly-language than macro calls, and people are already familiar
with assembly-language (FASM or whatever). I have never actually done
any website programming, but I am aware of the concept of a framework,
which I would bring to assembly-language programming. In this case,
the indentation of the high-level language doesn't really interfere
with the indentation of the assembly-language program because the only
high-level code that appears in the assembly-language program are
function calls to high-level macros, and they are one-liners.

[Rod Pemberton]

"Hugh Aguilar" <hughag...@yahoo.com> wrote in message

news:d8e2f35d-861d-47fa...@t38g2000yqe.googlegroups.com...

>
> HLA apparently started out as a preprocessor for NASM, but
> then got upgraded to be an assembler in its own right.
>

AIR, NASM has had it's own C like preprocessor and macro system
from the start.

For him to do that, that would seem "pointless" wouldn't it? ;-)


Rod Pemberton

[Rod Pemberton]

"Hugh Aguilar" <hughag...@yahoo.com> wrote in message

news:f28d48e4-9e1e-4777...@l19g2000yqc.googlegroups.com...

>
> Somewhat humorously, over on the FASM forum I suggested the idea that
> I would write a preprocessor for FASM that would use the ^ as a tag to
> pick out the preprocessor stuff from the FASM source-file, and then
> generate a FASM source-file that FASM could digest --- and T.G. didn't
> like that idea at all! He said that his built-in CTL was plenty
> powerful enough for anything that I might want to do, and that I
> should just learn it.
>

Well, yes, you should learn the macro system of whatever assembler(s) you
decide to use. If you plan to use many, keep your usage simple so you can
port it easily. Most macro systems have the same basic functionality.

Does he think the basic idea is a bad idea or a bad idea because CTL is
available?

The basic idea of using a 'tag' character to delimit preprocessor commands
is sound and proven. C uses the '#' to delimit preprocessor lines. The
idea of using an escape character to switch from one interpreter to another
has been used in the past too. I once programmed a BASIC that had a
character which switched to another interpreter for industrial machine
control in late '90's. BASIC was used for editing, keyboard input, screen
output, saving and loading of program files. A different syntax with an
escape was used to perform the machine specific operations. I also read
about the same idea in the late '80's where it was called a 'wedge'. The
escape character 'wedged' between the host and extended interpreter. In
this case, the extended interpreter extended the BASIC language for the C64
by adding a number of commands. Personally, I mix ASCII character 'markers'
with code to reduce parsing complexity, i.e., a C switch(character)
eliminates much parsing. You don't have to identify what the text is that
follows. Such usage probably has a formal name. I don't know what it is.
I call it 'character directed parsing' or 'syntax directed parsing'. E.g.,
you can see how I use it for an in-progress assembler of mine in this post:

http://groups.google.com/group/alt.os.development/msg/705dd0a24cfe9bb5


Rod Pemberton

[Frank Kotler]

Rod Pemberton wrote:
> "Hugh Aguilar" <hughag...@yahoo.com> wrote in message
> news:d8e2f35d-861d-47fa...@t38g2000yqe.googlegroups.com...
>> HLA apparently started out as a preprocessor for NASM, but
>> then got upgraded to be an assembler in its own right.
>>
>
> AIR, NASM has had it's own C like

? Not that C-like... IMO.

> preprocessor and macro system
> from the start.
>
> For him to do that, that would seem "pointless" wouldn't it? ;-)

:)

Actually, Hugh is confused. HLA was originally a preprocessor
("preparser", according to Betov) for Masm/Tasm... which had its own
macro system, but it didn't suit Randy. Any Nasm support has been quite
recent. Last I tried it, the Linux version still didn't have it, and
didn't produce (correct) ELF object format without assistance from (G)as
- so it's still a "preparser"! :)

Best,
Frank

[Hugh Aguilar]

On Dec 8, 12:35 pm, Frank Kotler <fbkot...@myfairpoint.net> wrote:
> Actually, Hugh is confused. HLA was originally a preprocessor
> ("preparser", according to Betov) for Masm/Tasm...

That is true. I reread his discussion and he said that he started out
using MASM for "Art of Assembly Language" but wrote HLA as a
preprocessor because MASM wasn't up to what he wanted.

I programmed in MASM/TASM back in MS-DOS days and I never did figure
out all of those directives --- I just cut and paste that stuff in as
boilerplate --- so my programs only used very simple memory-models.
Later on I switched to A86 which I liked a lot better, although I was
still using very simple memory-models. NASM is a fairly new project,
and FASM is even yet newer. Memory models don't matter now.

I remember going into a small computer store, picking up a shrinked-
wrapped box containing Turbo Assembler and Turbo Debugger on a stack
of 3.5" disks along with a stack of yellow-cover manuals, and paying
$80 for it (a discount, as the store was clearing that stuff out).
That world no longer exists. R.H. or T.G. could put their assemblers
in shrink-wrapped boxes along with printed manuals, and there wouldn't
be any store in the world that would carry them. Desktop software is
mostly just given away for free, except for games which are still sold
in shrink-wrapped boxes (and don't need a manual). Programming desktop
computers is a service industry now. People write software, usually in
Java, that supports some industry such as health-care insurance
billing --- they are pretty much glorified clerks --- I did something
similar when I was working as an IBM370 assembly-language programmer,
cranking out programs to process customer data for direct mail and for
banking.

There is still money in micro-controllers, but it is the hardware that
is being sold not the firmware --- the firmware is usually not
complicated enough that it couldn't be duplicated easily by any
programmer off the street --- people make money because they can
produce the boards, but they are competing solely on their ability to
produce boards cheaply and quickly, not on the gee-whiz aspect of what
the board does. Being first to market is largely what it is all about.

None of this matters to me though --- I'm writing a Forth development
system, not a history book. It is mostly just a hobby --- I don't
really have much expectation of ever making any money. Richard
Stallman has won --- we are all communists now, standing in the soup
line talking about assembly-language programming. Who is John Galt?