NanoWar wrote:
I'll shamelessly plug my funk build of spasm here: Could you maybe do me a favor and try this out? The command lie switch is -Z

https://dl.dropboxusercontent.com/u/902690/ti/funk/spasm-funk-win64.exe

Nice! I'll give it a try. Thank you! Smile Does the Funk build include all the macros as directives? Meh, I guess I'll just go see.
MateoConLechuga wrote:
Nice! I'll give it a try. Thank you! Smile Does the Funk build include all the macros as directives? Meh, I guess I'll just go see.

No just the compiler Smile . Lib is still on top.
Wonderful wonderful assembler, but I think I found a bug or two. It won't let you compile a file with "#include"s when the folder path to SPASM includes special characters. (In my case I tried to use "→")
I apologize if I missed the answer to this question on IRC yesterday: does SPASM-ng have some equivalent of Brass's .incbin? Also, I think a directive reference for SPASM[-ng] would be extremely helpful, and if I get a chance, I'd be happy to help.

Edit: Runer112 has kindly indicated on IRC that #import is the answer.

Edit #2: I originally thought that the Emscripten'd SPASM-ng and/or SourceCoder had a bug causing the following issue, but it turns out that it happens with the Windows build as well. The issue has two parts:
1) The listing file has the listing file title line about 10-50 lines into the file, rather than at the top.
2) The listing file title line mentions one of the #included files in a project that #includes files, rather than the top-level .asm file. For example:

Code:
Listing for file "C:\Users\[...]\DCS8Dev\vectors.asm"
*bump* More bug reports! If you have X .equ Y in a program any time after .org, SPASM equates X to the address at which the .equ appears, which I didn't discover as the cause of some inexplicably crashing code until I did some sleuthing into the list file. That's pretty broken: it's not a label, SPASM.

Edit: Thanks to Tari, we have an MWE that replicates my problem. This should emit an error, and silently performs undefined behavior instead:
Code:
   .org $0
A .equ B + 3
    .dl A
#define B $D00000
KermMartian wrote:
*bump* More bug reports! If you have X .equ Y in a program any time after .org, SPASM equates X to the address at which the .equ appears, which I didn't discover as the cause of some inexplicably crashing code until I did some sleuthing into the list file. That's pretty broken: it's not a label, SPASM.

Actually, I think this is perfectly fine behavior. Since A is not prefixed with whitespace, it is treated as a label. This is handy if you wish to do this:


Code:
.org 0
_someroutine .equ $
 jp 3


Also, spasm has many, many useful directives and macros that can add pretty much any functionality you desire:

https://wabbit.codeplex.com/wikipage?title=SPASM%20Directives&referringTitle=Documentation
https://wabbit.codeplex.com/wikipage?title=SPASM%20Internal%20Functions&referringTitle=Documentation
https://wabbit.codeplex.com/wikipage?title=SPASM%20Preprocessor&referringTitle=Documentation
http://www.omnimaga.org/asm-language/spasm-macros/?wap
http://z9.invisionfree.com/omnimaga/ar/t1647.htm
MateoConLechuga wrote:

Code:
.org 0
_someroutine .equ $
 jp 3
That's a weird overload, and breaks at least a few rules. Labels must be followed by a colon which that one is not, and even if you assume that's a legal label the .equ should be an error because it's not doing anything.
Tari wrote:
That's a weird overload, and breaks at least a few rules. Labels must be followed by a colon which that one is not, and even if you assume that's a legal label the .equ should be an error because it's not doing anything.

Haha, sure it is Smile Labels are not at all required to have colons, and this is basically telling the assembler that the label exists at the current address, which is 0. This is a nice go-between for the ZDS assembler and spasm, as it does not require a .org anywhere, and can be assigned to an arbitrary address.
Mateo: I should clarify, since I don't think it was clear, that SPASM-ng does what I expect it to if I change where the define is:
Code:
   .org $0
#define B $D00000
A .equ B + 3
    .dl A
In the "wrong" case, the assembler is realizing it doesn't know what B + 3 is, then seemingly silently discarding the .equ B + 3. In the "correct" case (the one in this post), it properly interprets this as a .equ.
KermMartian wrote:
Mateo: I should clarify, since I don't think it was clear, that SPASM-ng does what I expect it to if I change where the define is:
Code:
   .org $0
#define B $D00000
A .equ B + 3
    .dl A
In the "wrong" case, the assembler is realizing it doesn't know what B + 3 is, then seemingly silently discarding the .equ B + 3. In the "correct" case (the one in this post), it properly interprets this as a .equ.

Ah, that makes a lot more sense Smile Yeah, there should be a warning generated or something. Hm.
There should be an option to automatically replace jp with jr whenever possible.
tmwilliamlin168 wrote:
There should be an option to automatically replace jp with jr whenever possible.


This is not the job of an assembler, nor should it be. An assembler should translate assembly exactly as specified into machine code. I don't believe that there's any easy way that spasm could implement such a feature anyway.

If you wanted such behavior, although I would suggest that you really shouldn't, you could probably make a macro that works for backwards jumps.
Runer112 wrote:
tmwilliamlin168 wrote:
There should be an option to automatically replace jp with jr whenever possible.


This is not the job of an assembler, nor should it be. An assembler should translate assembly exactly as specified into machine code. I don't believe that there's any easy way that spasm could implement such a feature anyway.

If you wanted such behavior, although I would suggest that you really shouldn't, you could probably make a macro that works for backwards jumps.


It should be easy. Just check if the jump is within the 256 byte range, and if it is, change it to jr to save memory and a few clock cycles.
tmwilliamlin168 wrote:
It should be easy. Just check if the jump is within the 256 byte range, and if it is, change it to jr to save memory and a few clock cycles.

If it is so easy, you should write the code for it \o/ Anywho, this is not the purpose of an assembler. This is more of the role of a compiler.
MateoConLechuga wrote:
tmwilliamlin168 wrote:
It should be easy. Just check if the jump is within the 256 byte range, and if it is, change it to jr to save memory and a few clock cycles.

If it is so easy, you should write the code for it \o/ Anywho, this is not the purpose of an assembler. This is more of the role of a compiler.

Can SPASM-ng only be an assembler? I don't see any reason to not extend it.
tmwilliamlin168 wrote:
MateoConLechuga wrote:
tmwilliamlin168 wrote:
It should be easy. Just check if the jump is within the 256 byte range, and if it is, change it to jr to save memory and a few clock cycles.

If it is so easy, you should write the code for it \o/ Anywho, this is not the purpose of an assembler. This is more of the role of a compiler.

Can SPASM-ng only be an assembler? I don't see any reason to not extend it.

It's open source. Fork it if you feel the need.
FWIW, in GCC4TI for the TI-68k series, both A68k and GNU as for m68k can optimize some instructions - and then, the environment-specific linker can optimize more when there's full knowledge of the program: range-cutting, etc..

The A68k (documentation: https://debrouxl.github.io/gcc4ti/a68k.html ) and linker (documentation: https://debrouxl.github.io/gcc4ti/ld.html ) optimizations are disabled by default and enabled through command-line switches. However, at least one GNU as optimization is enabled by default: automatically turning two special, non-portable mnemonics to short form, or providing a long form of two mnemonics which exist only in word form: https://debrouxl.github.io/gcc4ti/gnuasm.html#SEC221 .
It works best inside a single source code file, and I'd say that this is mostly a misfeature for lazy programmers, though theoretically, it helps the code remain as optimized as possible when reordering inside a file: for instance, automatically taking advantage of 2-byte branches which may appear, while keeping 2-byte branches as such, and automatically adjusting 2-byte branches to 4 bytes.

If someone were to implement the optimization feature you mentioned in spasm, I'd strongly suggest that it be controlled by a command-line switch which defaults to disabled, of course Smile
I have a weak preference for a special mnemonics which would be turned into either jp or jr, over automatic optimization of standard mnemonics: while it makes the code non-portable to other assemblers, the fact is that spasm-ng is the community assembler of choice nowadays, and spasm-ng is itself a multi-platform program.
Apologies for reviving this thread from 2016, but it seems like this is the best one to ask about the status of spasm-ng. My question is: Is spasm-ng maintained or abandoned?

* The last release on the project's GitHub repo (https://github.com/alberthdev/spasm-ng) is SPASM-ng v0.5-beta.3. There was no final release.

* There has been only about 6 commits since 2017.

* I cannot find any documentation for spasm-ng. Every link to various docs in a previous post is dead. My Google-fu does not seem good enough to find any other documentation.

I have spent the last few months writing around 10,000 to 20,000 lines of Z80 assembly code for the TI-83+ and TI-84+ using spasm-ng. It works really well for the most part. But I am often hitting bugs in spasm-ng that would be nice to fix. But if the project has been abandoned, it would be difficult to justify the investment required to dig into the code.

Yes, I can always fork the project, the mechanics of the forking process does not faze me (though I do worry if there is enough information in the repo to allow me to build binary). My overall concern is whether there is enough institutional knowledge about spasm-ng and the TI-OS that I can rely on. I personally do not have the deep technical expertise about the TI-OS to maintain a fork of spasm-ng in the long run.
For documentation, archived pages from codeplex will do: http://web.archive.org/web/20170711205823/http://wabbit.codeplex.com/documentation
It would be nice to rescue that and put a copy in the repository though.

As for the rest of the maintenance, I don't think many people use spasm anymore (most of the people targeting eZ80 are now using fasmg) but I've made some changes for my own use that are at least meant to make it easier to maintain. As I don't have merge permissions to the "official" repository I've also made my fork more than just a staging ground for pull requests: https://github.com/tari/spasm-ng/

While I can't speak for anybody else, I'd say spasm looks abandoned because the people with the ability to merge have been unresponsive lately and because very few people have any interest in improving it (which is a result of very few people using it). However I also believe that nobody still maintaining it really understands how the entire thing is put together, since spasm-ng was basically resurrected from older versions of the assembler that had been abandoned. Fortunately the code isn't very complex.

I also don't think any knowledge of TI-OS is meaningful for working on the assembler, since it doesn't have any TI-specific knowledge aside from knowing how to handle calculator file formats.
Most of these days people use fasmg for ez80, and few people have been using it for z80 too. It's the future!
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 3
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement