PNut and p2asm and other P2 tools
Peter Jakacki
Posts: 10,193
I thought I'd start this thread and although it was about a comment about PNut, it also crosses over into p2asm and perhaps other tools.
My current ROM file can no longer be assembled by PNut since it exceeds the 1024 dat symbols that are handled by PNut. Any quick way around this other than trimming?
p2asm assembles this fine, but I have to load it as a 1M obj file so that it can replace hub ROM at $FC000. Do the p2gcc tools include a loader that handles this? (I need to check mind you found loadp2)
Also noticed some discrepancies between PNut and p2asm. I had a "callpa #"x",#xxxx" operation where the address lay in cog memory but PNut said the "relative jump" was too far whereas p2asm compiled it fine as it should since I though it was only a 9-bit cog address. This might be a documentation problem?
Also wrlong with an immediate source seems to be limited to 8-bits in PNut but p2asm handles an immediate of $17C fine as it should.
PNut: Constant must be from 0 to 255
p2asm:
My current ROM file can no longer be assembled by PNut since it exceeds the 1024 dat symbols that are handled by PNut. Any quick way around this other than trimming?
p2asm assembles this fine, but I have to load it as a 1M obj file so that it can replace hub ROM at $FC000. Do the p2gcc tools include a loader that handles this? (I need to check mind you found loadp2)
Also noticed some discrepancies between PNut and p2asm. I had a "callpa #"x",#xxxx" operation where the address lay in cog memory but PNut said the "relative jump" was too far whereas p2asm compiled it fine as it should since I though it was only a 9-bit cog address. This might be a documentation problem?
Also wrlong with an immediate source seems to be limited to 8-bits in PNut but p2asm handles an immediate of $17C fine as it should.
PNut: Constant must be from 0 to 255
p2asm:
fe97c fc64417c wrlong rxwrC,#rxrdEDIT: it does not seem to work with an immediate source of 9-bits though.....
Comments
At present if I say "word word1,word2,word3,word4" it will only list a single long as "word2word1".
With assembling this ROM I need to have all sections together in the one file but that is such a nuisance to maintain and edit. It would be nice if p2asm accepted the "include" directive so that the ROM file would just be the includes to the other files.
I know it's an ask but what do you think Dave?
Most ASM listings have a truncated form, I think to allow for comments and to keep inside printer paper widths.
Yes, that sometimes can be a pain, and I've split into more lines if I've needed to see listed values.
I guess some switch to extend the listing, could be 'nice to have'
It would be unusual for any assembler to not have an include directive ?
You mean other than fixing the symbol limit in PNut, and rebuilding ?
Chip is so familiar with the source code for PNut it and he really doesn't have time to redo it all. I've managed to believe what PNut says about coding errors and incorporate than into my source so that p2asm and p2load do the job for me very well, although p2asm allowed what I thought was a legal 9-bit immediate source for wrlong, but that doesn't seem to work as the documentation says it should.
I will fix PNut to handle over 1024 DAT symbols. I didn't know I had put such a limitation into it. I will be able to do this in 24 hours from now.
As far as >8-bit constant addresses in RDxxxx/WRxxxx, those are reserved for the PTRA/PTRB possibilities. You can hard-address hub $00000..$000FF, only.
Although p2asm allowed the 9-bit immediate, the code didn't work and I now seem to remember some talk a long time ago
I've come across the 1024 DAT symbol limit very often in the past. Now Chip, what do you think about adding an include directive? That would be a neat feature.
An INCLUDE would be really nice. It would be best handled as a pre-processor function, though. Once the PNut compiler is looking through source code, it needs it all present at once.
OpenSpin doesn't have the symbol limit, and it has #include. I know this doesn't cover your current need, but once I get the P2 version working, it will.
Have you tried fastspin on it? It does show all the words in listings, and it has #include. Unfortunately I see that they don't play well together: -- it displays all the data from the #included file in the listing, but doesn't display the source code. I'll try to fix that.
fastspin is at https://github.com/totalspectrum/spin2cpp/releases/latest. Or, you can grab the GUI version from https://github.com/totalspectrum/spin2gui/releases/latest. The GUI uses loadp2 to run the compiled binary.
The command line version gets used like: to produce myfile.binary, or to produce myfile.lst The -2 is for P2 mode; the default is P1 mode.
I just noticed that fastspin has the same bug/feature as p2asm in that it will accept immediates above $ff for rdlong/wrlong, but they won't do what you may expect.
Eric
Exactly what I didn't want!
Eric - thanks, I will check out fastspin.
I'll look into implementing the features you suggested into p2asm. I haven't implemented rigorous error checking, but I can add some checking for specific errors. Currently I only check for syntax errors.
Previous versions of loadp2 allowed for loading to an address other than zero. However, when I quit using a secondary loader I lost this feature. In the latest version I did a quick kludge to allow executing a p2gcc C program at an arbitrary address, but this doesn't work for general PASM programs. I'll add the secondary loader back into the next version so this feature works again.
p2gcc uses s2pasm along with p2asm to assemble PropGCC assembly files. It's possible to incorporate s2pasm into p2asm so it can assemble native PropGCC assembly files.
p2asm supports a -o option that is used to generate object files instead of binary files. The p2asm object file contains a symbol table that specifies global and unresolved symbols. It's essentially a poor man's ELF file. This could probably be converted into a standard ELF file.
p2link is used to link object files together to produce an executable binary file. I want to add an option to p2link to include a symbol table along with the binary code. This would be use for debugging, and also to provide a way to relocate a binary file to a different address so that it doesn't always have to be run from location zero.
If I hadn't had the experience of using the P123 early on in the discussion, right now I would have the distinct impression that the P2 is next to impossible to program for a novice or amateur... and yet, I know that this is simply NOT true.
It is much, much easier and more productive to get stuff done with P2(asm) than it ever was with either Spin1 or Pasm. This seems hard to believe looking at our favorite Forum... but it is absolutely true.
I think P2(asm) is so easy because of all of the "helper" functions, which reduce the size of the code... and the very simple, and very elegant design of the language.
At this point, from my perspective all that is required is to give PNUT the ability to compile code spread over several files. To me, the only bad thing about PNUT is that you end up with one huge file that is difficult to edit or read.
All the basic P1 ASM instructions are there excepting the NR option. So it's quite simple to progress to P2.
Then, as you require, you can add some extra instructions to help your code.
Then learn the few hubexec tricks and you don't have the 2K limit (now 4K with lut execution).
The ROM basically has FDX functions inbuilt, and basic SD calls too.
IIRC we are expecting first silicon in October. If all goes well, we could see the extra dice packaged up to cover any initial demand shortly thereafter.
At the moment these are the includes but they may be broken off into smaller maintainable sections:
p2rom.m4
header.inc
booter.inc
cluso.inc
taqoz.inc
threads.inc
flash.inc
sdcard.inc
hubexec.inc
kernel.inc
dictionary.inc
"bake" is simply:
p2rom.m4 is simply:
m4 also allows me to create macros and other useful stuff as a preprocessor, but whatever the original include file, it still produces a spin2 file that anyone can use.
You may know, prop-gcc already supports p2 in the old incarnation. Why don't start from an old source that can be compiled with it and see what needs to be updated ?
Some source code pointer:
binutils/gas/config/tc-propeller.c
binutils/opcodes/propeller-dis.c
binutils/opcodes/propeller-opc.c
gcc4/gcc/config/propeller/
There is a crt0_lmm2.s here that maybe is no longer needed since, if I'm not wrong, P2 supports LMM natively.
p2gcc does use a linker called p2link. It works with the object file format produced by p2asm when specifying the -o option. p2link can also handle libraries. A library is just a concatenation of multiple object files. A library file is produced with cat, and using a .a extension on the output file. As an example, a library can be built from the object files file1.o, file2.o and file3.o by typing "cat file1.o file2.o file3.o >library.a".
Currently, p2link puts code and data into one section. A high priority item on my TODO list is to link into different sections for text, data and bss. This will allow me to remove the kludge that I use for linking data. When I link data, each object file has it's own data storage for a variable or array. The linker adjusts the data addresses of all the objects to use the data array where the variable or array is initialized to explicit values. So that leaves wasted areas in memory, but the kludge does work.
As I started working with the existing PropGCC library code I noticed that there are accommodations for P2 already in it. My intention is to preserve and use that as much as possible.
Is the update checked in ? If the instruction set is complete, maybe someone can pick from there and continue.