I'll see about always outputting the list file. May not be able to get to it tonight, but I'll try.
Here are the symbols that might show up in a listing:
TYPE_CON Number 0040
TYPE_CON_FLOAT Number 0041
TYPE_REG Number 0042
TYPE_LOC_BYTE Number 0043
TYPE_LOC_WORD Number 0044
TYPE_LOC_LONG Number 0045
TYPE_VAR_BYTE Number 0046
TYPE_VAR_WORD Number 0047
TYPE_VAR_LONG Number 0048
TYPE_DAT_BYTE Number 0049
TYPE_DAT_WORD Number 004A
TYPE_DAT_LONG Number 004B
TYPE_DAT_LONG_RES Number 004C
TYPE_HUB_BYTE Number 004D
TYPE_HUB_WORD Number 004E
TYPE_HUB_LONG Number 004F
TYPE_OBJ Number 0050
TYPE_OBJPUB Number 0051
TYPE_OBJCON Number 0052
TYPE_OBJCON_FLOAT Number 0053
TYPE_METHOD Number 0054
Okay. I got the string() technique improved so it doesn't require patching and now takes only two bytes of overhead, instead of four bytes. It allowed me to get rid of a lot of stuff in the compiler that was carried over from Spin1.
There should be no more string trouble. Here is the newest PNut_v34d:
Rayman, at this time, inline assembly code needs a RET, which could be a _RET_.
Maybe I should add a RET after the user's code.
At the cost of one less instruction for inline code I think that is the safest and it won't preclude users from doing their own RETs wherever they need to. Otherwise missing the RET at the end of an inline block is going to catch people a LOT unless there is a warning generated for it.
Rayman, at this time, inline assembly code needs a RET, which could be a _RET_.
Maybe I should add a RET after the user's code.
At the cost of one less instruction for inline code I think that is the safest and it won't preclude users from doing their own RETs wherever they need to. Otherwise missing the RET at the end of an inline block is going to catch people a LOT unless there is a warning generated for it.
I agree. I'll have the interpreter tack a RET onto the end of the user's PASM code.
My vga file compiles and gets through the print fine now.
But, there's no image on the monitor...
Seems there's something wrong with the VGA output now.
I just looked at vsync and hsync on a scope and it looks fine...
Update: VGA output is back when I disable the cursor drawing...
I had to do a lot of PASM tricks to get the cursor to work, there's a lot of stuff to go wrong there...
I have some of these in there:
CursorJump call #\DoCursor1 'need absolute jump here
Ok, seems the VGA driver itself is outputting pixels when cursor drawing is disabled.
But, the cog that builds the scanlines is broke.
And the shared LUT cog that is supposed to dynamically update LUT colors is also broke...
But, looks like they are not being started at the right location...
If I move them into Spin, they appear to start correctly (although still appear to be using bad array pointers).
So, this at least starts the scanline cog correctly:
> @Rayman said:
> Looks to me like addressing is all messed up...
>
> Cogs are trying to start at the wrong places and the pointers to arrays are all wrong...
>
> Here's one symptom:
> My VGA driver cog is attempting to start two other cogs like this: coginit #Scan_Cog,##@ScanlineStart coginit #Color_Cog,##@ColorDriverStart
>
>
> But, looks like they are not being started at the right location...
>
> If I move them into Spin, they appear to start correctly (although still appear to be using bad array pointers).
> So, this at least starts the scanline cog correctly: PUB Start(pMousexy):cog cog:=VGA_Cog coginit(cog,@VGA_Driver, pMousexy) coginit( Scan_Cog,@ScanlineStart, pMousexy)
Rayman, because Spin2 builds objects and stacks them together, there is no absolute addressing at compile time.
You have a few options...
Spin2 can always resolve absolute addresses at runtime using @symbol. This pointer can be passed to cogs via COGINIT, where it winds up in PTRA.
Cogs can initially get the hub address of their code in PTRB. A PTRB offset to hub assets can be used to determine their location. See how the VGA and HDTV drivers get the address of their font data.
In DAT sections, you can make address tables and use @@table[index] to get absolute addresses:
[code]
DAT
table long @asset0, @asset1, @asset2
asset0 byte "hello",0
asset1 byte "today",0
asset2 byte "box",0
[/code]
Should I be able to add ptrb to address to get absolute address like this:
DAT 'VGA_Driver 'vsync and hsync normally low
orgh
org 0
VGA_Driver
SETLUTS #1 'Let color cog take care of LUT
mov pa,##@ScanlineStart
add pa,ptrb
setq ptra 'pass mousex pointer to scanline driver
coginit #Scan_Cog,pa '##@ScanlineStart
Should I be able to add ptrb to address to get absolute address like this:
DAT 'VGA_Driver 'vsync and hsync normally low
orgh
org 0
VGA_Driver
SETLUTS #1 'Let color cog take care of LUT
mov pa,##@ScanlineStart
add pa,ptrb
setq ptra 'pass mousex pointer to scanline driver
coginit #Scan_Cog,pa '##@ScanlineStart
PTRB will be the absolute address from which the program was loaded, or started in the hub.
If ScanlineStart was declared relative to where the program came from, that would work. That's probably not the case, though.
You may need to pass the pointer via a Spin2-generated structure pointed to by PTRA. That way, the cog can get any number of addresses that it may need.
Rayman, I did not get around to looking at your two files yesterday. I imagine, at this point, your work has moved on to a new point. If you want to send me your current files, I can look at them. Just post them here.
If adding ptrb to it doesn't work, I guess I don't see what it's good for...
If both the LOC instruction itself and the target address are in HUB memory then "loc pa, #@target" should work without any fixup, since in that case LOC will be PC relative. But if the LOC is in COG or LUT then you'll have to add ptrb to the relative offset of the code base, something like what @Wuerfel_21 suggested above
Hmm... Or, better yet, maybe I can change the source term in the LOC instructions before launching the cog?
Looks like I'd need to change the lower 18 bits to the address that I need...
Actually, this would be great because I could then make code that works for both FastSpin and Spin2 by calling a routine that fixes all the LOC instructions when used with Spin2.
> @Rayman said:
> I'm curious as to whether whatever magic ersmith uses in FastSpin to get the addresses come out the way they to could be applied to Spin2...
>
> Is there a fundamental issue that prevents this?
Spin2 builds objects in a heirarchy, innermost to outermost. They are movable during compilation and even at run time. They only know the offsets to their internal assets. Their base address is a run-time matter which can be gotten using @. Spin2 is probably not going to get compile-time address resolution because it's counter to the whole concept of the implementation.
> @Rayman said:
> I'm curious as to whether whatever magic ersmith uses in FastSpin to get the addresses come out the way they to could be applied to Spin2...
>
> Is there a fundamental issue that prevents this?
Spin2 builds objects in a heirarchy, innermost to outermost. They are movable during compilation and even at run time. They only know the offsets to their internal assets. Their base address is a run-time matter which can be gotten using @. Spin2 is probably not going to get compile-time address resolution because it's counter to the whole concept of the implementation.
Now that is getting interesting. It would allow of dynamic loading modules from SD/Flash/HyperRam to say replace VGA by Scope, Editor by Compiler and back to Editor or other interesting things like overlays...
Getting absolute HUB addresses was a pain in P1 Spin, thus the triple @ was introduced by other Spin Compilers to solve exactly that issue. Maybe that could be (re)introduced to Spin2 (another compiler pass?) so that the same source code could compile with Spin2 and fastspin.
Chip,
We found on P1 there were some cases where the absolute hub address was required. That was one of the main drivers for best and homespun and they introduced the 3 x @.
If a third pass is required if 3 x @ is found, that would be fine.
While I cannot site the cases, it was a real requirement for some of us with more complex code. I am absolutely certain this will be a requirement for P2 too. Please bite the bullet and include it while these things are fresh in your mind.
I tried a bunch to get the triple @ to work in OpenSpin and because of how Chip's compiler worked, it was not really possible without major rewriting of parts of it and how it worked, including adding an additional pass.
The part that made it extra hard was that it needed to work as part of expressions.
I recall a couple of threads a long time ago about it with people explaining why it was needed and thinking that they could have just done things differently in the design of their programs to not need it. I've never run into a case where I needed it.
I think many of the people wanted it just because BST had it, not because they actually really needed it themselves. Only a few people were actually using it for something, I think one was a compiler that produced Spin and then compiled that with BST. Seems like a compiler could be changed to produce Spin that didn't need it.
Anyway, OpenSpin has been open source since it was released, and none of the people who really wanted triple @ ever bothered to even look at the code or offer help with the feature implementation.
Short version,
I don't think Chip needs to put triple @ in Spin2. If you really need it and want it, help add it. Or just use FastSpin if it gives you what you need.
(edit, he hasn't shared the compiler source, but I hope he does, so you all can see how it works and it's not like you think it does)
I find that the way it works currently in FastSpin is very convenient. I think it took Eric a few days to get it the way it is now...
If it can't or won't be made to work that way in Spin2, that's OK, but just adds some extra work for the programmer...
Comments
Yes, and by using ORG with different addresses, you can load code in different places. You can place code/data from $000..$137.
I'll see about always outputting the list file. May not be able to get to it tonight, but I'll try.
Here are the symbols that might show up in a listing:
There should be no more string trouble. Here is the newest PNut_v34d:
https://drive.google.com/file/d/1iF73rgf-Gl0pWAFFDDD91uQzOtLgL-d4/view?usp=sharing
Turned out it was pretty easy. Here is PNut_v34e which always saves the list file:
https://drive.google.com/file/d/1zRWVjAlzfDUXKwKK6I2tGJws8p6AU46N/view?usp=sharing
To run a .spin2 file: To flash and run a .spin2 file:
At the cost of one less instruction for inline code I think that is the safest and it won't preclude users from doing their own RETs wherever they need to. Otherwise missing the RET at the end of an inline block is going to catch people a LOT unless there is a warning generated for it.
I agree. I'll have the interpreter tack a RET onto the end of the user's PASM code.
But, there's no image on the monitor...
Seems there's something wrong with the VGA output now.
I just looked at vsync and hsync on a scope and it looks fine...
Update: VGA output is back when I disable the cursor drawing...
I had to do a lot of PASM tricks to get the cursor to work, there's a lot of stuff to go wrong there...
I have some of these in there:
Should that work?
But, the cog that builds the scanlines is broke.
And the shared LUT cog that is supposed to dynamically update LUT colors is also broke...
Cogs are trying to start at the wrong places and the pointers to arrays are all wrong...
Here's one symptom:
My VGA driver cog is attempting to start two other cogs like this:
coginit #Scan_Cog,##@ScanlineStart coginit #Color_Cog,##@ColorDriverStartBut, looks like they are not being started at the right location...
If I move them into Spin, they appear to start correctly (although still appear to be using bad array pointers).
So, this at least starts the scanline cog correctly:
PUB Start(pMousexy):cog cog:=VGA_Cog coginit(cog,@VGA_Driver, pMousexy) coginit( Scan_Cog,@ScanlineStart, pMousexy)> Looks to me like addressing is all messed up...
>
> Cogs are trying to start at the wrong places and the pointers to arrays are all wrong...
>
> Here's one symptom:
> My VGA driver cog is attempting to start two other cogs like this: coginit #Scan_Cog,##@ScanlineStart coginit #Color_Cog,##@ColorDriverStart
>
>
> But, looks like they are not being started at the right location...
>
> If I move them into Spin, they appear to start correctly (although still appear to be using bad array pointers).
> So, this at least starts the scanline cog correctly: PUB Start(pMousexy):cog cog:=VGA_Cog coginit(cog,@VGA_Driver, pMousexy) coginit( Scan_Cog,@ScanlineStart, pMousexy)
Rayman, because Spin2 builds objects and stacks them together, there is no absolute addressing at compile time.
You have a few options...
Spin2 can always resolve absolute addresses at runtime using @symbol. This pointer can be passed to cogs via COGINIT, where it winds up in PTRA.
Cogs can initially get the hub address of their code in PTRB. A PTRB offset to hub assets can be used to determine their location. See how the VGA and HDTV drivers get the address of their font data.
In DAT sections, you can make address tables and use @@table[index] to get absolute addresses:
[code]
DAT
table long @asset0, @asset1, @asset2
asset0 byte "hello",0
asset1 byte "today",0
asset2 byte "box",0
[/code]
Unfortunately, this is a major difference between Spin2 and Fastspin.
Hopefully, the same code will work for both one day.
On the bright side, I now see the usefulness of having PTRB loaded with hub address of code.
DAT 'VGA_Driver 'vsync and hsync normally low orgh org 0 VGA_Driver SETLUTS #1 'Let color cog take care of LUT mov pa,##@ScanlineStart add pa,ptrb setq ptra 'pass mousex pointer to scanline driver coginit #Scan_Cog,pa '##@ScanlineStartPTRB will be the absolute address from which the program was loaded, or started in the hub.
If ScanlineStart was declared relative to where the program came from, that would work. That's probably not the case, though.
You may need to pass the pointer via a Spin2-generated structure pointed to by PTRA. That way, the cog can get any number of addresses that it may need.
I guess I've been spoiled by being able to just do this in FastSpin:
To get the address of an array defined in HUB RAM.
Before I start the driver, can I change one of the longs in that DAT section to be equal to the pointer?
Say I have a working long in the driver DAT section like this:
and an array defined elsewhere like this:
Could I do this before starting the driver from inside the Spin start method:
Does that work?
Is LOC just useless in Spin2?
If adding ptrb to it doesn't work, I guess I don't see what it's good for...
org 0 CogCode loc pa,#\(@somewhere-@CogCode) add pa,ptrb ' Imagine code here somewhere long 1234Altough this just uses LOC as a glorified MOV.
I guess you can still do the usual Spin thing, in which you let Spin figure out the pointers and patch them into the cog code before launching it.
If both the LOC instruction itself and the target address are in HUB memory then "loc pa, #@target" should work without any fixup, since in that case LOC will be PC relative. But if the LOC is in COG or LUT then you'll have to add ptrb to the relative offset of the code base, something like what @Wuerfel_21 suggested above
Yes, you could certainly do that.
Looks like I'd need to change the lower 18 bits to the address that I need...
Actually, this would be great because I could then make code that works for both FastSpin and Spin2 by calling a routine that fixes all the LOC instructions when used with Spin2.
Is there a fundamental issue that prevents this?
> I'm curious as to whether whatever magic ersmith uses in FastSpin to get the addresses come out the way they to could be applied to Spin2...
>
> Is there a fundamental issue that prevents this?
Spin2 builds objects in a heirarchy, innermost to outermost. They are movable during compilation and even at run time. They only know the offsets to their internal assets. Their base address is a run-time matter which can be gotten using @. Spin2 is probably not going to get compile-time address resolution because it's counter to the whole concept of the implementation.
Now that is getting interesting. It would allow of dynamic loading modules from SD/Flash/HyperRam to say replace VGA by Scope, Editor by Compiler and back to Editor or other interesting things like overlays...
Getting absolute HUB addresses was a pain in P1 Spin, thus the triple @ was introduced by other Spin Compilers to solve exactly that issue. Maybe that could be (re)introduced to Spin2 (another compiler pass?) so that the same source code could compile with Spin2 and fastspin.
Enjoy!
Mike
We found on P1 there were some cases where the absolute hub address was required. That was one of the main drivers for best and homespun and they introduced the 3 x @.
If a third pass is required if 3 x @ is found, that would be fine.
While I cannot site the cases, it was a real requirement for some of us with more complex code. I am absolutely certain this will be a requirement for P2 too. Please bite the bullet and include it while these things are fresh in your mind.
The part that made it extra hard was that it needed to work as part of expressions.
I recall a couple of threads a long time ago about it with people explaining why it was needed and thinking that they could have just done things differently in the design of their programs to not need it. I've never run into a case where I needed it.
I think many of the people wanted it just because BST had it, not because they actually really needed it themselves. Only a few people were actually using it for something, I think one was a compiler that produced Spin and then compiled that with BST. Seems like a compiler could be changed to produce Spin that didn't need it.
Anyway, OpenSpin has been open source since it was released, and none of the people who really wanted triple @ ever bothered to even look at the code or offer help with the feature implementation.
I don't think Chip needs to put triple @ in Spin2. If you really need it and want it, help add it. Or just use FastSpin if it gives you what you need.
(edit, he hasn't shared the compiler source, but I hope he does, so you all can see how it works and it's not like you think it does)
If it can't or won't be made to work that way in Spin2, that's OK, but just adds some extra work for the programmer...