abusing macros, was Re: Writing a simple assembler
toby
> toby wrote:
>
> > Alex wrote:
> >
> >>First, I would like to thank everyone for a response and advice.
> >>
> >>Second - the purpose was to write a simple assembler in order to generate
> >>an op code on a PC
> >>and then run it on my IC (fpga is used as a host controller).
> >>I understand that the task is trivial for gurus, but being a novice in
> >>this thing first thing that came to
> >>my mind was simply to make two passes: first - preprocessor, detects all
> >>the variables etc., second actual
> >>translation - recognising mnemonics and generate an opcode . Obviously it
> >>is not a "proper" way to do it
> >>(grammar descriptions and so on..). That's why I was asking about some
> >>examples and articles about this issue.
> >
> >
> > It can be argued that since you are in learning mode there is no
> > 'wrong' way to go about it. Go forth and build your prototype; doing so
> > is a great way to learn about languages and tools that might be related
> > or make the task easier. :)
>
> Total agreement. In the total time spent
> posting on this thread, a simple assembler
> could have been written and debugged :)
>
> Myself, I'd just define some macros for
> MASM, the old Microsoft DOS assembler.
Hi Jim,
Now that is a technique I have heard of before! A gentleman Tom Evans
clued me into this, and I hope he will allow me the liberty of quoting:
There's two ways to "write an assembler in Macro 11".
The IMP/PACE one I mentioned was "the classic version". It had
the parser, symbol table management and everything, all lovingly
coded in individual machine instructions. Lots of them. How
redundant...
The SC/MP cross assembler (and other ones I've worked on ...
that generated microcode) consisted of MACROS.
This is cheating big-time. The Macro-11 assembler is being abused
to assemble and emit code for a different CPU, or sometimes not
even for a CPU but for a ROM Sequencer or worse. The macros have
the same names as the target CPU's op-codes and they simply
generate the appropriate code, (ab)using the symbol table
management built into Macro-11.
As a huge benefit you can also use all of the powerful macro
facilities in Macro-11. Try emulating all of that in lex/yacc.
Of course if the targeted CPU uses opcodes with the same names as
the ones the PDP-11 uses there's a bit of strife, ...
Macro-11 isn't exactly fast when abused like this. It took about
5 minutes to make [a] 1023-byte ROM ...
Kids these days have it easy! Lex! Yacc! Puts me in mind of:
http://www.phespirit.info/montypython/four_yorkshiremen.htm
"SECOND YORKSHIREMAN:
Luxury. We used to have to get out of the lake at six o'clock in
the morning, clean the lake, eat a handful of 'ot gravel, work twenty
hour day at mill for tuppence a month, come home, and Dad would thrash
us to sleep with a broken bottle, if we were lucky!"
--Toby
Jonathan Kirwan
Macro-11 is pretty good and I've read exactly these cases, back in the
1970's when I was using Macro-11. I never wrote Macro-11 code for a
cross-assembler, though. Just heard about it.
I've actually used MASM/ML from Microsoft for such things, though.
From my vague recollection of Macro-11 macros, MASM/ML's macro
facilities aren't nearly as general and can be confusing to figure
out, at times. But the linker will actually punch out a .COM file,
which is a clean, exact, binary image. MASM/ML will allow you to
place things in separate segments so that you can, on the fly, place
things into nicely organized sections which will later be fused
together as you see fit. (You can generate a .EXE, but you will need
another tool to 'fix' it up.)
Jon
Roger Ivie
> The SC/MP cross assembler (and other ones I've worked on ...
> that generated microcode) consisted of MACROS.
>
> This is cheating big-time. The Macro-11 assembler is being abused
> to assemble and emit code for a different CPU, or sometimes not
> even for a CPU but for a ROM Sequencer or worse. The macros have
> the same names as the target CPU's op-codes and they simply
> generate the appropriate code, (ab)using the symbol table
> management built into Macro-11.
I haven't done this with either MACRO-11 or MASM, but I have done it a
few times with MACRO-32.
First time was for FQAM, the QBus adapter for the VAXstation 3520/3540.
It was built around a simple state machine implemented with registered
EPROMs.
Currently, I'm using a set of MACRO-32 macros that let me migrate
microcode assembly for a 2910/29116 based system off an old META29R
setup that required a VAX onto an Alpha using MACRO-32. I've managed to
retain all the original mnemonics used in the META29R code and quite a
bit of the syntax. This let me do automated source code conversion
between the two assemblers, which was nice.
The result is a .PSECT containing an initialized array that I link
against a FORTRAN program to extract the binary in a variety of formats.
> Macro-11 isn't exactly fast when abused like this. It took about
> 5 minutes to make [a] 1023-byte ROM ...
Neither is MACRO-32. It took a MicroVAX 2000 half an hour to assemble
the microcode for the FQAM.
--
roger ivie
ri...@ridgenet.net
rand...@earthlink.net
toby wrote:
> >
> > Myself, I'd just define some macros for
> > MASM, the old Microsoft DOS assembler.
>
> Hi Jim,
>
> Now that is a technique I have heard of before! A gentleman Tom Evans
> clued me into this, and I hope he will allow me the liberty of quoting:
>
Having a good compile-time language (macro processor plus other
goodies) in an assembler is useful for creating all kinds of different
languages, not just assemblers. Interested individuals might want to
take a look at my chapter on "Domain Specific Languages" in "The Art of
Assembly Language" where it discusses how to use HLA's macros and
compile-time language to create "mini-languages". Certainly, an
assembler would be fairly trivial to write. Indeed, I'm using this
technique to create a small assembler for a virtual machine I've
created to help with some object code obfuscation.
Cheers,
Randy Hyde
Jonathan Kirwan
<rand...@earthlink.net> wrote:
I was hoping you'd pop in on this.
Jon
CBFalconer
> toby wrote:
>>>
>>> Myself, I'd just define some macros for
>>> MASM, the old Microsoft DOS assembler.
>>
>> Evans clued me into this, and I hope he will allow me the liberty
>> of quoting:
>
> Having a good compile-time language (macro processor plus other
> goodies) in an assembler is useful for creating all kinds of
> different languages, not just assemblers. Interested individuals
> might want to take a look at my chapter on "Domain Specific
> Languages" in "The Art of Assembly Language" where it discusses
> how to use HLA's macros and compile-time language to create
> "mini-languages". Certainly, an assembler would be fairly trivial
> to write. Indeed, I'm using this technique to create a small
> assembler for a virtual machine I've created to help with some
> object code obfuscation.
This, with different assemblers, linkers, etc. was precisely the
path I took for the first version of machine code generation (as
opposed to pcode generation) from PascalP. The result worked,
generated excessively bloated code, but verified the ideas. I then
wrote a proper code generator, which greatly improved speed,
register assignments, bloat, etc.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Paul Keinanen
>
> This is cheating big-time. The Macro-11 assembler is being abused
> to assemble and emit code for a different CPU, or sometimes not
> even for a CPU but for a ROM Sequencer or worse. The macros have
> the same names as the target CPU's op-codes and they simply
> generate the appropriate code, (ab)using the symbol table
> management built into Macro-11.
>
> As a huge benefit you can also use all of the powerful macro
> facilities in Macro-11. Try emulating all of that in lex/yacc.
At least RSX-11 also contained a nice table driven parser (TPARS) in
the run time library. Macros were used to define the state tables with
all the various transitions.
This parser was initially intended for command line parsing, but it
was so versatile that I wrote a cross assembler (for a strange 20 bit
test instrument processor). This cross assembler was then used to
write a Basic interpreter for that 20 bit processor. The parsing
tables became quite complex, due to the oddities of the target
processor.
The TPARS was also useable for parsing simple high level languages:-).
Paul
Everett M. Greene
And then there are meta-assemblers that can generate code
for any processor...
ArarghMai...@not.at.arargh.com
<jki...@easystreet.com> wrote:
<snip>
>> This is cheating big-time. The Macro-11 assembler is being abused
>> to assemble and emit code for a different CPU, or sometimes not
>> even for a CPU but for a ROM Sequencer or worse. The macros have
>> the same names as the target CPU's op-codes and they simply
>> generate the appropriate code, (ab)using the symbol table
>> management built into Macro-11.
>>
<snip>
>
>Macro-11 is pretty good and I've read exactly these cases, back in the
>1970's when I was using Macro-11. I never wrote Macro-11 code for a
>cross-assembler, though. Just heard about it.
>
>I've actually used MASM/ML from Microsoft for such things, though.
>From my vague recollection of Macro-11 macros, MASM/ML's macro
>facilities aren't nearly as general and can be confusing to figure
>out, at times. But the linker will actually punch out a .COM file,
>which is a clean, exact, binary image. MASM/ML will allow you to
>place things in separate segments so that you can, on the fly, place
>things into nicely organized sections which will later be fused
>together as you see fit. (You can generate a .EXE, but you will need
>another tool to 'fix' it up.)
Way back in the 70's I wrote a series of macros for 360 ASM F to cross
compile object for a IBM 705. The cute part is the the 705 was a
character machine, some what like a 14xx. Which meant that the binary
addresses from the symbol table had to be converted to 4? 5? character
leading zero strings. I have forgotten most of the details by now.
--
ArarghMail603 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the garbage from the reply address.
Walter Banks
in PDP11 macro's. It didn't set any speed records. I think about 45
minutes to assemble 12K of code. It was enough to implement a
Daisy Wheel printer controller. The prototype is still around the office
in case someone needs a typewriter that actually hits the paper with a
hammer.
Macro 11 was a nice piece of software
w..
toby wrote:
> Hi Jim,
>
> Now that is a technique I have heard of before! A gentleman Tom Evans
> clued me into this, and I hope he will allow me the liberty of quoting:
>
> There's two ways to "write an assembler in Macro 11".
>
>
rand...@earthlink.net
CBFalconer wrote:
>
> This, with different assemblers, linkers, etc. was precisely the
> path I took for the first version of machine code generation (as
> opposed to pcode generation) from PascalP. The result worked,
> generated excessively bloated code, but verified the ideas. I then
> wrote a proper code generator, which greatly improved speed,
> register assignments, bloat, etc.
I don't know if "bloated" is the correct word to use here. To me,
"bloated" usually means "big". I can't imagine that either the set of
macros that did this, nor the code the macros generated, was
excessively big. OTOH, because macros are interpreted, and you've
effectively written a code generator with an interpreter, I can
certainly believe it was quite slow. Then again, I've seen assemblers
written in interpreted BASIC that weren't speed demons, either.
As for the 45 minute compile times I've seen mentioned elsewhere in
this thread, I'm not seeing that with my little "assembler written with
macros". Then again, it helps having a machine that's about 1,000 to
10,000 times faster than typical machines that MACRO-11 ran on :-)
(i.e., I'm sure HLA's performance would be worse if run on comparable
hardware).
Cheers,
Randy Hyde
Jim Stewart
These days, it's hard to imagine an assembler
that would be too slow. After all, the whole
symbol table can fit in the L1 cache with lots
of room left over (:
rand...@earthlink.net
Jim Stewart wrote:
>
> These days, it's hard to imagine an assembler
> that would be too slow. After all, the whole
> symbol table can fit in the L1 cache with lots
> of room left over (:
Until, of course, you include all the Win32 equates (all 20,000, or so,
of them).
And if your symbol table entries are a bit more complex than just a
name and a value (as is certainly true for HLA, for example) and you
tend to use long names (i.e., Win32 equates), you can use up the cache
fairly rapidly.
Oh, and don't forget, you want all the code to fit in the cache, too.
While the size of the executable code isn't a terribly great metric
(working set size, and all), fairly complex assemblers like HLA tend to
be fairly large.
While on the subject, I would also like to point out "yet another
reason not to use Flex and Bison" for assemblers-- the parsing and
lexer tables these assemblers produce are quite large. They blow away
the data cache, without even considering the effects of the symbol
table on the cache. HLA probably takes a 10x performance hit for this
very reason.
Cheers,
Randy Hyde
Jim Stewart
rand...@earthlink.net
Jim Stewart wrote:
>
> I defer to you knowledge of Win32 bloatage...
This has nothing to do with Win32 code. The problem exists under Linux
and every other OS on which Flex and Bison run. Bottom line is that
Flex and Bison generate a *lot* of table data and that obliterates the
cache compared to hand-generated parsers and lexers (at least,
well-written ones).
Cheers,
Randy Hyde
toby
rand...@earthlink.net wrote:
> Jim Stewart wrote:
> >
> > These days, it's hard to imagine an assembler
> > that would be too slow. After all, the whole
> > symbol table can fit in the L1 cache with lots
> > of room left over (:
> While on the subject, I would also like to point out "yet another
> reason not to use Flex and Bison" for assemblers--
Are you going to go into the reasons why one *would* want to use them?
Or will we leave that to others?
rand...@earthlink.net
toby wrote:
> > ...
> > While on the subject, I would also like to point out "yet another
> > reason not to use Flex and Bison" for assemblers--
>
> Are you going to go into the reasons why one *would* want to use them?
> Or will we leave that to others?
Flex and Bison are great for small prototype languages.
They might be okay for languages where you use Flex and/or Bison for
one small part of the compiler (e.g., they way they're used in GCC,
which is huge anyway). Trying to implement a compile-time language
inside a compiler written with Flex/Bison is a major pain in the butt
and it leads to all kinds of problems and restrictions on the grammar.
Let me give a classic example of a problem in HLA. HLA allows a data
declaration like the following:
static someVarName:int32;
or, it can allow a declaration like this:
static someVarName:int32; @external;
(with the obvious [I hope] effect.)
The problem is that if you follow a declaration of this sort by a
command that must be immediately executed at compile-time, you run into
some problems with Bison's one-symbol lookahead. In particular, the
compile-time statement may execute *before* the parser finishes the
declaration. This can create problems if the operation of that
compile-time statement depends upon the declaration, e.g., something
like
static someVarName:int32;
#if (@defined( someVarName)) ... #endif
Because the declaration has not finished yet, the symbol may not be
declared at the point the @defined compile-time function executes, and
@defined incorrectly returns false.
Unfortunately, you cannot (easily, anyway) merge the grammars of the
compile-time and run-time languages together. They are truly two
separate languages that the compiler must process concurrently (and the
other solution, using a preprocessor rather than a compile-time
language has an even bigger set of problems, such as lack of access to
objects declared or used in the run-time language).
Note that if you create a hand-written parser, it's easy enough to work
around problems like this. Of course, this has nothing to do with
working sets and blowing the cache away, but it is an example of some
problems I've encountered with using Flex and Bison to write a
full-blown macro assembler.
In general, assemblers have such simple grammars that using Bison for
anything other than processing arithmetic expressions is probably a
waste of time anyway. Flex can be useful, though. Nevertheless, a
Flex-generated scanner is going to be *way* bigger than most
hand-generated scanners (though the hand-generated scanner I wrote for
HLA v2.0 is far from tiny, as it was written to be fast and uses
in-line coding to implement a hash search for assembler keywords; and
that's many thousands of lines of code; fortunately, it doesn't all
execute all the time, and most of the memory it's sitting in doesn't
get touched, so you don't have the cache pollution problems you get
with Flex and Bison's tables).
Cheers,
Randy Hyde
toby
> toby wrote:
> > > ...
> > > While on the subject, I would also like to point out "yet another
> > > reason not to use Flex and Bison" for assemblers--
> >
> > Are you going to go into the reasons why one *would* want to use them?
> > Or will we leave that to others?
>
> Flex and Bison are great for small prototype languages.
> They might be okay for languages where you use Flex and/or Bison for
> one small part of the compiler (e.g., they way they're used in GCC,
> which is huge anyway). Trying to implement a compile-time language
> inside a compiler written with Flex/Bison is a major pain in the butt
> In general, assemblers have such simple grammars that using Bison for
> anything other than processing arithmetic expressions is probably a
> waste of time anyway. Flex can be useful, though. Nevertheless, a
> Flex-generated scanner is going to be *way* bigger than most
The fact that its specification is clearer and simpler, leading to a
more reliable and maintainable program, may matter more.
> hand-generated scanners (though the hand-generated scanner I wrote for
> HLA v2.0 is far from tiny, ...; fortunately, it doesn't all
> execute all the time, and most of the memory it's sitting in doesn't
> get touched, so you don't have the cache pollution problems you get
> with Flex and Bison's tables).
Cache pollution is not an issue that 999 out of 1000 HLL programmers
should concern themselves with. (Let's not confuse the assembler itself
with issues that might arise in assembly programming...)
The OP was, iirc, asking about "writing a simple assembler". A handmade
lexer/parser is likely outside the 'simple' zone: I argue that it's
easier and quicker to internalise 'info flex' and 'info bison' than to
internalise the Dragon Book, a bunch of more recent references *and*
fret oneself silly over cache pollution, pipeline stalls, etc.
In short, not every assembler is HLA.
> Cheers,
> Randy Hyde
Rod Pemberton
<rand...@earthlink.net> wrote in message
news:1142036486....@i40g2000cwc.googlegroups.com...
>
> toby wrote:
> > > ...
> > > While on the subject, I would also like to point out "yet another
> > > reason not to use Flex and Bison" for assemblers--
> >
> > Are you going to go into the reasons why one *would* want to use them?
> > Or will we leave that to others?
>
> Flex and Bison are great for small prototype languages.
> They might be okay for languages where you use Flex and/or Bison for
> one small part of the compiler (e.g., they way they're used in GCC,
> which is huge anyway). Trying to implement a compile-time language
> inside a compiler written with Flex/Bison is a major pain in the butt
> and it leads to all kinds of problems and restrictions on the grammar.
>
I'm interested in those statements.
(Sorry upfront to those who feel this is going off-topic since this thread
is heavily cross-posted).
I've run into this exact issue with a C99 grammar. The C language of course
is LALR(1) when stripped of typedef's and preprocessor directives. I can
deal with those issues, but I'm having a problem with flex. It matches
tokens by longest length, first. This is a problem with trigraphs,digraphs,
escape sequences, universal character constants, line continuation, etc.
All these small rules that must be processed first (C99 phase 1-4,5-7) and
are messing up the grammar: interfering with string tokenization,
preprocessor tokenization etc. At this point I'm thinking about writing a
pre-pre-processor and post-pre-processor just to deal with these situations
unless someone knows of a more elegant alternative.
Rod Pemberton
PS. Replies need to make it to alt.lang.asm for me to read.
Everett M. Greene
Just what is so complicated about parsing and lexical analysis
for a simple ASM (or even a complex ASM)? Do the obvious and
get on with the job.
toby
Well, we have differing definitions of 'the job'. I don't consider
reinventing the lexer/parser wheels (which can get arbitrarily complex
and tedious to get right/read/maintain) as *necessarily* part of this
'job' of writing an assembler. Ymmv.
Clearly HLA falls outside my parameters, or far outside the 'simple'
parameter, because it has strict performance requirements -- e.g. it
has to process very large symbol tables and a complex macro syntax, and
because it's among other things (forgive me) a competitor in a pissing
contest, if you've ever frequented alt.lang.asm. It's also written by
an assembly language programmer with an assembly language programmer's
preoccupations - cache, etc.
I am simply defending an alternative approach: Don't microdesign and
micromanage, but exploit tools like flex and bison to handle the
tedious and move on to focus on 'the real job'.
At one point I compared[1] two implementations of a PAL-III (PDP-8)
assembler, one with hand-coded lexer/parser, and one using flex/bison
(mine). In the hand-coded case, the code concerned with lexing/parsing
was 692 lines, or 58% of the program. In the flex/bison case, it was a
mere 179 lines, or 11% of the program (including token definitions,
grammar, support code). It seems reasonable to infer that there is
correspondingly less to write and debug in the latter case, by a factor
of nearly four. And it ends up in a clearer, more maintainable form.
But of course this reasoning applies most strongly to "simple"
projects.
[1] http://www.telegraphics.com.au/sw/info/dpa.html
toby
> Jim Stewart wrote:
> > toby wrote:
> >
> > > Alex wrote:
> > >
> > >>First, I would like to thank everyone for a response and advice.
> > Myself, I'd just define some macros for
> > MASM, the old Microsoft DOS assembler.
>
> Hi Jim,
>
> Now that is a technique I have heard of before! A gentleman Tom Evans
> clued me into this, and I hope he will allow me the liberty of quoting:
>
> There's two ways to "write an assembler in Macro 11".
I don't know why I didn't think of this before, since I've been looking
at it recently, but Mauro Persano's wicked-clever abuse of templates to
create a mock-assembler syntax for GNU Lightning is also in this vein.
I'm wishing for an excuse to try out his froofyjit:
http://freshmeat.net/projects/froofyjit/?branch_id=62508&release_id=218685
http://fzort.org/bi/sw/froofy/index.html#froofyjit
>
> --Toby
toby
> toby wrote:
> > Jim Stewart wrote:
> > > toby wrote:
> > >
> > > > Alex wrote:
> > > >
> > > >>First, I would like to thank everyone for a response and advice.
> > > >>...
> > > Myself, I'd just define some macros for
> > > MASM, the old Microsoft DOS assembler.
> >
> > Hi Jim,
> >
> > Now that is a technique I have heard of before! A gentleman Tom Evans
> > clued me into this, and I hope he will allow me the liberty of quoting:
> >
> > There's two ways to "write an assembler in Macro 11".
> > ...
>
> I don't know why I didn't think of this before, since I've been looking
> at it recently, but Mauro Persano's wicked-clever abuse of templates to
Not Mauro Persano's, but actually belonging to mncw, a.k.a. bi:
http://freshmeat.net/~mncw/
http://www.advogato.org/person/bi/
Apologies for the misattribution. And I only use the word 'abuse'
jokingly :-)
rand...@earthlink.net
toby wrote:
>
> Clearly HLA falls outside my parameters, or far outside the 'simple'
> parameter, because it has strict performance requirements
Hmm... That's the first time I've heard anyone claim HLA has "strict"
performance requirements. :-)
In matter of fact, HLA is one of the slower assemblers because
performance was never a design criterion for HLA v1.x (which is a
prototype used to develop the language).
> -- e.g. it
> has to process very large symbol tables and a complex macro syntax, and
> because it's among other things (forgive me) a competitor in a pissing
> contest, if you've ever frequented alt.lang.asm.
Performance has nothing to do with the "pissing contest" over in ALA.
On the performance side, only a few assemblers (e.g., NASM) are slower
than HLA.
> It's also written by
> an assembly language programmer with an assembly language programmer's
> preoccupations - cache, etc.
It's written in Flex, Bison, and C. As I've pointed out a couple of
times in this thread. Anyone concerned about "assembly language
preoccupations", especially the cache, would steer clear of Flex and
Bison. For reasons I've pointed out in this thread.
Boy, you seem to be a bit confused about what HLA is.
>
> I am simply defending an alternative approach: Don't microdesign and
> micromanage, but exploit tools like flex and bison to handle the
> tedious and move on to focus on 'the real job'.
That was exactly the approach I chose to use when developing the
prototype for the HLA language. I lived to regret that choice. Granted,
HLA has some sophisticated features that make it a bit more complex
than a "simple assembler", but is exactly those types of features for
which Flex and Bison are supposed to be ideal. Alas, the moment you
want to do something like macros, Flex and Bison (well, especially
Bison) become anchors, holding back the project.
>
> At one point I compared[1] two implementations of a PAL-III (PDP-8)
> assembler, one with hand-coded lexer/parser, and one using flex/bison
> (mine). In the hand-coded case, the code concerned with lexing/parsing
> was 692 lines, or 58% of the program. In the flex/bison case, it was a
> mere 179 lines, or 11% of the program (including token definitions,
> grammar, support code).
> It seems reasonable to infer that there is
> correspondingly less to write and debug in the latter case, by a factor
> of nearly four.
That is an incredible generalization that you cannot make on the basis
of such a small project.
> And it ends up in a clearer, more maintainable form.
> But of course this reasoning applies most strongly to "simple"
> projects.
Which, alas, have a habit of growing. And Bison parsers don't scale up
well.
Cheers,
Randy Hyde
toby
> toby wrote:
>
> >
> > Clearly HLA falls outside my parameters, or far outside the 'simple'
> > parameter, because it has strict performance requirements
>
> Hmm... That's the first time I've heard anyone claim HLA has "strict"
> performance requirements. :-)
>
> In matter of fact, HLA is one of the slower assemblers because
> performance was never a design criterion for HLA v1.x (which is a
> prototype used to develop the language).
>
> > -- e.g. it
> > has to process very large symbol tables and a complex macro syntax, and
> > because it's among other things (forgive me) a competitor in a pissing
> > contest, if you've ever frequented alt.lang.asm.
>
> Performance has nothing to do with the "pissing contest" over in ALA.
> On the performance side, only a few assemblers (e.g., NASM) are slower
> than HLA.
>
>
> > It's also written by
> > an assembly language programmer with an assembly language programmer's
> > preoccupations - cache, etc.
>
> It's written in Flex, Bison, and C. As I've pointed out a couple of
> times in this thread. Anyone concerned about "assembly language
> preoccupations", especially the cache, would steer clear of Flex and
> Bison. For reasons I've pointed out in this thread.
>
> Boy, you seem to be a bit confused about what HLA is.
Yes, I apologise for my ignorance of its implementation. I had gathered
from your earlier posts that you had rejected Flex/Bison early on. I
gather you will not use them in future rewrites?
>
>
> >
> > I am simply defending an alternative approach: Don't microdesign and
> > micromanage, but exploit tools like flex and bison to handle the
> > tedious and move on to focus on 'the real job'.
>
> That was exactly the approach I chose to use when developing the
> prototype for the HLA language. I lived to regret that choice. Granted,
> HLA has some sophisticated features that make it a bit more complex
> than a "simple assembler", but is exactly those types of features for
> which Flex and Bison are supposed to be ideal. Alas, the moment you
> want to do something like macros, Flex and Bison (well, especially
> Bison) become anchors, holding back the project.
I would agree with that. But again, maybe a macro assembler (especially
one with HLA's design goals) is outside the ambit of 'simple'.
>
> >
> > At one point I compared[1] two implementations of a PAL-III (PDP-8)
> > assembler, one with hand-coded lexer/parser, and one using flex/bison
> > (mine). In the hand-coded case, the code concerned with lexing/parsing
> > was 692 lines, or 58% of the program. In the flex/bison case, it was a
> > mere 179 lines, or 11% of the program (including token definitions,
> > grammar, support code).
> > It seems reasonable to infer that there is
> > correspondingly less to write and debug in the latter case, by a factor
> > of nearly four.
>
> That is an incredible generalization that you cannot make on the basis
> of such a small project.
I'm only talking about small projects, here. PAL-III is a strictly
defined syntax: It can't grow, and it doesn't have macros. This is only
a case study.