ASM-only code files
Seairth
Posts: 2,474
in Propeller 2
I like writing purely assembly language programs for the Propeller. The problem is that the "standard" file format is really for Spin, and that has necessarily impacted design decisions about the file format and features. I am not asking to change spin files. Instead, I want to define a file format that is meant to only be assembly language. And while I think it would be good to use the same general syntax as in spin files, I think there are a few things I would do differently:
So, given the myriad of programming language activities going on, does this already exist?
- #define-like ability to define constants (instead of a CON block)
- import/include other files (make things more modular)
- macro-like ability to define compile-time snippets (this is a stretch goal)
So, given the myriad of programming language activities going on, does this already exist?
Comments
EDIT: I just grabbed m4 at the time while I was adapting TAQOZ for ROM use and I really had to break up my main file into sections that could be built in different ways. But thinking about it now, it probably isn't too hard to write some Python code to preprocess files and then combine that with oz's loader code too.
There are batch files in the Catalina bin directory (p2_asm.bat on Windows, and just p2_asm on Linux) that wrap the two together.
(incidentally, I left one item out of the list above because I was concerned it would be controversial. I would make all of the directives (ORG, ORGH, etc.) use a different syntax instead of making them look like instructions. That would admittedly be a bigger departure than just adding some new features. On the other hand, I think it would make it more obvious what is a compile-time feature and what isn't.)
Not sure about behaviour when compiling though. Spin/C/Basic objects may have different rules.
I think you may need to explain exactly what you mean by "file standard". p2asm just takes a plain text file of pure P2 assembly language, which seems to be what you want - apart from the #define capabilities, which are typically added separately by a pre-processor of your choice.
The directives - DAT, CON, ORG, ORGH, ORGF, FIT etc - are all standard and would have to be supported by any assembler.
I'm not sure what there is more than that to "standardize", but I may be missing your intent here.
Ross.
I get that I could likely have what I want by using a preprocessor. But even then, is there a standard set of preprocessor directives, macros, etc, that everyone is using?
In truth, I don't want to use a preprocessor. I'm not dealing with a language like C where preprocessors are expected. As I stated above, I am starting a new assembler project and a preprocessor does fit with what I have planned. For instance, at the very least, I want an intrinsic syntax for importing other assembly code. And I don't want to have CON and DAT blocks, which I view as Spin concepts, not PASM concepts.
What I'm hearing is that there isn't anything like that.
Did you look at ersmith's work ?
IIRC that was doing include file support ?
eg this was talking about the most 'asm like' comments & supporting ; as a comment in ASM.
https://forums.parallax.com/discussion/170739/how-should-comments-and-expressions-work-in-pasm-that-isnt-inside-spin/p1
I cannot understand what you’re saying.
CON is tor constant equates.
#define is for setting compiler directives
#ifdef is for conditional compilation using the options defined with the #define directive
#include is used to insert more statements from an external file
file inserts a binary into the source.
ORG sets/resets the origin
These are fairly standard across many compilers dating back to pre 80’s. We had similar but differently named facilities (extremely powerful macros) instead. They were more powerful than anything I’ve ever seen since.
Eric’s fastspin does all the above, pnut only does file, and I’m unsure about p2asm. On P1 Roy’s OpenSpin, homespun and bst all implemented them too. Ross will need to comment wrt Catalina.
Of course we have ORGH because of hub.
I have been compiling pure pasm files for P2 for years -yes it’s been that long. While Chip compiled the P2 ROM with pnut, Peter and I used p2asm as it produced a very nice listing. Fastspin also produces a very nice listing. I’m compiling my Z80 emulator using fastspin and now have it in a number of separate files.
To me, I don’t care if the compilation (or to be pedantic, assemble) is done by a single program, or a pre-processor followed by a compiler, as long as the results are the same.
These days I use VS Code to edit my code. It works great, highlights code words in various colours, shows indentation, and above all is free, open source (but maintained by ms) and cross platform (Windows, Unix, mac). BTW I use vsc every day for my python day job.
I much prefer to use a standard editor such as VSC rather than use a less powerful IDE.
So, what am I missing?
He's wanting to be able to define constants anywhere in the source. Get rid of the CON section entirely.
But hey you can do this now. You just have to insert a CON, then the equates, and then back with a DAT followed by an ORG or ORGH. I do it now with #include files and fastspin, but it doesn’t have to be in an include file. Probably pnut would handle it too.
And ORGH has a trickiness to it as well with hubexec requiring a minimum start of $400.
I will certainly need to look at how fastspin handles multiple ASM files. But here's the thing. I am not looking to make an assembler based on pre-80's concepts. For instance every modern programming language (including Spin) has first-class import concepts instead of C-like includes. This is not to disparage preprocessor techniques, but it is not what I want in a "modern" language.
Actually, that is directly related to my plans. I too solely use VSC these days, and am working on a new extension for it. But, my intent for that extension is to be ASM-only. But more to the point of this conversation, the logical model of the source files significantly impacts the design of that code. For instance, were I to use "#include" and treat it like preprocessors do, then it means that every time I parse a file containing that directive, I need to inject the contents as if it were inline and coders can't use "#include print.p2asm" (for instance) in multiple source files. On the other hand, if there is an "import"-like behavior, then the referenced code file is not injected. Just its symbols are, and the rest becomes linkable (so to speak). There are obviously trade-offs to each approach, but what I want is the latter approach.
Maybe nothing at all. I clearly view the place of ASM code in the P2 software ecosystem differently than many of you here. My original question was simply whether such an alternative existed. I don't want to impose changes on anyone else, and I don't expect to be in agreement with everyone on this topic. Certainly, if a more universal standard were to be defined, I'd prefer Chip to be the one to do it (or, in lieu of that, the community). And if there's no desire for this from anyone else but me, then that's fine too.
Addressing this separately, CON is section of Spin code. Along with VAR, OBJ, PUB, PRI, and DAT. These are all legacies of the P1, where the only way to run assembly code is to bootstrap it with Spin code. And modularization is spin-centric. Heck, assembly code sits inside a data block. And that's fine for P1. But P2 is something different. Assembly code can stand on its own. No host language required. I am looking for a format that is not just "Spin without VAR, OBJ, PUB, or PRI". In other words, a format unburdened by another language it no longer depends on.
I admit I was careless when I used "#define" above, as it inadvertently invokes other concepts (like the use of preprocessors) that get in the way of my intended question. I am looking for a format that uses "modern" programming concepts and is not just spin-but-not-spin. If it doesn't exist, then that's a perfectly acceptable answer to my original question.
(note: I have also come to realize during this conversation that, for others to use this new format in existing toolchains, it would potentially require abandoning their own idiomatic concepts (e.g. #include). And so maybe what I am asking for is really just too domain-specific to be shared across toolchains. And have therefore essentially answered my own question.
That said, I do see an opportunity here. I believe it's possible that the ASM code could stand on its own, be fully-featured, and still work hand-in-hand with Spin2. Admittedly, it might meant that Spin2 would have to change slightly, and it seems now would be the time to do it. For instance, imagine changing the Spin2 format as follows (and note that I am spitballing here):
Defined a new ASM section that is named similar to PUB/PRI.
Change OBJ to something more generic like REF or IMP(ort), and change the format so that it can reference another file and a symbol (or symbols) within it.
Formally define .spin files to contain all sections and .p2asm to have only CON, REF, ASM, and DAT blocks (inclusion of the other sections would be an error).
I don't know what the right approach is, admittedly. And Spin is Chip's language, not mine. So maybe he has no desire to do anything like this. And that's fine too.
What I'd suggest you do instead is to add a "preprocessor" to convert your vision of p2asm to the standard format. This would not necessarily be a traditional C preprocessor, but rather something like ratfor that translated a cleaned up version of Fortran to "standard" Fortran. That way you could convert code written in the assembly format you like into something that the other tools can accept.
When you say "standard file format", are you also talking about usage of things like #include? Or are you just referring to the Spin/Spin2 format as the standard format?
Regardless, I think I've come to the realization that the thing I want doesn't exist.
If I'm following you correctly, I like that approach. For my own assembler, I treat the files as-is (e.g. have import semantics instead of include preprocessor directives). To use the code with other toolchains, I'd write a converter that others could use to create a valid .spin file (or whatever format you are stating above to be standard).
Assembly code can get pretty big now and I need some way to jump between sections.
SpinEdit (and hopefully the Prop Tool) shows a list of sections that you can jump to by clicking on.
It gave an error on this section of the USB keyboard/mouse driver, that I fixed with the ORG/END:
PRI mywrpin_(mode, pin) org wrpin mode,pin end { #ifdef __SPIN2CPP__ {++ pinwr(pin, mode); } #else wrpin_(mode, pin) #endif }It seems that __SPIN2CPP__ is not defined (should it be?) and wrpin_ appears to not be implemented...
That would certainly be useful, and I've seen assemblers with library supporting OBJ files that the linker can remove unused, often on a multi-pass basis.
Some linkers also can try to overlay local vars, on a who-calls-who basis.
I'm not sure where the current P2 Assemblers fit on linking - they may expect to 'see' all source code.
As for "include" capability, I don't see what is wrong with using a C-style pre-processor to achieve that. This also makes it a "standard" - and one that nearly everyone would be familiar with.
As for "import" style behaviour, this is not typical assembler functionality, but linker functionality - as @jmg points out.
Spin's confusion of assembly, compilation and linking may have seemed like a good idea by Parallax to help newbies, because it reduced the number of tools they had to use - but until it was teased apart by others, it is what made supporting languages other than Spin on the P1 such a dog's breakfast.
Let's not fall back into this trap on the P2. We have a de-facto standard for PASM files - let's accept it and move on.
Ross.
I have my answer, and will indeed move on.