Ok, I think you're saying one can't have non-local references in between local ones.
Guess that explains it...
Correct. By definition a "local" reference only extends until the next non-local one. This is the same as for P1 PASM; the only difference is that for P2 PASM we use "." to introduce a local label instead of ":".
Yes, there's a bug in the parsing of rep instructions; if a ## is present the augment instruction is counted as part of the loop for @ expressions. That's wrong of course, and I'll try to fix it soon. You can avoid it for now by putting the "640" in a register and using that for the loop count.
As for the loc ptra, ##@HyperBuffer; there are probably multiple issues there. ## will generate an augment, which will probably mess up the loc address. Also, if you have Spin code in the same file (it's not a pure assembly program) then the whole meaning of "@" is a bit fuzzy, just as in Spin1 (where we had @ and @@ to handle this kind of thing). The upcoming fastspin release will handle this better, I think, but for now I'd suggest doing something like:
mov ptra, HyperBufferPtr
...
HyperBufferPtr long @ @ @ HyperBuffer
(without the spaces between the "@" signs -- why does the forum try to parse those inside code blocks??) which will work even if you have Spin code there.
Thing about the loc ##@ is that it appears to mess up all the cogs, not just the one whose code this is in...
Well, I guess the effects would depend on what the loc result was used for -- if you end up with a bad address in ptra you could overwrite other COGs memory.
@Rayman : this fixes the REP bug you noticed, as well as another REP bug where the optimizer would get confused when inlining a function that contained REP. It also handles loc better, although there are probably still some issues with addresses when mixing Spin and PASM code.
@pilot0315 : spin2gui checks now for deleted files and always re-writes the files if it can't find them on disk.
There are also a bunch more bug fixes (see the release notes for details). The only major new feature is that FCACHE is supported in P2 mode, using the LUT to cache small loops, but that has to be explicitly enabled by saying something like --fcache=240 on the command line. FCACHE doesn't make nearly as much difference on P2 as on P1, since hub exec is already pretty efficient, but it does provide a small speedup, e.g. the fftbench time dropped from 46 microseconds without fcache to 40 microseconds with --fcache=240.
There are new releases of fastspin and spin2gui. Mostly this is a bugfix release to fix various issues that people have reported (thanks for the bug reports, everyone). The only "new" features are (1) FCACHE is enabled automatically on P2 at optimization level -O2, and (2) if an object is given without an extension, fastspin looks for it as a .spin2 file first, and then a .spin file.
I stumbled over a idea on the P1 thread. And that got me thinking. I am not sure if fastspin already does this, but if not you might add this to the spin syntax.
In p1 Spin you can set bits in dira/outa and read bits from ina with that nice syntax a := ina[3..19] for example. Or a := ina[19..3]
I think it would be nice if that would be possible with any variable so one could say in Spin a[5..9] := b[8..4] or similar, a and b being single longs.
Currently you are defining Spin2 and Chip will have to follow, right?
I really like fastspin, it works for P1 and P2 and the multi language aspect is phenomenal.
In my not at all humble opinion this is wonderful work you are doing there. And if Chip gets his bytecodes done then you might be able to assimilate that too.
I stumbled over a idea on the P1 thread. And that got me thinking. I am not sure if fastspin already does this, but if not you might add this to the spin syntax.
In p1 Spin you can set bits in dira/outa and read bits from ina with that nice syntax a := ina[3..19] for example. Or a := ina[19..3]
I think it would be nice if that would be possible with any variable so one could say in Spin a[5..9] := b[8..4] or similar, a and b being single longs.
There's a problem with that syntax: in Spin you are allowed to use any variable as an array, so for example in:
VAR
long x, y
PUB setit(a, b)
x[0] := a
x[1] := b
the "x[0]" refers to "x" and "x[1]" refers to "b". So we would need a completely new syntax.
It might be possible to do something like that via a new suffix like ".bit":
x.bit[4] := 1 ' same as x |= (1<<4)
x.bit[3..0] := 2 ' same as x := (x & !$F) | 2
How does that sound?
Currently you are defining Spin2 and Chip will have to follow, right?
Definitely not . Spin is Chip's baby, and I think we'll all follow where he leads. That said, Chip has been very open to community suggestions, so perhaps he'll adopt something like this for Spin2 as well.
I really like fastspin, it works for P1 and P2 and the multi language aspect is phenomenal.
Thanks! It's nice to know that people find it useful.
Would var.bit[n] with n>31 act on the bits of the next long(s) in memory?
That'd probably be too confusing...
would be conform with spin a.byte/word/long do it like that and do not check boundariessame goes for the alternate syntax of
long[@a+b] could be bit[@a+33] for the first bit of the long after a.
But I am more after the [a..b] syntax, it is already in fastspin for dir/out/in
Eric,
I've started using the -l listing output for Fastspin. I see a couple of formatting niggles:
- I note the hexadecimal is all byte sized big-endian in a little-endian system. It's a little disorienting trying to visually maintain the hexadecimal pairs without any delimiters. The easiest improvement would be to have a space between bytes to show the hexadecimal big-endian pairings. The alternative would be go pure little-endian.
- There is some oddball miss-align occurs at memory boundaries, eg: going from cogram to hubram with an ORGH.
Eric,
I've started using the -l listing output for Fastspin. I see a couple of formatting niggles:
- I note the hexadecimal is all byte sized big-endian in a little-endian system. It's a little disorienting trying to visually maintain the hexadecimal pairs without any delimiters. The easiest improvement would be to have a space between bytes to show the hexadecimal big-endian pairings. The alternative would be go pure little-endian.
Normally, in little-endian systems the bytes (hexadecimal pairs) are the same as big-endian, but ordered differently; this is exactly what you are seeing. For "pure little-endian" bit 31 would represent a value of 1, bit 30 a value of 2, and so on.
Having inter-byte delimiters is not a bad idea, at least as an option, if the data is going to be listed in little-endian form.
Perhaps it would actually make more sense to list the data twice (little-endian for hub and "big-endian" long form for cog), as well as the hub and cog address equivalents, with a header row to show the fields, and maybe even some in-line field delimiters.
e.g.
Normally, in little-endian systems the bytes (hexadecimal pairs) are the same as big-endian, but ordered differently; this is exactly what you are seeing.
Ya, it's ugly and I'd prefer each hex character be displayed in little-endian order to match the hardware but with spaces between bytes it clarifies enough to be readable.
For "pure little-endian" bit 31 would represent a value of 1, bit 30 a value of 2, and so on.
Bad idea. Bit numbering must always represent the numerical significance. Anything else is just adding confusion.
Perhaps it would actually make more sense to list the data twice (little-endian for hub and "big-endian" long form for cog), as well as the hub and cog address equivalents, with a header row to show the fields, and maybe even some in-line field delimiters.
e.g.
That could work, as it is common for listing files to firstly follow the memory map, as in a HEX dump does.
If there is a number involved, that could be quoted in numeric format, & should character strings be listed in ASCII ?
Normally, in little-endian systems the bytes (hexadecimal pairs) are the same as big-endian, but ordered differently; this is exactly what you are seeing.
Ya, it's ugly and I'd prefer each hex character be displayed in little-endian order to match the hardware but with spaces between bytes it clarifies enough to be readable.
For "pure little-endian" bit 31 would represent a value of 1, bit 30 a value of 2, and so on.
Bad idea. Bit numbering must always represent the numerical significance. Anything else is just adding confusion.
That was my point. I'm not aware of any computer systems that use "pure little-endianness" for anything but serial communications, certainly not for memory contents.
Perhaps it would actually make more sense to list the data twice (little-endian for hub and "big-endian" long form for cog), as well as the hub and cog address equivalents, with a header row to show the fields, and maybe even some in-line field delimiters.
e.g.
That was my point. I'm not aware of any computer systems that use "pure little-endianness" for anything but serial communications, certainly not for memory contents.
Those were two independent replies. Pertaining to the first one, I'll point out that the traditional solutions have always been problematic.
Eric,
I've just had a nosy at the Fastspin sources looking for encoding details of LOC instruction. One thing that looked mismatched is in frontends/lexer.c
I have no understanding of these but I would have expected OPC_GENERIC_BRANCH would apply to both "calla" and "callb" equally. And presumably the OPC_CALL would go with the "call".
PS: Fastspin v3.9.21
Thanks everyone for the suggestions / comments about listing files. Definitely there should have been spaces between the bytes to make it clear that they were bytes, not longs. I've fixed that in github now and it'll be in the next release.
Comments
I'm getting an error when I use ".end" but not with "end" here:
DAT 'ReadRegOrId ReadRegOrId or outa,mRSTn 'bring resetn high setbyte dira,#$FF,#0 andn outa,mCSn 'bring cs low 'Send Command Address mov altsd,#datain0 rep @.end,#7 alts1 alts altsd setbyte outa,0,#0 xor outa,mCK add altsd,#1 .endthis is the error (see attached image).
Addit: if alts1 is not local you can just rename it to .alts1 and all should be good.
Guess that explains it...
Correct. By definition a "local" reference only extends until the next non-local one. This is the same as for P1 PASM; the only difference is that for P2 PASM we use "." to introduce a local label instead of ":".
But, for P2 it's handy for the REP instruction...
If I add this line to a program, it doesn't work anymore: I think it's maybe supposed to just be #@ instead of ##@.
But, don't know why that should kill the whole application...
It's slower using @.reploop2 than with #1..
rep #1,##640'@.reploop2,##640 wfbyte inb .reploop2Yes, there's a bug in the parsing of rep instructions; if a ## is present the augment instruction is counted as part of the loop for @ expressions. That's wrong of course, and I'll try to fix it soon. You can avoid it for now by putting the "640" in a register and using that for the loop count.
As for the loc ptra, ##@HyperBuffer; there are probably multiple issues there. ## will generate an augment, which will probably mess up the loc address. Also, if you have Spin code in the same file (it's not a pure assembly program) then the whole meaning of "@" is a bit fuzzy, just as in Spin1 (where we had @ and @@ to handle this kind of thing). The upcoming fastspin release will handle this better, I think, but for now I'd suggest doing something like: (without the spaces between the "@" signs -- why does the forum try to parse those inside code blocks??) which will work even if you have Spin code there.
Not sure it's a FastSpin bug, maybe I did it wrong...
Well, I guess the effects would depend on what the loc result was used for -- if you end up with a bad address in ptra you could overwrite other COGs memory.
Remember that cogatn takes a mask as parameter (to signal multiple COGs). I've attached a sample program that works for me.
@Rayman : this fixes the REP bug you noticed, as well as another REP bug where the optimizer would get confused when inlining a function that contained REP. It also handles loc better, although there are probably still some issues with addresses when mixing Spin and PASM code.
@pilot0315 : spin2gui checks now for deleted files and always re-writes the files if it can't find them on disk.
There are also a bunch more bug fixes (see the release notes for details). The only major new feature is that FCACHE is supported in P2 mode, using the LUT to cache small loops, but that has to be explicitly enabled by saying something like --fcache=240 on the command line. FCACHE doesn't make nearly as much difference on P2 as on P1, since hub exec is already pretty efficient, but it does provide a small speedup, e.g. the fftbench time dropped from 46 microseconds without fcache to 40 microseconds with --fcache=240.
I stumbled over a idea on the P1 thread. And that got me thinking. I am not sure if fastspin already does this, but if not you might add this to the spin syntax.
In p1 Spin you can set bits in dira/outa and read bits from ina with that nice syntax a := ina[3..19] for example. Or a := ina[19..3]
I think it would be nice if that would be possible with any variable so one could say in Spin a[5..9] := b[8..4] or similar, a and b being single longs.
Currently you are defining Spin2 and Chip will have to follow, right?
I really like fastspin, it works for P1 and P2 and the multi language aspect is phenomenal.
In my not at all humble opinion this is wonderful work you are doing there. And if Chip gets his bytecodes done then you might be able to assimilate that too.
Thank you for putting all that work into it.
Mike
It might be possible to do something like that via a new suffix like ".bit":
How does that sound?
Definitely not
Thanks! It's nice to know that people find it useful.
Regards,
Eric
My thinking was that var[a..b] would be easy distinguishable from var[a] or var[a,b] / var[a].
how about var[1..1] for the single bit?
But basically var.bit[] fits nice into var.byte[] var.word[] var.long[] already existing.
Enjoy!
Mike
That'd probably be too confusing...
would be conform with spin a.byte/word/long do it like that and do not check boundariessame goes for the alternate syntax of
long[@a+b] could be bit[@a+33] for the first bit of the long after a.
But I am more after the [a..b] syntax, it is already in fastspin for dir/out/in
Mike
while pluming along with my two port serial driver I adapted your std_text_routines for use with a additional port parameter.
The ability to have optional parameters is really nice and your prinf saves so much code in my test routines, it is just fantastic.
Thank you for all the work you are putting in here,
Mike
You're very welcome, Mike. I'm glad you're finding it all useful! Let me know if you run into any problems.
Thanks,
Eric
I've started using the -l listing output for Fastspin. I see a couple of formatting niggles:
- I note the hexadecimal is all byte sized big-endian in a little-endian system. It's a little disorienting trying to visually maintain the hexadecimal pairs without any delimiters. The easiest improvement would be to have a space between bytes to show the hexadecimal big-endian pairings. The alternative would be go pure little-endian.
- There is some oddball miss-align occurs at memory boundaries, eg: going from cogram to hubram with an ORGH.
Normally, in little-endian systems the bytes (hexadecimal pairs) are the same as big-endian, but ordered differently; this is exactly what you are seeing. For "pure little-endian" bit 31 would represent a value of 1, bit 30 a value of 2, and so on.
Having inter-byte delimiters is not a bad idea, at least as an option, if the data is going to be listed in little-endian form.
Perhaps it would actually make more sense to list the data twice (little-endian for hub and "big-endian" long form for cog), as well as the hub and cog address equivalents, with a header row to show the fields, and maybe even some in-line field delimiters.
e.g.
Bad idea. Bit numbering must always represent the numerical significance. Anything else is just adding confusion.
That could work, as it is common for listing files to firstly follow the memory map, as in a HEX dump does.
If there is a number involved, that could be quoted in numeric format, & should character strings be listed in ASCII ?
That was my point. I'm not aware of any computer systems that use "pure little-endianness" for anything but serial communications, certainly not for memory contents.
I like it! It makes clear the addressing.
It also makes the list format fatter but that's no problem these days.
I've just had a nosy at the Fastspin sources looking for encoding details of LOC instruction. One thing that looked mismatched is in frontends/lexer.c
// long jumps { "jmp" , 0x0d800000, P2_JUMP, OPC_JUMP, 0 }, { "call", 0x0da00000, P2_JUMP, OPC_GENERIC_BRANCH, 0 }, { "calla", 0x0dc00000, P2_JUMP, OPC_CALL, 0 }, { "callb", 0x0de00000, P2_JUMP, OPC_GENERIC_BRANCH, 0 },I have no understanding of these but I would have expected OPC_GENERIC_BRANCH would apply to both "calla" and "callb" equally. And presumably the OPC_CALL would go with the "call".PS: Fastspin v3.9.21
Eric