P2 Macro-Assembler, anyone needs this?

Surac

I have written compilers and analyzers for many years now. My last Project was a COBOL compiler for Volkswagen here in Germany.

Is a Macro-Assembler a needed feature in the P2 world, or do you think it is a wast of time because there are enough ways to program the P2

Please tell me what you think

rogloh

It could probably only be useful if the code it generates was self-contained, relocatable and could be then packaged as blobs into other environments for launching COGs. For example if it could create simple object code that could be packaged for something else like MicroPython to run etc. But maybe lot is needed for that to work. The main issue is that each existing tool like PNut and FlexProp sets up its own environment / memory layout etc so it's hard to share object code right now.

Wuerfel_21

Certainly, macro assemblers are great!

You can already do simple C-sytle macros in FlexSpin (which is how it internally implements ASMCLK, btw), but that's obviously not very flexible or good.

I wrote my own P1 XMM macro assembler for Projekt Menetekel. It is an internal Ruby DSL (or in layman's terms, a bunch of functions that look like assembler instructions/directives on an object that I instance_eval the asm files on), so it is absurdly powerful and flexible (Opening a CSV/JSON/PNG/etc file and emitting code/data based on the content is really neat), but the syntax is somewhat odd and some mnemonics are different than the official ones (mostly by choice, but OR/AND had to be renamed ORA/ANDP to not conflict with Ruby keywords). It'd have to be even more odd for a general P2 assembler (as opposed to targeting a specific P1 XMM kernal), so that approach may not be very useful.

ersmith

@rogloh said:
It could probably only be useful if the code it generates was self-contained, relocatable and could be then packaged as blobs into other environments for launching COGs. For example if it could create simple object code that could be packaged for something else like MicroPython to run etc. But maybe lot is needed for that to work. The main issue is that each existing tool like PNut and FlexProp sets up its own environment / memory layout etc so it's hard to share object code right now.

For pure assembly language neither PNut nor flexspin adds any environment or memory layout -- if you're just using either of them as an assembler then what you write is what you get.

One thing we are missing at the moment is a "native" assembler that runs on the P2 itself.

rogloh

@ersmith said:

For pure assembly language neither PNut nor flexspin adds any environment or memory layout -- if you're just using either of them as an assembler then what you write is what you get.

One thing we are missing at the moment is a "native" assembler that runs on the P2 itself.

You're right, if you write in pure PASM2 you can control things, but we often write in SPIN2 or in C. It's these cases that make it harder to link in arbitrary object code built with another toolchain, unless it could get built with full relocatability in mind (eg. uses only relative jumps and not absolute addresses) and there is some suitable spare (and preferably contiguous?) memory area available to execute it and store its data.

A native assembler would be nice.

msrobots

what we really need is a COBOL compiler for the P2.

Just saying...

Mike

Cluso99

Eric's FlexProp is a fantastic tool.
AFAIK it doesn't have macro's for p2asm, and compiles spin2 to pasm rather than using the spin2 interpreter. It's the last point that stops it being a total replacement for pnut/proptool.

A p2 pasm macro assembler would be great, and sadly missing

For pnut/proptool, perhaps what we need is a pre-compiler that will perform the #include and #ifdef functions, plus a p2asm macro expander. This output could then be passed to either pnut/proptool or flexprop for compiling.

I've been working on converting pnut (written in x86 assembler) into a python style HLL using a python program to do the conversion (ie no manual intervention as pnut continues to be developed). Sadly I have not had time for the past 6 weeks to progress this further, but hoping to get time to resume this project shortly.
We need to get pnut into an HLL so we can compile for various platforms including P2 itself, and then to add the basic missing features.
PM me if you think you could help.

Peter Jakacki

I have my p2 assembler resident with TAQOZ on the P2 and I also have all the file system and editor and VGA output as well for a standalone system. However, there is a lot of polishing yet to do on my p2asm as I really only use it for inline code but there is no reason why I can't assemble from a file and output a listing and object file. Since it is Forth based, it is inherently "macro" capable in that I can either write a one-liner or write Forth code that emulates traditional macros. Best of both worlds.

But please go ahead and write the macroassembler although you could concentrate on the preprocessing (including the includes) and the macros first and perhaps rely on Dave Hein's p2asm that I use to compile my code or Eric's excellent and prodigious works.

evanh

Something for tidying up the ALTxx instructions would be nice. ALTI might be too tricky but the rest should tidy up nicely.