Assembler Enhancements

[Onkar Shinde]

There are some minor things that could be improved on in the current assembler implementation.R Error messages are currently not very useful, in fact their line numbers are often apparently offset by +1.

Also, using wrong operands will often wrongly report an invalid mnemonic.

In this sense, assuming that it would be difficult to improve such things in the short run, it might make sense to provide a separate, more detailed, log that contains more information about the assembly process. So that each step of the assembler is interactively shown:

1: found comment, skipping to next line
2: found supported mnemonic "mvi", (expecting reg,immediate): found reg,reg
3: found unknown token "foo"

Something like this would at least have the potential to allow users to see clearly where the assembler stopped succeeding with assembling the file.

Also, other 8085 assemblers often support direct ways to provide numbers using a different notation:
  mvi a,14h
  mvi a,14d
  mvi a,01110011b

Also, the "db" directive usually also supports providing the corresponding bytes as quoted strings of characters:

data: db 'hello world',0A,0D,'$'
dat2: db "foo"

In its current form the assembler also isn't able to compute offsets for labels defined after the position of the current instruction:

  mvi a,5
start: nop
  cmp 5
  jz exit ;ERROR: exit not known because no multipass support in assembler
exit:

[Bug Importer (bug-importer)]

Logged In: NO

realtime source assembling might be another option to make the editor more informative and helpful: if for each keypress in the editor, the scanner and tokenizer are triggered to reparse the source code, interactive editing support would become possible, for example typing "mvi" could directly display a message in the statusbar "mov immediate value: expecting operand value (8 bit)".

Whenever a complete and valid instruction is entered, the global state could be set to "valid" which could be visualized using an "ok" symbol in the statubar, if the source code isn't complete or valid, the symbol could be grayed out to illustrate that the source seems invalid.

[Bug Importer (bug-importer)]

Logged In: NO

one could also consider embedding any of the existing open source x85 assemblers into gnusim

http://sourceforge.net/projects/sasm85/

[Bug Importer (bug-importer)]

Logged In: NO

FYI: there's a number of tools (like sdcc or gpsim) that rely on the gputils package which provides assemblers for various microprocessors and microcontrollers, IIRC the 8085 is among the supported devices.

[Bug Importer (bug-importer)]

Logged In: NO

WRT the previous comment, that might indeed pose a feasible approach to reducing code size and complexity, so that existing tools might be leveraged that are maintained separately, and being pretty widely in use, the gputils package would be an ideal candidate for such a thing

[Bug Importer (bug-importer)]

Logged In: NO

the classic approach to solve the problem with unknown symbols because they're defined at a later time, would be to make use of forward declarations, however this is currently not possible because of the check that yields a "Redefinition error", it could work something along the lines of:

jmp start
; data
label: db 00 ; define symbol named label of word byte

; dead code:
jmp label ; -- recognized as referring to an address of type byte

; functions:
label: nop
       nop
ret

; -- entry point
start: nop

end: nop
     hlt

[Bug Importer (bug-importer)]

Logged In: NO

support for forward declarations could also be implemented via macros, so that labels can be explicitly declared at the beginning of the program, i.e. using some sort of EQU directive.

[Bug Importer (bug-importer)]

Logged In: NO

Item #1799444 probably belong here, too - or is at least very much related.

[Bug Importer (bug-importer)]

Logged In: NO

There's now a patch available: http://sourceforge.net/mailarchive/attachment.php?list_name=gnusim8085-devel&message_id=c09091460803190450v29d61000le3583e62139ba355%40mail.gmail.com&counter=2

[Bug Importer (bug-importer)]

Logged In: NO

WRT the DB/string directive, see: http://sourceforge.net/mailarchive/forum.php?thread_name=E1Jljct-0007hd-Tm%40sc8-sf-web23.sourceforge.net&forum_name=gnusim8085-devel

[Bug Importer (bug-importer)]

Logged In: NO

I would agree that factoring out the assembler would be a good idea, in fact using a separate, standalone tool might be the best option in the end, there are various options and this would make help redefine the scope of gnusim8085, so that it doesn't have to maintain redundant components, that are also easily otherwise available

[Bug Importer (bug-importer)]

Logged In: NO

the following also seems unsupported
  foo: ds 04

also, the website at http://www.sbprojects.com/sbasm/8080.htm shows how immediate mode mnemnonics are normally supposed to support a syntax in the form of:

mvi a,#05

[Bug Importer (bug-importer)]

Logged In: NO

just use an external assembler, such as the one provided by gputils/gpasm, if necessary this could be put into a library

[Bug Importer (bug-importer)]

Logged In: NO

assuming that the current simulator infrastructure is working with 1:1 valid hex output, it would indeed be a nobrainer to go and use existing standalone simulators

[Bug Importer (bug-importer)]

simulators??
You probably standalone *assemblers*!?

[Bug Importer (bug-importer)]

an optionally "interactive assembly process" could also help in educational settings

[Bug Importer (bug-importer)]

here's some more info about assembler directives generally supported by most 8085 assemblers:
http://www.cs.otago.ac.nz/cosc243/lectures/asm_dir.pdf
http://www.ordersomewherechaos.com/rosso/fetish/m102/web100/docs/assemb-tutorial.html (look for "directive")
http://www.crossware.com/8085/a8085nt.pdf (last site and paragraph)

[Bug Importer (bug-importer)]

another useful directive would be 'dup' to pre-initialize values to a certain value

[Bug Importer (bug-importer)]

regarding standalone assemblers:

there's a GPL'ed 8085 standalone assembler available at http://john.ccac.rwth-aachen.de:8000/as/

[Bug Importer (bug-importer)]

regarding db strings, the following bug discussion is related:
http://sourceforge.net/tracker/index.php?func=detail&aid=1942906&group_id=86462&atid=579699

[Bug Importer (bug-importer)]

Using a separate, standalone assembler (library or executable) might actually help re-defining the focus of the project, meaning that the complexity of this project would decrease, because it would rely on a separate project for assembling the source code, the sdcc project also relies on external assemblers such as "asXXXX". In addition, this would be a fairly powerful step, too because users could also use other external assemblers such as nasm if they want to.

This would probably be a good step to help the simulator become less monolithic and more modular, and most of the assembler-related shortcomings would be immediately solved, too.

So it's probably worth to think about this some more!

[Bug Importer (bug-importer)]

regarding the issue with hex immediates, the following discussions are related:

http://sourceforge.net/tracker/index.php?func=detail&aid=1922335&group_id=86462&atid=579702
http://sourceforge.net/tracker/index.php?func=detail&aid=2655537&group_id=86462&atid=579699

[Bug Importer (bug-importer)]

If there are no plans to replace the built-in assembler with a standalone tool or an external library, here's a detailed explanation how to implement a two pass assembler that patches label addresses in the 2nd pass:

http://stackoverflow.com/questions/384871/building-an-assembler

[Bug Importer (bug-importer)]

there are other sf.net projects that provide standalone 8085 assemblers:
http://sourceforge.net/projects/lc8085asm/

[The Escapist (wisd00m)]

There are a number of bugs and patches related to this:

https://bugs.launchpad.net/gnusim8085/+bug/579316
https://bugs.launchpad.net/gnusim8085/+bug/579367
https://bugs.launchpad.net/gnusim8085/+bug/579368

[The Escapist (wisd00m)]

There seems to be an increasing number of OSS 8085 assemblers available on line, even if none of those standalone assemblers should end up replacing the built-in assembler, it might still make sense to have a look at the source code in question to see how the features missing in GNUSim8085 were implemented, so that it would be possible to borrow ideas or even snippets of code from other open source projects.

[The Escapist (wisd00m)]

I have created a new blueprint to collect all issues related to the implementation of the built-in assembler: https://blueprints.launchpad.net/gnusim8085/+spec/assembler-fixing

What is the general consensus here: would people rather improve on the current built-in assembler to become more feature-complete, or is anybody seriously considering replacing the built-in assembler with a more mature standalone/library component from another OSS project?

I am myself interested in this debate, mostly because of the following features missing in the current implementation:

- ORG
- many standard pseudo instructions
- character strings
- macros

[The Escapist (wisd00m)]

Looking into this at the moment: the very first step for supporting an external assembler is providing an option to load assembled binary/HEX files. Then you could open and run an already assembled file with valid opcodes.

Saving to a HEX file has already been requested previously: https://bugs.launchpad.net/gnusim8085/+bug/579344

So once these two steps have been decoupled (saving and loading HEX files), supporting an external assembler would not be complicated to do, if that's really what people want to do.