Learning to use assembly code on the Prop 2
MByron
Posts: 26
in Propeller 2
My on and off observations of the Prop 2 development in the forums give me concern on what the documentation will be for using assembler code.
The documentation for the Prop 1 was quite good. I get the impression that for the Prop 2 it will be 100X more involved to program.
When will the documentation become available and will it be done as well as for the Prop 1?
The documentation for the Prop 1 was quite good. I get the impression that for the Prop 2 it will be 100X more involved to program.
When will the documentation become available and will it be done as well as for the Prop 1?
Comments
Some new features really help with easy assembly programming ... but obviously there is much much more inside the Prop2 compared to the Prop1.
PS: I prefer to download them as PDF and ODS respectively. Google's javascript editors are slow and only work while you're online. The word processing one formats to PDF quite well but the spreadsheet one just comes out a mess so I view it with LibreOffice.
If all you want to do is write Pasm2 code that does exactly what Pasm1 could do... that learning curve would actually be easier... maybe as little as an hour or two to get comfy with the concepts.
It is when you want to get functionality out of the P2 that you couldn't get out of the P1 that things get a little complicated...
smart pins for instance. Smart pins are actually very easy to use... but not so easy to figure out from the documentation. Ditto for the Cordic and streamer stuff. I would suggest this order of study and docs: streamer, smart pin, cordic.
Knowing what the P2 can do is different from knowing how to do it. It is important to know what is possible, far less so to know (without question) exactly how to do it... that is where the examples come in. We will need a lot of them at all levels.
I have concluded that it is not meant to be a learning source for someone trying to get into PASM programming of the Prop 2.
It appears to be documentation to define what the Prop 2 is for those who have been involved with its evolution over the years.
I have used the Prop 1 for over 6 years, owning at least a dozen Proto boards and found great enjoyment in my hobby.
I am beginning to suspect that the Prop 2 is not intended for the hobbyist.
Maybe the "documentation" for the PASM will be improved. It has a long way to go.
Be patient.
If you've done any Prop1 assembly then first thing is learn many of plain Prop2 Cog assembly. That's equivalent to the Prop1. Then HubExec is only a small step away. Followed by CORDIC extension. CORDIC is very easy but only for maths. If you aren't doing maths then it won't be of use.
Smartpins can be very nice, and easy to set up ... but again, don't rush into them, they impose detailed visualisation from their descriptions. These are the closest function to the Prop1 counters.
PS: There is quite a lot of special instructions that you can happily ignore until it is time to use them. Things like setting up LUT sharing or interrupts or debug hooks or some of the weirder data manipulation instructions.
EDIT: Fix punctuation/grammar/mistakes.
BUT...
You don't have to worry about most of the cisc features, if you don't want to. They are there to reduce clocks for commonly used combinations of instructions. You can ignore them and use just the subset of Pasm2 that closely matches the Pasm1 instruction set. It is only when you run out of clocks that you have to look any further.
I haven't had any interest in HubExec yet. There has to be a lot going on before you need HubExec. And HubExec uses resources that I typically use from the cog ... so.... not yet.
It's not complicated. We just need some more explanations with examples. You'll find it quite useable.
Adding a prefix to an instruction that consumes another LONG and requires more clocks to execute moves a RISC design from RISC to CISC.
Hence "truly a lovely addition to a RISC architecture" becomes a contradiction.
Mind you, I'm not saying anything about either RISC or CISC or a mash up of both being "truly lovely" or otherwise.
I take my definition of RISC from David Patterson who first coined the term "RISC" and wrote the book on the subject: https://www.elsevier.com/books/computer-organization-and-design-risc-v-edition/patterson/978-0-12-812275-4
By that definition it is clearly seen that Intel processors are not RISC.
Edit: Last sentence updated at the request of evanh below.
With the P1, the original documentation was terse to the point of being opaque to a hobbyist. If that was what you were looking at, you would have come to the same conclusions about the P1. That original documentation was intended to jumpstart expert users.
P2 documentation is actually more readable. But there is so much more to document with the P2. Many of the commands are actually compound... you have to do things in the proper sequence and it is all documented down to the bit level... so there is a lot to say if you are trying to be complete, which Chip is doing.
I blur over when I attempt to actually read parts of it... it can be difficult to find the appropriate section and difficult to remember where in that particular section I am reading. I think this is partly because of trying to read the documents in a browser. I think from now on, I am going to open the docs in two windows. I haven't resorted to printing it out, but that might help too.
A couple of weeks ago I had old code that worked, but when I tried to go back into the documentation to look at the bit level descriptors, I came away thinking... I don't know... it works but I don't see it here. Obviously, it is in there, but over time I forgot how I accessed it.
For the amateur, It all comes down to use case examples. There will be a finite number... which you will be able to use, without requiring the user to have a holistic understanding of the P2.
Bottom line... it all looks complicated, but it is actually very simple to use. That doesn't seem possible, but it is:)
Why do we need #? Can't we just use ## all the time?
I don't know and I don't care:)
I fixed up the post a bit for you anyway.
Interesting. I see the AUGx instructions to be very RISCy. It's only the ## syntax sugar that makes it feel CISCy.
The Prop 2 looks to be one awesome chip.
The explanations with examples will be of critical value for the early appreciation of the device.
I look forward to any and all learning resources as I await its availability.