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.
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!
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.
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.
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?
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.
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?
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
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
@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.
@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?
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.
@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.
@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.
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.
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.
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.
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.
Comments
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.
PS: In the case of pure pasm2, though, there is no outside.
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!
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.
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.
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.
DAT
FILE "filename.ext"
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.
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.
Mike
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.
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)?
This is most likely the only description, but it has every detail: spin2_interpreter.spin2
The source code IS the document, aside from a list of bytecodes in the compiler.
Your PASM code called from Spin2 can use PA, PB, PTRA, PTRB, and six (I think) levels of the hardware stack.
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.
Great
For the SD pasm driver I need 5 levels including the call from spin and just PTRA or PTRB.
Sometimes I need to reshuffle the bytecode values, too.