Opinions requested: How about a PASM-centric coding environment?
Wossname
Posts: 174
I wonder how many of you fellow forum members do a sizeable amount of PASM coding. I've been battling with it a fair bit lately and honestly I find it a pain in the Smile.
I can see several areas where the Propeller Tool (lovely and $free though it is) falls down pathetically where debugging PASM is required. I feel like I'm having to "help" the tool rather than the tool helping me. It's a fight to see who breaks first.
After having finally won my latest battle with the Prop Tool's assembler quirks, I'm sufficiently frustrated with the amount of time it's taken to get this far, that I'm actually interested in building some kind of pre-compilation functionality that could augment the Prop Tool in compiling/assembling PASM centric code.
I'd be interested in hearing about any other issues you guys have had with getting to grips with PASM and finding solutions to common problems and user errors.
If I manage to make something useful I'll release it as open source software of course.
My thoughts so far...
I can see several areas where the Propeller Tool (lovely and $free though it is) falls down pathetically where debugging PASM is required. I feel like I'm having to "help" the tool rather than the tool helping me. It's a fight to see who breaks first.
After having finally won my latest battle with the Prop Tool's assembler quirks, I'm sufficiently frustrated with the amount of time it's taken to get this far, that I'm actually interested in building some kind of pre-compilation functionality that could augment the Prop Tool in compiling/assembling PASM centric code.
I'd be interested in hearing about any other issues you guys have had with getting to grips with PASM and finding solutions to common problems and user errors.
If I manage to make something useful I'll release it as open source software of course.
My thoughts so far...
- Tabbed-document coding environment - one tab for the HUB and 8 more for the cogs. Certain declarations can be shared between them.
- Intelligent syntax guidance with '//comment based compilation hints.
- Common error highlighting (did you forget the "#" symbol and so on).
- Variable name decoration - to aid consistent naming conventions across cogs and HUB memory.
- Unused variable/constant identification.
- .......
Comments
I've wanted intelligent syntax/intellisense (like with Visual Studio) ever since I first started learning spin. I would LOVE that, the same with variable name intellisense. Unused variable/constant identification would be nice.
But the biggest helper of all would be if you could step through the code using an emulator. It could even be low speed emulator, just something to allow you to step through the code, watch the values change through mouse highlight just like Visual Studio. The debugging features of VS is what makes it so nice and even though a lot of people on this forum aren't big Windows fans, there is a lot that can be bench marked from Visual Studio.
I'd be on board with trying to write a tool that works closer to VS.
^ LOL!
While this is being done, I'd also vote for a 'Smarter PASM', it seems so many Assembler Designers stop as soon as they have a pulse.
Some of the IQ gains can be controlled by Pragmas, as it should never break existing code.
A good example is the # above that should be a default-selectable, and the rarer indirect should be explicitly asked for.
Target should be code clarity but ABSOLUTELY NOT at the expense of size.
No Brainers are things like INC VarName and DEC VarName, and this could even allow VarName++ and VarName--, tho that is less 'ASM Syntax', it probably still is quite clear to any reader.
A (local) pragma would set the default flags, but explicit full coverage coding should also be allowed.
Next would be Named Boolean variable support - here it should allow something like 8051 style 'pseudo opcodes', so you give your PinName, and then can SETB CLRB CPLB JB JNB and I can see a WaitPin and WaitNotPin being valid for PinName space (but not other Boolean Names)
Then add Asm-intelligent blocking like IF ELSEIF REPEAT etc, the target here is to remove label fluff.
Macros and conditional assembly (pre-processor) are also expected capabilities.
It may be that the GCC work is advanced enough to be 'sufficiently close to COG-ASM', but certainly PASM is far too primitive and limited.
( I do not think a few band-aids are enough)
GCC+ GoodDocs + Clear-Asm-Listing might be workable, and that Clear-Asm-Listing should be paste-able into any ASM branch.
Adding a MACRO capability to the assembler could take care of some of the issues.
Please ......... ???!!!!
Cheers,
Peter (pjv)
I've not tried GNU Assembler (GAS) yet, but part of the GCC work includes this apparently.
- and it seems GAS does include this expected MACRO support
http://tigcc.ticalc.org/doc/gnuasm.html#SEC109
"Asm designers stop as soon as they have a pulse"
No they don't, they go on to make compilers.
Given all the features requested here that seems to be the way to go.
Its a nice wish list but at the end of the day you have to concentrate on what you are doing with every statement in assembler, you are in full control of the hardware and you need to understand that hardware in full, no amount of hand-holding from the development software can obviate the need to understand the precise semantics of every instruction.
If you want a high-level programming model you have to use a high-level language where the compiler abstracts away from all the grisly details, but otherwise you are compelled to follow the steep learning curve and check and double-check every line of code (that's the nature of programming at the hardware level which is what assembler is really).
As for runtime debugging, many applications of PASM are talking to hardware with precise timing requirements - there is no chance of single-stepping being of use for this so there will always be situations where you have to debug via intelligent deduction and trial/error - the best approach is having the discipline to check and re-check every line of code before you run it - you will find more bugs if you learn to inspect code critically than by just running it and going round the debug cycle (yes you may have to do that anyway but you save a lot of time by careful inspection)
I don't think the environment can ever substitute for being an alert and methodical programmer, or for rereading the PASM manual several times.
This misses the point that is IS possible to be " full control of the hardware", without wearing a hair shirt.
Indeed, a well designed assembler and support infrastructure, means you have MORE brain cells able to "concentrate on what you are doing" in software, and less on the syntactic fluff and distractions of book-keeping. That's what computers do so much better than humans.
Many programmers have coded a LOT in assembler, just NOT on the Prop.
Only up to a point, because if you THINK some flag is changed, but it is not, "check and re-check" does not help.
For projects that cannot step, there are some good Simulation options mentioned in this thread :
http://forums.parallax.com/showthread.php?128698-Propeller-emulator
and it points to this one, which recently added PASM level sim.
http://forums.parallax.com/showthread.php?127976-Spin-Simulator
Many forum member may object, so I preface with "This is my opinion, as requested".
An option is to approach this differently.
Try doing a lot of little easy quick experiments, until each little detail is ironed out, and then stick all these together. Its much easier.
One way to do this is interactively. One way to do that is propforth. It is, my limited opinion, the easiest way.
Its just you the stack and the assembler words. (Supported by the forth kernel that already behaves in a known, predictable, consistent manner).
No intelligent anything, each little chink of opcodes either works, or it doesn't; if it doesn't work, figure it out (its just a few opcodes); if it works, add another until the app is done.
Some folks may say that this is cheating, since "real" programmers use (some stereotypical set of tools and methods that is not forth). But why bang your head against the wall? Just try the easy way. The investment in getting familiar with thinking on the stack is well worth it.
[/end-braino-opinios]
Thanks for the input guys, much to think about.
Keep the ideas coming in though.
The most talk in this thread is about an imrpoved assembler.
Anyway is everybody aware of PASD? http://propeller.wikispaces.com/PASD from http://www.insonix.ch/propeller/prop_pasd.html
I haven't read all details of this thread, but I did not find the letters "PASD" in it. So I guess not everybody is already aware of PASD.
PASD does a quite good job on debugging PASM-code.
Take a look into the threads
http://forums.parallax.com/showthread.php?132221-Best-Practices-tools-for-PASM-debugging
and
http://forums.parallax.com/showthread.php?113779-What-methods-do-you-use-to-debug-PASM-code
best regards
Stefan
It can be a brave call to say something is unused (!), but unreferenced is easy to detect for direct variable names.
Good compilers can do this for free. [ eg report unreferenced names, and report code size of a function, and even speeds]
I've seen some simulators that change colour when a variable is changed, which can help, and simulators can give good speed information.
I always liked the upstairs/downstairs metaphor of PASM programming...and how the PropTool facilitates that metaphor in a variety of ways. Unfortunately it also obfuscates a lot of what is going on in the various COGs, and how the tasks are distributed across the COGs. PropForth makes this so embarrassingly simple that you kind of have to ask yourself, "why didn't Parallax do it this way from the get-go?"
I was aware of PASD after having read "Programming And Customizing The Multicore Propeller Microcontroller", last year, and have often wondered why I don't see too much mention of it here.
I haven't had the time to pursue what I want to do with the Prop, yet but I do know that I want PASM performance and although I'm not at all intimidated by it (it reminds me of MASM), I would like to see what can be achieved using PropBASIC which generates PASM code.
Cheers!
Mickster
You can then do all the things in post #1.
Eg, if you load a variable with a value 511 that works fine. If you load it with 513, it could either tell you that is wrong, or even better, could write the pasm equivalent (define a variable "five_hundred_and_thirteen" in the dat section) and load that.
If you had such things, you might start to think about tweaking the language somewhat. Heresy I know but there are some new and exciting things that are going to need tweaking anyway. So you could maybe do away with #numbers and just write them as numbers and not have to know about the special 511 value thing.
See, I have this idea for an XMM version of pasm that exists in a huge flat 32 bit memory model. Massive programs. But the catch with existing LMM (and indeed all the CPU emulators) is they are slower than native pasm. How can you have native pasm speed and at the same time, huge programs?
The first problem is variables. In a standard pasm program these exist at the bottom of the program. If you start thinking about huge programs then you run out of variable space. Of course, you could put the variables in hub, but a rdlong is slower than getting a local variable in a cog. So certain routines (eg video) won't work.
So an idea is to load in 2k blocks of pasm code and the complete program ends up loading lots of these in sequence.
Take a typical pasm program. Define some common variables at end of the cog - maybe 16 longs, and a program counter, and a stack counter. The stack itself is in hub.
Load in the first 2k pasm block. Jumps are the key difference between this model and a CPU emulation. In a CPU emulation, you don't know if the next instruction is a jump, or a call, so you have to check all of them, every single time. But if the precompiler compiles this, it knows about jumps and can put the code in as required.
So you have a "call" to a subroutine, and it happens to exist in a different 2k block. What happens is that some code is inserted by the precompiler - push the program counter to the stack, maybe store some other variables as required, and then load in the new 2k block.
The clever bit is that the code to load in the new block exists in this current block. So if you compiled to an "LMM" model, the precompiler might insert some code to read a block of data from hub. But if the precompiler was doing an XMM model, it would insert the code for reading external ram.
So similarly with a "return". The cog that has a "return" in it also contains the code to do a return. It pops the program counter off the stack etc etc.
There are still a few catches. Those variables at the top of the cog take up a bit of space. So maybe when this is translated to standard pasm, it has a "fit 470" instead of "fit 496" at the end.
The code that reads from hub or external ram takes a bit of space. But one thing you could do in a GUI environment is tell the user how much space they have in that block of code.
Passing variables eg call myfunction(a,b,c) might push a,b,c onto the stack, and the called cog code will pop them off. The precompiler would put all this in automatically.
But it need not be a pure stack machine. Reading the theory of microcontrollers, there are some advantages to register based machines and some to stack based ones. So there could be some advantages to having 16 longs (or more) that are static between cog blocks. The most obvious use there would be for a "result" value, where you return one value, and can then save pushing and popping the value to and from the stack.
I am thinking that if you wrote such a precompiler (and GUI) you could incorporate all the wishlist things in post #1 at the same time.
In summary, you build a huge (megabyte) sized pasm program in ?1.5k blocks. Each block runs in a cog in a self contained way and has the ability and the code to daisy chain the next pasm program. But at the same time, each cog program is totally standard pasm, so is capable of full speed video if you wanted.
Thing is that if the code in your 2K block is only run through once, say it contains a subroutine that gets called which causes the block to be loaded and run through, then you are not doing any better performance wise than using LMM. In fact you may be doing much worse what with loading 2K, executing a few instructions of subroutine and then loading the next 2K. Better to use variable size overlays Cluso style. All in all it's easier and quicker to use LMM.
However if your code contains something that loops around a lot and fits within 2K then you can get a dramatic performance gain. But then you need the programmer to tell the system that "this block of code is to be loaded and run at full speed rather than using LMM"
Or you need to use a higher level language, block structured at least, where the compiler can figure out for itself that yes, this loop can be run in COG.
And that is exactly what the propgcc C compiler can do. Most code is compiled to LMM but it can detect when loops would be better loaded and run at full PASM speed.
In the propgcc demos they have my heater_fft doing exactly that. It runs nearly as fast as my hand coded PASM version!!
I think there almost needs to be another sub-forum called something like
Propeller GCC Assembler (GAS) Alpha Test Forum
as I think GAS is going to become quite important.
GCC has a pro-processor, and GAS has macro support, and is an ideal chance to clean-up the worse aspects of PASM.
eg A macro should be able to accept large constants, transparent to the user, and the PASM listing will show clearly what happened. I've not used GAS in anger yet, but better assemblers have a message facility, so you can ping a message when a user consumes extra storage for example.
What I have read of GAS + Prop, is looking impressive.
I've found this :
http://sourceware.org/binutils/docs/as/index.html
and yes, GASm can give .warning "message goes here "
Sounds close to ideal, provided it has some operator control on that 'detect' ?
You need to assign COGs a priority binning, so a couple of critical ones may be 'Load and Keep', and a couple more would be 'Replace only by more important task', and the lowest level would be 'use as required', first come, first served.
If there was room/support for a simple re-load counter, you could check that every now and then to catch any COG-thrashing ?
I was also thinking about having another (also configurable) feature that enforces naming conventions for certain things like constants (eg. you can 't declare something in the CON section without prefixing it's name with "CON_" or whatever).
I suggest these things because it clarifies to the programmer where and how things are defined without forcing them to go hunting around all the time to check they've been consistent everywhere, if the computer can do that on their behalf then that's a good thing I guess. Although I don't like being dependant on a particular IDE, SOME people might find it helps their productivity.
These things, plus giving the user a chance to segregate code in to COG-sized chunks, might go a long way to making PASM programming a lot less frustrating - without actually changing fundamental about PASM itself.
I don't recall how much control there is over propgcc compiling loops to native PASM. Perhaps only a means of enabling/disabling it like you might other optimizations.
Of course if you really want some code C code to be compiled for COG loading you can specify that on a file by file basis.