Learning to use assembly code on the Prop 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?

Comments

  • 18 Comments sorted by Date Added Votes
  • Read the two Google docs at top of http://forums.parallax.com/discussion/162298/prop2-fpga-files-updated-1-january-2018-version-31/p1

    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.
    "Are we alone in the universe?"
    "Yes," said the Oracle.
    "So there's no other life out there?"
    "There is. They're alone too."
  • I understand why at first glance it all looks far more complicated. It will take longer to completely master Pasm2, but that is principally because of it's increased functionality.

    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 read over the "streamer" documentation several times and I am giving up trying. It appears a bit to be the replacement for what are "counters" on the Prop 1.
    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.
  • The Prop 2 is not even available yet so I would not expect user documentation to be in good condition.

    Be patient.




  • evanhevanh Posts: 5,669
    edited January 28 Vote Up0Vote Down
    I'll disagree with RJO. Forget the Streamers, they are really DMA channels. Use them for special stuff and only after you've mastered most everything else.

    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.
    "Are we alone in the universe?"
    "Yes," said the Oracle.
    "So there's no other life out there?"
    "There is. They're alone too."
  • Make yourself familiar with ## assembler syntax. It's truly a lovely addition to a RISC architecture. But what you need to be aware of is it adds a prefix to any instruction you use it with. This uses another long-word of space and another 2 clocks to execute.

    "Are we alone in the universe?"
    "Yes," said the Oracle.
    "So there's no other life out there?"
    "There is. They're alone too."
  • evanh,
    Make yourself familiar with ## assembler syntax. It's truly a lovely addition to a RISC architecture. But what you need to be aware of is it adds a prefix to any instruction you use it with. This uses another long-word of space and another 2 clocks to execute.
    I don't know how more self-contradictory a statement can be.


  • What? Adding a CISC feature to a RISC architecture and then calling that lovely? ;)
    "Are we alone in the universe?"
    "Yes," said the Oracle.
    "So there's no other life out there?"
    "There is. They're alone too."
  • I love Pasm2. Cats meow. But ... Spin2 is going to be a lot faster than Spin1. You will lose very little using the advanced instructions directly from Spin2. It is going to be fun... and that is the key.: If it is fun... it is much easier to learn. Pasm2 is going to be popular.

    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.







  • MByron wrote: »
    I have read over the "streamer" documentation several times and I am giving up trying. It appears a bit to be the replacement for what are "counters" on the Prop 1.
    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.

    It's not complicated. We just need some more explanations with examples. You'll find it quite useable.
  • Heater.Heater. Posts: 21,178
    edited January 28 Vote Up0Vote Down
    evanh,
    What? Adding a CISC feature to a RISC architecture and then calling that lovely?
    Not exactly.

    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.

  • To me, pipelining is the defining trait of RISC. The 80486 is a RISC chip with some CISC baggage that only legacy software uses.

    "Are we alone in the universe?"
    "Yes," said the Oracle.
    "So there's no other life out there?"
    "There is. They're alone too."
  • Heater.Heater. Posts: 21,178
    edited January 28 Vote Up0Vote Down
    There has always been a lot of debate over what is RISC or not.

    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.
  • "Clearly" isn't much debate is it? You might need to fix your posting.
    "Are we alone in the universe?"
    "Yes," said the Oracle.
    "So there's no other life out there?"
    "There is. They're alone too."
  • MByron

    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:)





  • evanh,
    "Clearly" isn't much debate is it? You might need to fix your posting.
    Well no. The debate and supporting evidence were in the preceding paragraph. The last sentence just presents the logical conclusion.

    I fixed up the post a bit for you anyway.

  • Heater. wrote: »
    evanh,
    What? Adding a CISC feature to a RISC architecture and then calling that lovely?
    Not exactly.

    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.

    Interesting. I see the AUGx instructions to be very RISCy. It's only the ## syntax sugar that makes it feel CISCy.
  • Chip,
    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.
Sign In or Register to comment.