An API to obtain source code and information about symbols

[tstih]

At present you are reading the list files (SLD, LIST), which is limited to certain assemblers. But if one could provide a simple API that works over TCP/IP (similar to GDB) you could read any format- unlocking some wild features:

1. You could create your own disassembly dialect (for example: SDCC),
2. You could provide your own symbols,
3. You could provide annotated C source code and use DEZOG as C source code debugger.
   One would simply need to write C/C++ TCP/IP server to support certain assembler/dialect/language and support a few functions.

[maziac]

Hi Tom,

Thanks for the suggestion. Could you elaborate some more on this.

The general problem is the association of file/line numbers with the PC value.
In an emulator you often just put the binary in and the emulator doesn't even know of this relationship or of symbols.
The 2nd major problem (and this is really a huge problem) is paging/banking.
DeZog does alot to work correctly even when different memory banks are involved.
This would probably not be solved on the emulator side so that it would still be required to use extra info (like the bank addresses in the sld format).

[tstih]

Hi,

Ad 1. The problem of association of file/line numbers on SDCC is solved by generating the CDB file. This file is generated by using special switch and the specs is here:
https://sourceforge.net/p/sdcc/wiki/CDB%20File%20Format/
You can think of this as sort of external coff data.

Ad 2. I know that people on z88dk and people at fuzix (for SDCC) were both upgrading compilers to support Z80 paging or as they call it the far memory, but only as 3-byte pointers to data.
https://z88dk.org/previous/far_z88.html
https://github.com/EtchedPixels/sdcc280
But I need to study a bit more how your mapping works and how this works. Is there a nice document how far addresses are handled in the assembler and what would DeZog need? For example, I'm currently writing a debugger for Eastern computer called Iskra Delta Partner and it switches bank by writing to bank 0x88 and 0x90. So before using anything for any bank it would need to call OUT or IN instruction on that port anyway. And par to the memory (top part) is shared between both banks. So what does the debugger need that we need to provide? My assumption is jumps can only be 16 bit so the only thing that can be generated by the assembler is data/variable in another bank and you'd like to see the value anyways in the debugger regardless of the bank? Or is it something else that is problematic. Can you hint me what does SLD do and what does DEZOG need and I can do a bit of research?

[ped7g]

SLD originated from different project "Next Development System" for ZX Next, initial patch for sjasmplus happened due to that, then I tried to extend it myself in sjasmplus to theoretically cover more complex cases and together with Maziac we tried to adapt it for Dezog.

Current file format and some examples: http://z00m128.github.io/sjasmplus/documentation.html#c_sld_data

Giving quick look this thread: I'm not sure how API differs from file protocol. The SLD file is kinda API too. Real API would probably allow for some more dynamic stuff, which could enable more features, but also bring more pain and breakages, but overall I believe you can get pretty far by exploiting current SLD mechanics and it would take you some time to create and polish API variant to the point where it would bring significantly more to the table. IMHO. Maybe you would prove me wrong quickly. :)

[maziac]

In DeZog the "far addresses" are called "long addresses".
This document is a good start: https://github.com/maziac/DeZog/blob/main/design/MemoryPaging.md
Further good reads are https://github.com/maziac/DeZog/blob/main/design/AddingNewAssemblers.md and https://github.com/maziac/DeZog/blob/main/design/AddingNewRemotes.md.

There are 2 things to it:

• First the parser (parsing sld or list files or maybe some other symbol file for sdcc in the future).
  It associates files with long addresses.
• The other important thing is the emulator and the memory model used in emulation.
  • zesarux: the memory model is read after connection setup. This tells dezog how to interpret the values read through zrcp.
  • cspect: this assumes a zxnext
  • zxnext HW: This also assumes a zxnext obviously, the banks are read through dzrp.
  • mame: the mame gdbstub does not report any information about paging, thus banking is not supported in this mode.

I.e. it is also important to have a target (emulator) that allows to read the banking information.

[tstih]

Thanks. I'm taking some time thinking about it. Will provide feedback once I detail the idea.