Shop OBEX P1 Docs P2 Docs Learn Events
PNut and p2asm and other P2 tools — Parallax Forums

PNut and p2asm and other P2 tools

Peter JakackiPeter Jakacki Posts: 10,193
edited 2018-05-25 05:36 in Propeller 2
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:
fe97c     fc64417c 		wrlong 	rxwrC,#rxrd
EDIT: it does not seem to work with an immediate source of 9-bits though.....

«1

Comments

  • A couple of nice features that p2asm could have is listing the hex for bytes/words/longs in their respective mode and listing them over multiple lines if need be.
    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?
  • jmgjmg Posts: 15,140
    A couple of nice features that p2asm could have is listing the hex for bytes/words/longs in their respective mode and listing them over multiple lines if need be.
    At present if I say "word word1,word2,word3,word4" it will only list a single long as "word2word1".

    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'
    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.

    It would be unusual for any assembler to not have an include directive ?

  • jmgjmg Posts: 15,140
    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?

    You mean other than fixing the symbol limit in PNut, and rebuilding ?

  • jmg wrote: »
    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?

    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.

  • cgraceycgracey Posts: 14,131
    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:
    fe97c     fc64417c 		wrlong 	rxwrC,#rxrd
    
    EDIT: it does not seem to work with an immediate source of 9-bits though.....

    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.
  • cgracey wrote: »
    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 :) about reserving codes for these possibilities. Fair enough as I coded them as indirects for the moment.

    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.
  • cgraceycgracey Posts: 14,131
    cgracey wrote: »
    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 :) about reserving codes for these possibilities. Fair enough as I coded them as indirects for the moment.

    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.
  • Peter,
    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.
  • cgraceycgracey Posts: 14,131
    If you got the "RANDOMLY ACCESSING HUB RAM" section in the Google Doc, you can see the encodings for the RDxxxx/WRxxxx instructions.
  • A couple of nice features that p2asm could have is listing the hex for bytes/words/longs in their respective mode and listing them over multiple lines if need be.
    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?

    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:
    fastspin -2 myfile.spin2
    
    to produce myfile.binary, or
    fastspin -2 -l myfile.spin2
    
    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
  • FYI
    fe97c     fc64417c 		wrlong 	rxwrC,#rxrd
    
    Would be decoded as
    000: FC64417C                  WRLONG  $20,PTRA--[4]
    

  • ozpropdev wrote: »
    FYI
    fe97c     fc64417c 		wrlong 	rxwrC,#rxrd
    
    Would be decoded as
    000: FC64417C                  WRLONG  $20,PTRA--[4]
    

    Exactly what I didn't want! :)

    Eric - thanks, I will check out fastspin.
  • Peter,

    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.
  • Dave Hein wrote: »
    Peter,

    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.
    I wonder if there is a way to get the GCC toolchain to use p2asm instead of the binutils assembler. It's a shame that a big part of moving GCC to the P2 will be porting binutils when there are already several working assemblers for P2. The problem is that we would need ELF support in p2asm and the ability to generate relocatable objects.

  • Dave HeinDave Hein Posts: 6,347
    edited 2018-05-25 20:28
    One approach would be to try to integrate the p2gcc tools into the PropGCC tools. So this would create yet another assembler for the P2 using gas. I've started looking at assembling the existing PropGCC library using p2asm. Some portion of the library assembles without any changes. Some of library requires very minor changes, and some part of it may require a bit more modification.

    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.
  • rjo__rjo__ Posts: 2,114
    over my head or under my radar... not sure which.

    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.








  • Cluso99Cluso99 Posts: 18,066
    P2 doesn't require you to learn all the extras baked in.

    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.
  • I'm really in need of an include directive right now as I finalize the source so I've broken off include files with a master file that the m4 preprocessor will build a .spin2 file with. So for me a simple script runs m4, p2asm, and p2load and of course products the final .spin2 file. Now there is no need for me to copy & paste other sections or try to remember if the code I'm looking at is running in cog or hub etc. Just doing all this right now in case someone has a better idea! :)

    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
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2018-05-27 04:54
    Great! I now have my files broken up into maintainable sections and use p2asm/p2load and m4 like this:
    peter:BOOT$ ./bake p2rom
    

    "bake" is simply:
    m4 -I includes ./includes/p2rom.m4 > $1.spin2
    ./p2asm $1.spin2
    ./loadp2 $1.bin
    

    p2rom.m4 is simply:
    include(`header.inc')
    include(`booter.inc')
    include(`cluso.inc')
    include(`taqoz.inc')
    include(`threads.inc')
    include(`flash.inc')
    include(`sdcard.inc')
    include(`hubexec.inc')
    include(`kernel.inc')
    include(`dictionary.inc')
    include(`license.txt')
    

    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.
  • Dave Hein wrote: »
    One approach would be to try to integrate the p2gcc tools into the PropGCC tools. So this would create yet another assembler for the P2 using gas. I've started looking at assembling the existing PropGCC library using p2asm. Some portion of the library assembles without any changes. Some of library requires very minor changes, and some part of it may require a bit more modification.

    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.
  • macca wrote: »
    Dave Hein wrote: »
    One approach would be to try to integrate the p2gcc tools into the PropGCC tools. So this would create yet another assembler for the P2 using gas. I've started looking at assembling the existing PropGCC library using p2asm. Some portion of the library assembles without any changes. Some of library requires very minor changes, and some part of it may require a bit more modification.

    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.
    Yes, I put in most of that code and it is where I will start. I just have to read through the instruction document carefully to see what new instruction formats are in the current P2. I got as far as writing a program to parse Chip's instruction spreadsheet to produce tables to drive the instruction parser but got stalled after that. You're correct that LMM will not be needed but we will still need a crt0.s of some sort.

  • Using p2asm instead of gas might be a good idea -- the P2 instruction syntax is pretty complicated, so making gas compatible with PNut will be a pain. The tricky bit will be modifying p2asm to output ELF or some other object file format recognized by binutils. @"David Betz", I think we did something similar for NUON, where we used an in-house assembler ("llama") instead of gas. If I remember right, we ended up using COFF for the object file format because it was simpler than ELF.
  • ersmith wrote: »
    Using p2asm instead of gas might be a good idea -- the P2 instruction syntax is pretty complicated, so making gas compatible with PNut will be a pain. The tricky bit will be modifying p2asm to output ELF or some other object file format recognized by binutils. @"David Betz", I think we did something similar for NUON, where we used an in-house assembler ("llama") instead of gas. If I remember right, we ended up using COFF for the object file format because it was simpler than ELF.
    I don't think it's that bad producing ELF files. Should we ask Dave Hein to modify p2asm to generate ELF or COFF? Doesn't Dave also have a linker? Could that be used in place of the binutils linker?

  • I agree, ELF is probably not too bad and is pretty widely supported these days (back then it was still relatively new). Using the binutils linker does come with the advantage that all the other binutils tools (objcopy, objdump, nm, ar, etc.) come along "for free". I think it's probably not that hard to support the various P2 relocations; the tricky part is parsing the instructions, especially in a PNut compatible way.
  • Dave HeinDave Hein Posts: 6,347
    edited 2018-05-27 13:45
    I looked at the ELF specification when I first started p2gcc, and I found it quite complicated. So I development a simple object file format instead. However, since the P1 PropGCC uses ELF it would be good to continue using that for the P2. I do hope to take another look at ELF sometime in the near future.

    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.
  • David Betz wrote: »
    Yes, I put in most of that code and it is where I will start. I just have to read through the instruction document carefully to see what new instruction formats are in the current P2. I got as far as writing a program to parse Chip's instruction spreadsheet to produce tables to drive the instruction parser but got stalled after that.

    Is the update checked in ? If the instruction set is complete, maybe someone can pick from there and continue.
  • macca wrote: »
    David Betz wrote: »
    Yes, I put in most of that code and it is where I will start. I just have to read through the instruction document carefully to see what new instruction formats are in the current P2. I got as far as writing a program to parse Chip's instruction spreadsheet to produce tables to drive the instruction parser but got stalled after that.

    Is the update checked in ? If the instruction set is complete, maybe someone can pick from there and continue.
    I'm willing to work on this. I just don't want to put effort into something that isn't needed. There has been talk recently of having a meeting soon to plan the P2 GCC development effort. Hopefully, this issue will get resolved then.
  • ersmith wrote: »
    I agree, ELF is probably not too bad and is pretty widely supported these days (back then it was still relatively new). Using the binutils linker does come with the advantage that all the other binutils tools (objcopy, objdump, nm, ar, etc.) come along "for free". I think it's probably not that hard to support the various P2 relocations; the tricky part is parsing the instructions, especially in a PNut compatible way.
    Did we ever get gdb to work for Nuon? It looks like we not only need to generate ELF object files from p2asm but also DWARF debugging information if we want to be able to use gdb with P2 code.
  • I think gdb can work with COFF files (or anything else supported by the BFD library, as long as it has debugging information in it). DWARF sections in ELF is probably the best supported, so if we can do it that would be the way to go. Probably we want to walk (get basic linking working) before we run (get gdb working) :)
  • ersmith wrote: »
    I think gdb can work with COFF files (or anything else supported by the BFD library, as long as it has debugging information in it). DWARF sections in ELF is probably the best supported, so if we can do it that would be the way to go. Probably we want to walk (get basic linking working) before we run (get gdb working) :)
    I'm trying to figure out if we should go ahead with porting gas or if we should try to use p2asm. Just how hard is it to parse the P2 instruction set? There is already code in tc-propeller.c to parse some of the P2 syntax. Are there a lot of tricky features beyond what we already have?

Sign In or Register to comment.