No debugger in Basic - even in asm shared section
pik33
Posts: 2,350
Of course having "print" makes debugging in Basic without "debug" easy, but then there can be asm shared started by cpu command.
The compiler doesn't accept "debug" there. This makes writing a Basic based driver code much harder.
I have now switch the code to Spin to enable debug.
Comments
I dont play at the level you do Pik33, but when I’m coding in assembly and need to print something as a debugging aid, I just toss an END ASM in there, print from BASIC, and drop back into assembly. Does this not work for what you are doing? (And yep, having DEBUG would be cool!)
DEBUG is a bit of a parser nightmare, which is why it's only in spin. Adding PASM debug took adding quite a couple specific parser rules. I guess it could be transplanted to the other language grammars, but I myself don't have time and care (IMO cog-loaded PASM drivers should be in Spin files) for that right now.
This was asm shared, which is an equivalent of dat section in SPin, to be executed in a new cog.
I ended up with 2 files: spin for debugging, basic for testing if it still works inside Basic. Switching between languages in one project is nasty. =, ==, := , (), [] , etc.
I don't know where is the problem with parsing if the same compiler can understand debug in Spin dat section. After discovering of asm shared section it should switch to Spin-like PASM DAT mode. There was another problem:
long i_ld_zpg | %100_1_11110 << 10 | 2 << 28 ' A7 *LAX zpgThe compiler didn't like "|" - I replaced all of them with + - in this case I could but I still think that assembly syntax should be the same, regardless of the high level language that contains the asm code in it. One cpu, one asm.
That's not how it works though, each language has it's own bison grammar, so to facilitate PASM in BASIC/C, all the PASM rules have to be copied into them.
So it looks PASM is not a language but only an extension to whatever language it is added to instead of being a language with its own syntax and set of rules.
I tried to separate .dat section with its own .spin2 file but then I am unable to get pointers to its labels to start the cog from outside this file. So there is no workaround other than keeping cog asm with all the code which needs access to it with .spin2 file. At least the start function has to be there.
If you really really want, you can just define methods that return the pointers you need (which in practice will be inlined). But having the code that interacts with the PASM in there with it is obviously just better.
The problem is that BASIC and Spin have different expression syntaxes. For example,
).
3^2is9in BASIC but1in Spin. Most PASM code is written using Spin expression syntax, but should BASIC programmers have to learn that? There's no easy answer. In C I ended up having bothasm(assembly code using C expression syntax) andpasm(assembly with Spin syntax) keywords, and maybe BASIC needs the same, but as Ada said it's a big pain and a lot of syntax has to be manually duplicated (and testedAs for DEBUG, what we really need is a high level debugger that lets you single step through assembly code and print memory locations. I think @cgracey is working on something like that. I just hope it isn't too tightly bound to PNut so that other compilers (flexspin, llvm, TAQOZ, etc.) can use it too.
The idea of writing a GDB stub was floated a bunch of times. That'd give the benefit of being able to hook into pre-exisiting GUI debug support in VSC and the likes. But the compiler would need to dump sufficient symbols and we'd need to maintain a GDB fork with P2 support.
But adding Spin-style debug prints to C and BASIC would be pretty nice, too.