Shop OBEX P1 Docs P2 Docs Learn Events
P2 - Where will it be used? It's time for Parallax to step up and answer this! — Parallax Forums

P2 - Where will it be used? It's time for Parallax to step up and answer this!

Cluso99Cluso99 Posts: 18,069
edited 2020-02-15 07:14 in Propeller 2
I am frustrated to say the least.
It's no fun any more and that is the only reason I'm here :(

The original Z80 in the late 70's and early 80's rose to having 64KB of mostly RAM with some EPROM. It was a microprocessor. The P2 can clearly be considered a single chip microprocessor with 8x 32-bit cores and 512KB of Hub RAM and 200+MHz.

Back then, we had assemblers, linkers, and various compilers which all ran on that little Z80 with either a pair of 360KB-1.2MB floppies or if we were lucky a floppy and a 5MB HDD.
Lucky me - a Microsoft Z80 card in an Apple /// plus a Corvus? 5MB HDD where I designed/developed our own Z8 card running SDLC to an IBM mainframe and emulating an IBM 3270 Controller and 3274 Terminal, all on a n Apple //e or ///. We sold this to Apple USA in the early 80's. It certainly was not a toy.

Where is the P2 headed??? It can replace the whole microcomputers of the late 70's and early 80's. The tools of course don't exist for the P2 to do this, and any suggestion about this brings down the rath of those who cannot see this as a possible viable situation, except perhaps Chip.

But when I ask for the @@@ operator so we can determine the precise hub location for code, I get answers like this from Chip
cgracey wrote: »
I think the supposition that @@@ is needed might stem from some misunderstaning or even ignorance of what @ does. Minimal conveyance of @ values is required if you understand what's going on and plan things out a little.
Clearly, Chip does not believe there will be large programs run on the P2 as it is pretty much a given that tables of addresses, jump tables, and hub calls from cog, will need to know the precise location in hub. It WAS REQUIRED in P1 to do the sort of things the P2 is more suited to doing.

And for Roy,
It WAS ADDED to homespun and bst, if not originally, then very soon afterwards, as my other post showed.
It WAS INDEED REQUIRED. All the experienced forumistas of the time agreed. There were no alternatives.

Anyway, where is P2 headed???
I am obviously mistaken that it could host a nice development system as well as doing some real work.

Comments

  • Roy ElthamRoy Eltham Posts: 3,000
    edited 2020-02-15 07:37
    Chip's reply was reasonable, and does not lead to what you said it does about large programs. Sheesh man, you are all extremes.
    Jump tables don't require @@@. Like do you truly believe that? How can someone with as much experience as you believe that?

    I'm just boggling at your reaction here.

    I never said @@@ wasn't added to Homespun or BST, I said it was added AFTER they were released. You had said they were made to give us @@@, which is clearly wrong.

    P2 is headed to having hosted development of Spin2 (Chip intends to do that). P2 will have huge programs, even bigger than 512K, because you will be able to dynamically load code and run it at any address (you can build code that uses all relative addressing). Chip even intends that for Spin2.
    Not sure why you think the absence of @@@ = doom and gloom.

  • cgraceycgracey Posts: 14,155
    edited 2020-02-15 08:14
    It's maybe not hard to patch in actual @@@ values to final code, but to have @@@ incorporated into expressions is a much more complex problem to solve. Spin2 will probably never have that. It's not necessary.

    You can write huge blocks of assembler code that are relatively addressed from within, including jump tables and data tables, using JMPREL and LOC. They can even be moved around and executed. @@@ means that addresses must be fixed.

    As for where the P2 will be used, I don't know. Hopefully, it will find favor with people inventing things for which other solutions are of little help. That's all I've got.
  • When I was working on trying to make @@@ work for OpenSpin, everyone told me it had to work with expressions and anywhere. That made it really painful and impractical. If it could have been only in DAT data and only without expressions I might have got it working, but it still would have required a 3rd pass to fixup the final combined binary of all the objects.

    Homespun limited it to dat sections, and also turned of duplicate object removal when you used @@@ (based on the fix notes in the thread Cluso linked and the github page rosco linked). No idea on BST, it might have been less restrictive.

  • Dave HeinDave Hein Posts: 6,347
    edited 2020-02-15 14:58
    In the past, the @@@ operator would have been useful, but I've avoided it because the Prop Tool never supported it. In the top object I would just hard code a "+ 16" to any addresses I had stored in the DAT section because I knew that the top object always had an offset of 16. It was a bit kludgy, but it worked.

    For any other object than the top object, I would have an initialization routine that I would call when the program first started up. The initialization routine would add "@0" to all the object offsets stored in the object so that they would be absolute addresses.

    There are two different cases where I needed absolute addresses stored in memory. One case was in a Forth interpreter I wrote that needed addresses of Forth words. Using object offsets would have slowed it down. The other case is when I used arrays that contained a list of string addresses, or some other types of address lists. Its just more convenient to use absolute addresses.
  • RaymanRayman Posts: 14,646
    Adding @0 to my loc instructions sounds Better than my plan
  • Cluso99 wrote: »
    I am frustrated to say the least.
    It's no fun any more and that is the only reason I'm here :(

    The original Z80 in the late 70's and early 80's rose to having 64KB of mostly RAM with some EPROM. It was a microprocessor. The P2 can clearly be considered a single chip microprocessor with 8x 32-bit cores and 512KB of Hub RAM and 200+MHz.

    Back then, we had assemblers, linkers, and various compilers which all ran on that little Z80 with either a pair of 360KB-1.2MB floppies or if we were lucky a floppy and a 5MB HDD.
    Lucky me - a Microsoft Z80 card in an Apple /// plus a Corvus? 5MB HDD where I designed/developed our own Z8 card running SDLC to an IBM mainframe and emulating an IBM 3270 Controller and 3274 Terminal, all on a n Apple //e or ///. We sold this to Apple USA in the early 80's. It certainly was not a toy.

    Where is the P2 headed??? It can replace the whole microcomputers of the late 70's and early 80's. The tools of course don't exist for the P2 to do this, and any suggestion about this brings down the rath of those who cannot see this as a possible viable situation, except perhaps Chip.

    But when I ask for the @@@ operator so we can determine the precise hub location for code, I get answers like this from Chip
    cgracey wrote: »
    I think the supposition that @@@ is needed might stem from some misunderstaning or even ignorance of what @ does. Minimal conveyance of @ values is required if you understand what's going on and plan things out a little.
    Clearly, Chip does not believe there will be large programs run on the P2 as it is pretty much a given that tables of addresses, jump tables, and hub calls from cog, will need to know the precise location in hub. It WAS REQUIRED in P1 to do the sort of things the P2 is more suited to doing.

    And for Roy,
    It WAS ADDED to homespun and bst, if not originally, then very soon afterwards, as my other post showed.
    It WAS INDEED REQUIRED. All the experienced forumistas of the time agreed. There were no alternatives.

    Anyway, where is P2 headed???
    I am obviously mistaken that it could host a nice development system as well as doing some real work.
    Just use FastSpin. It doesn't have the @@@ problem and it also supports C which is likely to be quicker path to a self-hosted system since there are lots of tools floating around that are written in C and could be ported.

  • Rayman wrote: »
    Adding @0 to my loc instructions sounds Better than my plan

    Actually, now that I think about it I believe is was @@0 that I used, which gives the address of the start of the object.
Sign In or Register to comment.