Closed SuperJMN closed 1 year ago
This seems specifically only for assembling Z80 source without the client having to specify on command line? I don't know if this is appropriate since the assembler is designed to support several different CPUs.
This seems specifically only for assembling Z80 source without the client having to specify on command line? I don't know if this is appropriate since the assembler is designed to support several different CPUs.
It would be OK to have a single assembler as a façade to other assemblers. In any case, my goal is to expose any artifact that makes it possible to consume the assembled data without calling to an executable and writen a file to the filesystem.
Does it makes sense to you?
This seems specifically only for assembling Z80 source without the client having to specify on command line? I don't know if this is appropriate since the assembler is designed to support several different CPUs.
It would be OK to have a single assembler as a façade to other assemblers. In any case, my goal is to expose any artifact that makes it possible to consume the assembled data without calling to an executable and writen a file to the filesystem.
Does it makes sense to you?
I think it makes sense. It seems like what you are looking for is the ability to call a package/module that implements a specific assembler. Each module could leverage shared library that handles parsing, symbols, expression evaluation, etc. but each would be responsible for generating code specific to its target CPU, and its output would be the actual in-memory generated code that caller/client could do with as it wish, like writing to disk or maybe sending back as a response for a web service or something. Is that right?
This seems specifically only for assembling Z80 source without the client having to specify on command line? I don't know if this is appropriate since the assembler is designed to support several different CPUs.
It would be OK to have a single assembler as a façade to other assemblers. In any case, my goal is to expose any artifact that makes it possible to consume the assembled data without calling to an executable and writen a file to the filesystem. Does it makes sense to you?
I think it makes sense. It seems like what you are looking for is the ability to call a package/module that implements a specific assembler. Each module could leverage shared library that handles parsing, symbols, expression evaluation, etc. but each would be responsible for generating code specific to its target CPU, and its output would be the actual in-memory generated code that caller/client could do with as it wish, like writing to disk or maybe sending back as a response for a web service or something. Is that right?
Exactly. You said it exactly. 100%!
I don't mind doing this but can we hold off on this change for now? It's just because I would have to re-organize all the stuff responsible for the other CPUs and probably don't have time at the moment? If so we can close.
I don't mind doing this but can we hold off on this change for now? It's just because I would have to re-organize all the stuff responsible for the other CPUs and probably don't have time at the moment? If so we can close.
No problem! I hope you can come with some nice changes to consume the library from another app. By the way, I want to share with you the IDE for the Z80 I have created. It's here: https://github.com/SuperJMN/SuppaZ80
Thanks for your help!
I'll check it out!
This PR makes it easier for consumers of this library to use it without relying on the command line part.
Usage: