PNut/Spin2 Latest Version (v34z - Lots of DEBUG display stuff)

1121315171834

Comments

  • You're not ... !!!
  • Cluso99Cluso99 Posts: 16,661
    edited 2020-04-25 - 04:46:52
    ozpropdev wrote: »
    Cluso
    For immediate-branch and LOC address operands, "#" is used before the
    address. In cases where there is an option between absolute and relative
    addressing, the assembler will choose absolute addressing when the branch
    crosses between cog and hub domains, or relative addressing when the
    branch stays in the same domain. Absolute addressing can be forced by
    following "#" with "\".

    Your NOT crossing a domain so your call's will always be treated as relative.
    1. Still seems wrong.
    and
    2. Going to be a major trap for many!!!!! :( :( :(

    Only by looking at the hex code of the listing do you find it has used the wrong address. You see, spin has moved the code from where it compiled it, so the relative address is calculated incorrectly as far as I am concerned.
  • evanhevanh Posts: 9,964
    edited 2020-04-25 - 05:16:48
    Actually, if the target address is outside the compiled module then maybe it can be treated as crossing domains.

    PS: In the case of pure pasm2, though, there is no outside.

  • evanh wrote: »
    Actually, if the target address is outside the compiled module then maybe it can be treated as crossing domains.

    PS: In the case of pure pasm2, though, there is no outside.
    Possibly yes.

    I just think that this is a microcontroller, not a microprocessor. Here, engineers like to plan where everything is going to fit. We seem to be moving along the PC lines, where you no longer know what is happening, and bloat takes over. Just IMHO.
    Pity help the newbie trying to find these problems!
  • Relative can be more compact in theory.

    I don't see it as following the PC at all. X86 code traditionally was pretty darn absolute based. That may have changed in modern times but like most things PC, it only came belatedly.
  • Cluso99Cluso99 Posts: 16,661
    edited 2020-04-25 - 05:48:38
    evanh wrote: »
    Relative can be more compact in theory.

    I don't see it as following the PC at all. X86 code traditionally was pretty darn absolute based. That may have changed in modern times but like most things PC, it only came belatedly.
    The JMP # and CALL # have both relative and absolute variants (b18=R) and 20bit addresses (relative or absolute). It is these that caused me the latest grief :(
    But yes, where you have a compact djnz etc which has 9bit relative addresses, if you are outside the +/- 256 range then a jmp is also required.

    I haven't verified if the relative address changes from bytes to longs when in cog. In hub, the call/jmp are in bytes.
  • My comment of "compact in theory" was in reference to you drawing generalised comparisons with other architectures. It wasn't about the prop2.

  • cgracey wrote: »
    Today I took the Spin2 compiler, which is 13,600 lines of 80386 assembly, and converted the 2,270 lines containing all the equates and automatic symbols into Spin2 source. It's all data, no code, and compiles to 11KB. I want to get the parser working in Spin2, but I need all this data present for context. Here is the Spin2 source for this, so far.

    I added size overrides to BYTE/WORD/LONG expressions in DAT sections, so that you can generate data of a different size when needed. Good for symbol table data. This will be in the next release of PNut.exe:
    byte	"X_DDS_GOERTZEL_SINC1",0,	type_con,		long	$F007 << 16
    

    @cgracey How are you doing on implementing the Spin2 compiler in Spin2?

  • David Betz wrote: »
    cgracey wrote: »
    Today I took the Spin2 compiler, which is 13,600 lines of 80386 assembly, and converted the 2,270 lines containing all the equates and automatic symbols into Spin2 source. It's all data, no code, and compiles to 11KB. I want to get the parser working in Spin2, but I need all this data present for context. Here is the Spin2 source for this, so far.

    I added size overrides to BYTE/WORD/LONG expressions in DAT sections, so that you can generate data of a different size when needed. Good for symbol table data. This will be in the next release of PNut.exe:
    byte	"X_DDS_GOERTZEL_SINC1",0,	type_con,		long	$F007 << 16
    

    @cgracey How are you doing on implementing the Spin2 compiler in Spin2?

    It's coming along really well. I've got the symbol table stuff done and now I'm finishing up the code that converts source into elements, with type and value. Once that is done, the most fundamental matters are out of the way.
  • cgracey wrote: »
    David Betz wrote: »
    cgracey wrote: »
    Today I took the Spin2 compiler, which is 13,600 lines of 80386 assembly, and converted the 2,270 lines containing all the equates and automatic symbols into Spin2 source. It's all data, no code, and compiles to 11KB. I want to get the parser working in Spin2, but I need all this data present for context. Here is the Spin2 source for this, so far.

    I added size overrides to BYTE/WORD/LONG expressions in DAT sections, so that you can generate data of a different size when needed. Good for symbol table data. This will be in the next release of PNut.exe:
    byte	"X_DDS_GOERTZEL_SINC1",0,	type_con,		long	$F007 << 16
    

    @cgracey How are you doing on implementing the Spin2 compiler in Spin2?

    It's coming along really well. I've got the symbol table stuff done and now I'm finishing up the code that converts source into elements, with type and value. Once that is done, the most fundamental matters are out of the way.
    Have you had to make any changes in the Spin2 language to support your efforts?

  • Can PNut load binary files? I think it used to able to, but don't see how now...
  • OzPropDev showed me a way to do this using a couple of lines in Pnut. It was really easy, but I can't remember the details because i thought I would just remember. It was soemthing like an orgh, dat, and file instruction
  • Tubular wrote: »
    OzPropDev showed me a way to do this using a couple of lines in Pnut. It was really easy, but I can't remember the details because i thought I would just remember. It was soemthing like an orgh, dat, and file instruction

    DAT

    FILE "filename.ext"
  • cgracey wrote: »
    David Betz wrote: »
    @cgracey How are you doing on implementing the Spin2 compiler in Spin2?

    It's coming along really well. I've got the symbol table stuff done and now I'm finishing up the code that converts source into elements, with type and value. Once that is done, the most fundamental matters are out of the way.

    Does it still seem based no what you have so far like it should ultimately fit fairly easily in the P2 memory leaving plenty of space for a nice dev system environment to be added around it with text screen/serial interfaces and file system etc? i.e. Table sizes are scaling well and code is not growing uncomfortably large etc? I wonder what practical limits might need to be enforced based on number of active symbols/files/objects/included data etc. Hopefully this will all scale up ok with the Spin2 approach.
  • rogloh wrote: »
    cgracey wrote: »
    David Betz wrote: »
    @cgracey How are you doing on implementing the Spin2 compiler in Spin2?

    It's coming along really well. I've got the symbol table stuff done and now I'm finishing up the code that converts source into elements, with type and value. Once that is done, the most fundamental matters are out of the way.

    Does it still seem based no what you have so far like it should ultimately fit fairly easily in the P2 memory leaving plenty of space for a nice dev system environment to be added around it with text screen/serial interfaces and file system etc? i.e. Table sizes are scaling well and code is not growing uncomfortably large etc? I wonder what practical limits might need to be enforced based on number of active symbols/files/objects/included data etc. Hopefully this will all scale up ok with the Spin2 approach.

    The code size is only about 1.5KB, so far. There is 11KB of built-in symbol data, though. I think everything's going to fit easily. It would be nice to maybe have a HyperRAM, in order to simplify compilation of very large files.
  • That sounds good Chip. Yes maybe we can consider a RAM based filesystem stored in HyperRAM given what Rayman is doing with FAT on flash too. Sharing up to 16MB could become useful for very large builds and larger files being edited etc, even if it is mostly non-persistent unless copied back to SD or into flash. Reading/writing 512 byte sectors is going to be very efficient given the burst nature of HyperRAM.
  • @cgracey Are you going to make the source to the compiler available?
  • cgraceycgracey Posts: 13,078
    edited 2020-05-01 - 18:11:22
    David Betz wrote: »
    @cgracey Are you going to make the source to the compiler available?

    Of course. I am going to post something today that shows the parser working. It's not much code, at all, but forms the basis of a compiler.

    Being able to go from source file text to an ordered list of resolved elements is a huge thing.
  • cgracey wrote: »
    David Betz wrote: »
    @cgracey Are you going to make the source to the compiler available?

    Of course. I am going to post something today that shows the parser working. It's not much code, at all, but forms the basis of a compiler.

    Being able to go from source file text to an ordered list of resolved elements is a huge thing.
    Sounds great! I'm looking forward too seeing it. Since you're pretty confident that you will be able to get the compiler running directly on the P2, I'm wondering if there is really any need for a self-hosted BASIC interpreter for the P2.

  • sure it is.

    Mike
  • David Betz wrote: »
    cgracey wrote: »
    David Betz wrote: »
    @cgracey Are you going to make the source to the compiler available?

    Of course. I am going to post something today that shows the parser working. It's not much code, at all, but forms the basis of a compiler.

    Being able to go from source file text to an ordered list of resolved elements is a huge thing.
    Sounds great! I'm looking forward too seeing it. Since you're pretty confident that you will be able to get the compiler running directly on the P2, I'm wondering if there is really any need for a self-hosted BASIC interpreter for the P2.

    Well, take a look at this work I've done so far and you will see that it is within easy reach. Will post soon.
  • Chip,

    When calling P2ASM from spin...

    * Is/are PTRA and/or PTRB available for the assembly code to use (without save/restore)?

    * Is/are PA and/or PB available for assembly code to use (without save/restore)?

    * Are the 8 levels of the stack available (less 1 for the call to assembler) (without save/restore)?
  • @cgracey Can you point me to a description of the P2 byte codes? I'm working on a BASIC interpreter for the P2 and I'm thinking it might be a good idea to have it generate the same byte codes that Spin2 uses.
  • David Betz wrote: »
    Can you point me to a description of the P2 byte codes?

    This is most likely the only description, but it has every detail: spin2_interpreter.spin2

  • Ariba wrote: »
    David Betz wrote: »
    Can you point me to a description of the P2 byte codes?

    This is most likely the only description, but it has every detail: spin2_interpreter.spin2
    Yeah, I know about the interpreter source code. I don't really want to have to distill the byte code instruction set description from that code. I was hoping for a document describing the byte codes.

  • David Betz wrote: »
    Ariba wrote: »
    David Betz wrote: »
    Can you point me to a description of the P2 byte codes?

    This is most likely the only description, but it has every detail: spin2_interpreter.spin2
    Yeah, I know about the interpreter source code. I don't really want to have to distill the byte code instruction set description from that code. I was hoping for a document describing the byte codes.

    The source code IS the document, aside from a list of bytecodes in the compiler.
  • Cluso99 wrote: »
    Chip,

    When calling P2ASM from spin...

    * Is/are PTRA and/or PTRB available for the assembly code to use (without save/restore)?

    * Is/are PA and/or PB available for assembly code to use (without save/restore)?

    * Are the 8 levels of the stack available (less 1 for the call to assembler) (without save/restore)?

    Your PASM code called from Spin2 can use PA, PB, PTRA, PTRB, and six (I think) levels of the hardware stack.

  • cgracey wrote: »
    David Betz wrote: »
    Ariba wrote: »
    David Betz wrote: »
    Can you point me to a description of the P2 byte codes?

    This is most likely the only description, but it has every detail: spin2_interpreter.spin2
    Yeah, I know about the interpreter source code. I don't really want to have to distill the byte code instruction set description from that code. I was hoping for a document describing the byte codes.

    The source code IS the document, aside from a list of bytecodes in the compiler.

    I'm afraid I don't have the time or patience to distill the byte code definitions from the source code. I guess I'll just stick with my own byte code interpreter for now.

  • cgracey wrote: »
    Cluso99 wrote: »
    Chip,

    When calling P2ASM from spin...

    * Is/are PTRA and/or PTRB available for the assembly code to use (without save/restore)?

    * Is/are PA and/or PB available for assembly code to use (without save/restore)?

    * Are the 8 levels of the stack available (less 1 for the call to assembler) (without save/restore)?

    Your PASM code called from Spin2 can use PA, PB, PTRA, PTRB, and six (I think) levels of the hardware stack.

    Great :)

    For the SD pasm driver I need 5 levels including the call from spin and just PTRA or PTRB.
  • David Betz wrote: »
    cgracey wrote: »
    David Betz wrote: »
    Ariba wrote: »
    David Betz wrote: »
    Can you point me to a description of the P2 byte codes?

    This is most likely the only description, but it has every detail: spin2_interpreter.spin2
    Yeah, I know about the interpreter source code. I don't really want to have to distill the byte code instruction set description from that code. I was hoping for a document describing the byte codes.

    The source code IS the document, aside from a list of bytecodes in the compiler.

    I'm afraid I don't have the time or patience to distill the byte code definitions from the source code. I guess I'll just stick with my own byte code interpreter for now.

    Sometimes I need to reshuffle the bytecode values, too.
Sign In or Register to comment.