Re: Huge ADK Update
From: Randall Hyde (randyhyde_at_earthlink.net)
Date: 02/28/05
- Next message: Beth: "Re: Can this loop be made faster ?"
- Previous message: Randall Hyde: "Re: When to use Rosasm, when to use Masm?"
- Maybe in reply to: Randall Hyde: "Huge ADK Update"
- Next in thread: Betov: "Re: Huge ADK Update"
- Reply: Betov: "Re: Huge ADK Update"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 28 Feb 2005 02:22:27 GMT
"Octavio" <933191278@terra.es> wrote in message
news:a3b1e869.0502270811.522f7990@posting.google.com...
> I have take a look to sources from others assemblers to get ideas for
> my own.
> And it call my attention that while most programmers are using table
> based dictionnaries
> Randall and Betov are using code based
> dictionaries,
Depends on which version of HLA you're talking about.
HLA v1.x uses a Flex-built scanner and a Bison-generated parser.
HLA v2.0 uses a recursive-descent predictive parser and, largely,
a machine-generated lexer (for recognizing reserved words) and
a hand-written lexer for everything else. This wasn't a trivial
decision. The assembler spends a fair amount of time in lexical
analysis, so you want that to be as fast as possible. That's why,
for example, there is a huge chunk of machine-generated code
to recognize the reserved words. That type of coding is highly
repetitive and tedious to write and maintain. So I wrote a program
that *generated* this code from a table of reserved words.
The result is something that runs faster than a strict table-driven
lookup, yet it's still easy to maintain (just add your new reserved
words to a text file and run the code generator).
Parsing in HLA v2.0 is definitely recursive-descent ("code-based")
and this is *highly* intentional in the part of HLA v2.0's design.
You can do *far* better error analysis and reporting with a
recursive-descent compiler than you can with a table-driven one.
Keep in mind that HLA's audience is beginning assembly language
students, so being able to provide good error diagnostics is important.
This was the biggest failure, IMO, in the HLA v1.x system that
uses a parsing table system (i.e., a Bison-generated lexer).
As for code generation, well, HLA v2.0 will continue to use
a recursive descent parser with table lookups for instruction
opcodes. But this is still a ways in the future and is subject
to change. The important thing is to ensure that HLA v2.0
is easy to maintain. Though it seems contrary to intuition,
table lookup (code generators) are not all that easy to maintain.
For example, when something like a 64-bit processor comes
along, all the tables have to be redesigned. For a "code-driven"
code generator, you simply add the new code for the newer
instructions.
Performance-wise, I've yet to see an argument that one
way is faster than the other. Table-driven systems tend to
be *smaller* than the state-machine ("code-driven") versions,
however.
> both use hll programing style :rosasm source has a lot
> of 'if while', hla uses automatic code generators also called
> compilers.
???
Which version of HLA are you talking about here?
> and i have never seen both togheter.
Thank God :-)
> Conclusion: is the same person.
:-)
Cheers,
Randy Hyde
- Next message: Beth: "Re: Can this loop be made faster ?"
- Previous message: Randall Hyde: "Re: When to use Rosasm, when to use Masm?"
- Maybe in reply to: Randall Hyde: "Huge ADK Update"
- Next in thread: Betov: "Re: Huge ADK Update"
- Reply: Betov: "Re: Huge ADK Update"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
