Re: HLA and embedded controllers

Betov wrote:

There is no *need* for providing code to directly expand the macros
inside the assembler, other than it is faster to do it that way, you
can generate better code, and the result is more robust. That's why
it's better to do this inside the assembler rather than in the
interpretive macro language.

Translation: "There is no need of implementing such a difficult
thing as a macros parser, in an Assembler because it can be done
way easier and faster in HLL".

I guess you haven't read about how to do this in AoA, have you?

It's actually quite easy when you've got a powerful macro system such
as the one HLA possesses. But even so, the version built into HLA is
going to be faster, generate better code, and be more robust.

If so, why is your HL Pre-Parser so slow, clown?

I don't know what a "HL Pre-Parser" is, but if you're refering to my
assembler, HLA, I'd hardly call it "slow". Let's see, in my HLA
directory I have the following files:

c:\hla>dir *.hla
Volume in drive C has no label.
Volume Serial Number is 8CD0-466B

Directory of c:\hla

06/25/2006 08:44 PM 3,919 99bottles.hla
01/30/2004 03:20 PM 16,545 bm.hla
06/25/2006 02:58 PM 157 htest.hla
05/20/2006 05:02 PM 1,001 htestunit.hla
05/10/2006 07:12 AM 2,609 instrTest.hla
10/16/2003 11:38 AM 2,228 PatchRadASM.hla
11/14/2005 05:33 PM 13,571 stldemo.hla
10/31/2006 11:01 AM 155 t.hla
01/23/2006 08:26 AM 106,688 term.hla
06/03/2006 07:08 AM 1,018 u.hla
06/28/2006 07:02 AM 3,719 v.hla
11 File(s) 151,610 bytes
0 Dir(s) 64,463,450,112 bytes free

"term.hla" looks to be a pretty good size, let's try compiling that and
see how long it takes:

c:\hla>hla -v term.hla
HLA (High Level Assembler)
Released to the public domain by Randall Hyde.
Version Version 1.87 build 8966 (prototype)
Win32 COFF output
Using MASM assembler
MASM output
-test active

HLA Lib Path: c:\hla\hlalib\hlalib.lib
HLA include path: c:\hla\include
HLA temp path:
Linker Lib Path: c:\hla\hlalib;c:\hla\hlalib;c:\hla\hlalib

1: term.hla

Compiling 'term.hla' to 'term.asm'
using command line [hlaparse -v -sm -test "term.hla"]
HLA (High Level Assembler) Parser
Released to the public domain by Randall Hyde.
Version Version 1.87 build 8962 (prototype)
-t active
File: term.hla
Output Path: ""

Compiling "term.hla" to "term.asm"
Compilation complete, 18892 lines, 0.267 seconds, 70757

Oh my! Nearly 19,000 lines of code compiled in 0.267 seconds, at an
assembly rate of better than 70,000 lines/second (2.7 GHz PIV). That's
just *PATHETICALLY SLOW*, I must agree :-)

Granted, some other assemblers are faster, but HLA compiled this
program almost faster than I could react to it, so who really cares if
it could have been done in 0.15 seconds instead?

Of course, you've never really used HLA so you really don't have any
idea about how fast or slow it really is. Indeed, your whole notion of
HLA's speed comes from the posting of Paul Pank's adventure game
problems where he called a 600-line macro over 2,500 times in his
source code. And as that macro wasn't written very well back then (it's
been modified so that it compiles about 10x faster today), that's
hardly a good metric. But nonetheless, it proves the point in question
-- the reason for not using macros for common things like the HLL-like
statements is that macros are always much slower than compiled code.
And as I mentioned, they're also less robust and you can't always
generate as good of code as you can inside the assembler itself.

What's absurd is that you think think this is absurd. :-)
The whole point of macros is to hide things. Look up the definition
for "abstaction" some time.

Look up the definition of the word "Assembler" some time.

An assembler is a compiler for an assembly language. Your point?
Randy Hyde