Seems that could be useful for debugging with breakpoints...
Maybe adding a breakpoint would cause the PropTool to swap out that method with one that includes something that happens at the breakpoint...
By that logic, #include_once doesn't sound too hard either. Store the filenames, the length of the file, and the hash/crc of the contents in the file. If they're all equal, don't include it again.
By that logic, #include_once doesn't sound too hard either. Store the filenames, the length of the file, and the hash/crc of the contents in the file. If they're all equal, don't include it again.
How could the length and hash possibly differ if they're the same file? Isn't there any way on Windows to tell if two different paths are the same file, even if there are symlinks or shortcuts or junctions complicating things?
By that logic, #include_once doesn't sound too hard either. Store the filenames, the length of the file, and the hash/crc of the contents in the file. If they're all equal, don't include it again.
How could the length and hash possibly differ if they're the same file? Isn't there any way on Windows to tell if two different paths are the same file, even if there are symlinks or shortcuts or junctions complicating things?
That's what i was thinking to make it simpler, because of those blasted virtual files and directories. Or handle the case of two files with the same name, in different directories, with different content.
Thought to just keep it simple as this is being written in 486 assembler.
I don't think I will jump into this, just yet. I need to get the documentation done for the tool, first.
Eventually, I will singulate duplicated routines, if there are any. An include-file would make it very easy to bring functionality into an object, without having to bring an object in. For example, some routines that just prints numbers and strings.
...
Thought to just keep it simple as this is being written in 486 assembler.
The Spin2 compiler is almost 13,000 lines of '386 code now, all in a single file. It uses only two include files, one for the interpreter and one for the flash programmer. Both of those files just define bytes that make up the respective programs.
Indeed, a stand alone preprocessor should work well. There's one called mcpp that I use for FlexC and that can be built as a library (easy to call, I think even from assembly).
There's also a simpler preprocessor that fastspin shares with openspin and which is less C specific.
Is there some kind of high level support for qrotate and qvector in spin2?
ROTXY(x,y,t) 'rotates (x,y) by t, returns x and y
POLXY(r,t) 'converts polar to cartesian, returns x and y
XYPOL(x,y) 'converts cartesian to polar, return rho and theta
Interesting... Prop manual says the "step" value is re-evaluated in every loop.
Is true for "Start" and "finish" values as well?
I guess so, but Prop Manual doesn't seem to say...
Interesting... Prop manual says the "step" value is re-evaluated in every loop.
Is true for "Start" and "finish" values as well?
I guess so, but Prop Manual doesn't seem to say...
In Spin2, the start, finish, and delta values are evaluated only initially. During looping, the delta is added to the current value and, based on the sign of the delta, a comparison is made to the finish value.
The COGID instruction with the WC flag will return if the given cog, defined by D[3:0], is on or not. It sets C if the cog is active.
Is there a Spin2 equivalent of that, or just use inline asm?
The COGID instruction with the WC flag will return if the given cog, defined by D[3:0], is on or not. It sets C if the cog is active.
Is there a Spin2 equivalent of that, or just use inline asm?
I'm currently trying to get my keyboard/mouse USB object working using Spin2 (PNut v34L). The fastspin version is currently running well. This object has Spin2 methods and the USB host is DAT pasm, using both cog/lut exec and hub exec routines. The cog/lut exec routines look to be working fine, but when the first hub exec routine is called the train quickly goes off the rails. As far as I can tell now, it looks like it may be associated to the object relocation that Spin2 does.
Calls/jmps cog->hub are invoked using loc pa, #@target_label - #@cog_start_label followed by add pa, cog_start_offset to calculate the hub target address. All #relative and #.local_labels work fine without fix-up.
But it looks like something wonky is going on when calculating call/jmp targets in hub space. Below is a list of label locations used in the USB pasm code and it looks like there may be something going on with #label and #@label calculation when in hub space.
The top spin2 object imports two child objects, a serial spin2-only object and the USB host Spin2+pasm object. The label addresses below are calculated in cog/lut and hub space. The "usb_host_start" label is the cog start address and the "hparse_con_desc" label is the label that follows the first ORGH in the object. The label locations come from the compiled .BIN file.
-------------------------------------------------------------------------------
Cog/LUT exec space:
All labels in cog space calculated as expected.
-------------------------------------------------------------------------------
PTRB offset at cog start == hcog_base_addr == $1950
wrlong #usb_host_start == $0
wrlong #@usb_host_start == $1c
loc #usb_host_start == $0
loc #\usb_host_start == $0
loc #@usb_host_start == $1c
loc #\@usb_host_start == $1c
-------------------------------------------------------------------------------
wrlong ##hparse_con_desc == $c9c
wrlong ##@hparse_con_desc == $c9c
loc #hparse_con_desc == $c9c
loc #\hparse_con_desc == $c9c
loc #@hparse_con_desc == $c9c
loc #@\hparse_con_desc == $c9c
-------------------------------------------------------------------------------
Hub exec space:
Labels in cog space calculated as expected.
Hub exec space # and #@ labels not calculated as expected?
-------------------------------------------------------------------------------
wrlong #usb_host_start == $0
wrlong #@usb_host_start == $1c
loc #usb_host_start == $0
loc #\usb_host_start == $0
loc #@usb_host_start == $1c
loc #\@usb_host_start == $1c
-------------------------------------------------------------------------------
wrlong ##hparse_con_desc == $c9c
wrlong ##@hparse_con_desc == $c9c
**loc #hparse_con_desc == $2e68
loc #\hparse_con_desc == $c9c
**loc #@hparse_con_desc == $2e68
loc #\@hparse_con_desc == $c9c
**loc #@hparse_con_desc - @usb_host_start == $2e4c ($2e68 - $2e4c == $1c)
loc #\@hparse_con_desc - @usb_host_start == c80 (c80 + 1c == c9c)
Garryj, yes, I just discovered this, myself. I'm trying to figure out how to track addresses for ORGH code now. I'm hoping to be able to use ORGH to set up an offset that will be added to all PASM references for address computation. I don't fully have my head around this, yet.
Comments
Maybe adding a breakpoint would cause the PropTool to swap out that method with one that includes something that happens at the breakpoint...
I think this is very useful when code starts to get big...
My main GUI .spin file was over 3000 lines long, so I decided to make use of FastSpin's "#include" feature...
Does #include just insert the file, verbatim?
Makes me wish there was an #include_once
Or a #pragma once.
So if you're going to add #include, please add the other #define and #ifdef Preprocessor stuff as well.
https://github.com/parallaxinc/OpenSpin/wiki/Preprocessor
Anyway, wouldn't an assignment in a CON section be the same as a #define?
How could the length and hash possibly differ if they're the same file? Isn't there any way on Windows to tell if two different paths are the same file, even if there are symlinks or shortcuts or junctions complicating things?
That's what i was thinking to make it simpler, because of those blasted virtual files and directories. Or handle the case of two files with the same name, in different directories, with different content.
Thought to just keep it simple as this is being written in 486 assembler.
Eventually, I will singulate duplicated routines, if there are any. An include-file would make it very easy to bring functionality into an object, without having to bring an object in. For example, some routines that just prints numbers and strings.
The Spin2 compiler is almost 13,000 lines of '386 code now, all in a single file. It uses only two include files, one for the interpreter and one for the flash programmer. Both of those files just define bytes that make up the respective programs.
There's also a simpler preprocessor that fastspin shares with openspin and which is less C specific.
I've tried this, but it does not work:
PUB main() coginit(16, @blink, 0) PUB blink() repeat pintoggle(60) waitms(300)Andy
Maybe it needs to be above $400?
This is the step in a downward repeat loop.
This doesn't work as expected in Spin1:
You'd think you'd want to make the step negative to count down, but this makes it actually count up.
Was this changed in Spin2?
ROTXY(x,y,t) 'rotates (x,y) by t, returns x and y
POLXY(r,t) 'converts polar to cartesian, returns x and y
XYPOL(x,y) 'converts cartesian to polar, return rho and theta
COGSPIN(cognumber, spinmethod({params}), stackaddress)
COGSPIN returns the cog number if used as a function. -1 means no free cog, if 16 was used as cognumber.
Spin2 makes the step value absolute, then negates it if it needs to count downward. So, it ignores the sign that the user specifies.
Is true for "Start" and "finish" values as well?
I guess so, but Prop Manual doesn't seem to say...
In Spin2, the start, finish, and delta values are evaluated only initially. During looping, the delta is added to the current value and, based on the sign of the delta, a comparison is made to the finish value.
If cognumber = 16, that will start a free cog. COGSPIN will return the started cog, or -1 if none was available.
Is there a Spin2 equivalent of that, or just use inline asm?
COGCHK(cognumber)
Calls/jmps cog->hub are invoked using loc pa, #@target_label - #@cog_start_label followed by add pa, cog_start_offset to calculate the hub target address. All #relative and #.local_labels work fine without fix-up.
But it looks like something wonky is going on when calculating call/jmp targets in hub space. Below is a list of label locations used in the USB pasm code and it looks like there may be something going on with #label and #@label calculation when in hub space.
The top spin2 object imports two child objects, a serial spin2-only object and the USB host Spin2+pasm object. The label addresses below are calculated in cog/lut and hub space. The "usb_host_start" label is the cog start address and the "hparse_con_desc" label is the label that follows the first ORGH in the object. The label locations come from the compiled .BIN file.