Re: Okay, lets talk assemblers and Lua (was Re: A bit more on bits...)

[Sean Conner <sean@...>]

It was thus said that the Great Johann ''Myrkraverk'' Oskarsson once stated:
> On 2/17/2023 7:18 PM, Luiz Henrique de Figueiredo wrote:
> >Can we please go back to discussing Lua? Thanks.
> 
> I have done project 1-1, more or less, in the book /Assemblers and
> Loaders/ [1] in Lua.  It was a bit unusual for me to create data
> structures out of Lua tables, but once the initial hurdles were over
> and I had figured out binary output, it turned out to be rather easy.

  Cool!  

  A few years ago I did an assembler for the Motorola 6809 in Lua.  

> It turns the example input of
> 
> 	INP
> 	STO 50
> 	INP
> 	STO 51
> 	BZE X
> 	ADD 50
> 	OUT
> 	BRA Y
> X	LOD 50
> 	ADD 50
> Y	STO 52
> 	HLT
> 
> into
> 
> 00000000: 7000 2032 7000 2033 400d 3032 8000 6011  p. 2p. 3@.02..`.
> 00000010: 1032 3032 2034 0000                      .202 4..
> 
> with the 2pass assembler.  

  Yup, my Lua 6809 assembler is also a two pass assembler.  

> As per the book, I changed the binary
> format slightly between the 1pass and 2pass assemblers. [2]
> 
> Parsing is something I did with a line by line reader, and
> string.match(), which works fine for a very rigid syntax.  Later
> on, I'm pretty sure I'll have to resort to something more flexible
> like recursive descent or something.

  I used LPEG for my assembler, only because parsing expressions like:

	ldd	#(ACIA_CONTROL_RESET * 256) + ACIA_CONTROL_DEFAULT

a lot easier.  It also helped with index-based addressing modes.  But even
with LPEG, I still do line-by-line parsing.  The only portion of my
assembler that is recursive is my "include" directive, which to me, is a
"nice to have" rather than a "hard requirement."

  -spc