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

[Johann ''Myrkraverk'' Oskarsson <johann+lua@...>]

On 2/23/2023 2:36 AM, Sean Conner wrote:
> 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.

Nice!  I may try to make an assembler project for a CPU that exists,
but right now, I'm not sure which one would be a suitable target for
a Lua project.

[snip]

> > 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."

Nice, I didn't know about LPEG.  Depending on exactly what I end up
doing I may decide to do recursive descent, or something else.  My
personal end goal is a learning experience, so I'll definitely put
LPEG in my toolbox, but it's not necessarily the tool I end up using
for my projects.

That said, experimenting with it is probably a worthwhile endeavor for
said learning experience.


Thanks,
Johann