Assembler mnemonics and syntax
VonSzarvas
Posts: 3,450
in Propeller 2
This discussion was created from comments split from: Possible P2 Logos.
Comments
No appar
What kinds of improvements do you guys think are needed on assembler mnemonics and syntax?
Make it so that anyone just picking up the chip can start using standard ports to interface to things easily.
I know you can include whatever objects you want to get those now on P1, but it should just be built in. The way things are on the P@ those protocols can all be included in the runtime as needed by the compiler. In fact, one Core(cog) can run Spin, do the serial, and/or I2C, and still be fine.
Above I think there was mention of change COGINIT to COREINIT, (ie a COG to CORE sweep) for example, and in another thread for another Assembler there was mention of 'auto-promote' of immediates to 32b
- all things designed to reduce the times any user has to reach for the manual...
Is it worth standardising on a single assembler, on github ?
Same applies to CALL and the generic JMPRET, obviously. Of course, this assumes that the jump commands mimic those of the P1. Maybe they don't; I haven't studied them.
Otherwise, I wouldn't change a thing. But add macros if it fits your time budget.
-Phil
Perhaps again the stickers
+1
Macros are very handy indeed and make quite a bit of difference. It's the difference between programming with assembly language or programming in assembly language.
Same with the jmp/call #label and while I do appreciate why it's done that way it would certainly help new ones to adapt if they could code "jmp label" rather than "jmp #label" and also "jmp (label)" for when the code needs to use the register for the indirect address.
btw Chip - do you want to start a new thread then?
I'd like to see Pnut have full command line support for use with other editors and other language tools.
Macros would be nice too.
Pushing my luck and being a bit cheeky, maybe the source code be OPENED for Pnut so it can be ported to all platforms.
Anyhow wasn't Openspin created from rewriting X86 code to C?
The same could be done again maybe this time to Python.
Having spent an inordinate amount of time recreating the functionality of ASM projects in C, for which there was no design documentation, I'm convinced that is not the best way to proceed. A compiler should be built from a formal language specification.
PNut is a "wrapper" is written in Delphi that talks to that ASM code to do the compiles, similar to how PropTool (and Propellent) did for the P1 version.
There is no formal language spec for Spin or Spin2, and I doubt Chip will do that. I'm not even sure it's really possible with how the PASM syntax conflicts with the Spin syntax and they are in the same file together.
The rest is an excellent syntax. Would hate to see it get cluttered up and harder to read.
The MCU Assembler I'm using here supports
FSIN(x), FCOS(x), FTAN(x), FATAN(x), FLN(x), FEXP(x), FSQR(x) and FSQRT(x)
which could be nice to see in a P2-ASM ?
there are also these works
https://github.com/davehein
https://github.com/totalspectrum
https://github.com/parallaxinc/OpenSpin
I've never used a Python-coded Assembler - does anyone have any speed benchmarks for Python as Assembler ?
I did dabble in fasmg, which is a script-based assembler, and that's very powerful, but not especially fast.
After waiting for FPGA tools, a minute is a snap.
But once again, we need to move this to its own thread.
Well, there are already p2asm and fastspin which are both portable and run on lots of platforms.
https://blog.gopheracademy.com/advent-2016/peachpy/
Claims : PeachPy is a Python-based framework for writing modules in assembly. It automates away some of the details and allows you to use Python to generate repetitive assembly code sequences.
https://github.com/Maratyszcza/PeachPy
PeachPy x86-64 assembler embedded in Python - with 362 commits and 11 contributors, that's quite well supported.
Currently x86 centric, still getting my head around if this makes sense as a Prop2 centric variant ?
Another search leads to
http://dman95.github.io/SASM/english.html
Looks to be an ASM-centric IDE, with Debug support built in,
https://github.com/Dman95/SASM 272 commits, 9 contributors
and conditional assembly.
As far as I know they are both complete -- at least, I'm not aware of any opcodes not supported by either, and I think they can both compile all the major samples (including the ROM). I can't speak for Dave Hein, but certainly I would regard any missing opcodes in fastspin as a bug and fix them if reported.
Eric
Use fastspin
p2asm also has a mode where it generates a relocatable object file. In that mode it also supports a small number of GAS pseudo-ops. Since these pseudo-ops start with a "." character I had to disable the use of local labels in this mode. However, local labels are still available when not in the object mode, and generating a binary file. Eventually, I may add GAS macros and conditional assembly features in the future if there is enough interest.
It seems avoiding direct conflicts with GAS is a smarter thing to be doing ?
So that means PNut (x86 asm?) can be retired ?
I thought that already had moved (somewhat?) along the Spin2 features path, that Chip has mentioned before ?
Sure, not a formal language definition, but certainly new features ?
It also seems sensible to track a P1 Spin improvement, even if that needs a not-from-ROM load step ?