Thoughts on memory
System
Posts: 42
in Propeller 2
This discussion was created from comments split from: 7,000 P2 Rev. C Chips delivered to Parallax!.
Comments
Agreed on tools. When will you share your plans beyond PropTool, because that's not going to cut it this time around.
PropTool caters to existing customers, but Spin2 turns them away because it's different enough to make many things fail to work as expected from Spin1.
And these days way more potential customers don't want Windows, and they want standard languages.
Time to start officially supporting cross platform tools that do C/C++, BASIC, Micropython, etc. that the overwhelming majority of coders want.
you have a very nice way to formulate this.
My language would be more filled with $%^%$^&%$, but I also think that Parallax should make some deal with @ersmith and official support FastSpin/FexGui as Parallax provided tools.
I also think that PropTool should support FastSpin and Spin2, so that one could use it to compile to ByteCode or native.
Sadly this never happened with OpenSpin, thus the reluctant use of it, even supporting some precompiler for idefs and friends.
It is about branding, some PARALLAX approved sticker on it would help a lot. And Eric's Compiler Collection is - by far - the most interesting and powerful tool on the P2 horizon, it even gives the P1 a big boost, languagewise.
I am not a C guy but I could see that some port of the simple Library of PropGCC seems to be underway (is it you doing that?) and that would help a lot to get the Blockly side of things over to P2, using FastSpin.
I met Chip and I like and respect him, and I also understand his need to build Spin2 as he is imaging it. I am amazed that Eric can follow so close. But I do not understand why Chip can't leave the registers needed for the ROM monitor free in the Interpreter COG. This is just WRONG.
Mike
The ROM shadow space in $FC000..$FFFFF is going to be swallowed up by the debugger. If someone wants a monitor, they can include Cluso's latest into their compilation without any net memory penalty.
Clusso has rewritten the rom monitor routines to use different registers and it works perfect with Spin2 via Pnut.
It would be nice to not use another loaded Module, but the in ROM existing ones.
So you would need to spare those longs to be able to call the ROM routines as they are from within a Spin Program.
Which registers are affected is not in my mind right now, but @Cluso99 has a thread about it, I think we are talking about 4-6 longs in the upper COG ram which need to be available for parameters to call the ROM functions inline within a COG running the Interpreter.
And you might be able to leave those fixed locations alone and every monitor and SD function in the rom would be callable again.
Enjoy!
Mike
And then there is the SD routines and they take $1C0-$1DF (32 registers). TAQOZ uses others and HUB $0-$FFFF. How far do you go?
These routines are great for getting started without anything else connected (no FLASH or at least not programmed, no SD Card or at least not with the boot file(s)). But once you have a system up and running these do not matter so much as they can be added with extensions, etc.
Don't let me get started on spin2
Just writing PASM solves the problems, but I actually DID like the P1 way to have a Spin Main process and the rest in PASM.
But - I am just a tinkerer, not a main customer - so maybe I am WRONG. This is a Microcontroller. I would like to be able to understand the HUB RAM usage and be able to place stuff where I would like to have it, nor where my compiler thinks it could/should be.
That is what drove me to the MC world in the first place, to know what is going on, on the System, completely.
Now we have the same BS as with windows, not knowing what is running where and why. Just horrible.
So back to assembler for all of it. Then one can place stuff where one wants it. Thankfully both Pnut and Fastspin support this.
And - smile - PASM is quite a nice language...
Mike
I think we all agree that Chip is a very talented hardware designer. His views about how he implements certain things in software are sometimes very "special", though. I just want to mention that he wrote the whole P1 propeller tool in x86 assembler if I remember correctly. This is surely something very few other people would do theese days.
But if you don't like it you can use other tools.
And yes, I also vote for parallax supporting Erics Fastspin compiler.
I would like to be able to calculate HUB addresses, but I have not found out yet how to do so. In p1 Spin you had at least @ to find the relative HUB address and @@ to find the offset of the module (or @@@ in BST to have a fixed address at compile time) but in P2 Spin you are simply lost.
@Cluso99 describes the problem nicely in this thread https://forums.parallax.com/discussion/171649/still-struggling-with-hub-locations-in-spin2-and-pnut
The solution seems to be to patch your PASM and add a offset of $ff8 to all references of HUB variables, but @ersmith writes:
jmp-tables might work, but if you need access to HUB variables you fall flat again and have to patch your PASM.
One can compile PASM in a DAT section for HUB exec using say ORGH $2000, it gets compiled to run at HUB $2000 but it is not put at $2000 in HUB, you have to move it there first, then having two copies of it in you memory map.
If Pnut would at least support IFDEF and friends one could maybe get away with one code listing, but this does not work either.
so I am utterly lost here,
Mike
In essence, it is an absolute necessity that I configure hub with fixed known locations if any speed is to be obtained.
Code can’t be patched for correct addressing as I have 12 bit and 10 bit address vectors for the decoding. Instructions that are executed in cog and LUT are 10 bits and hub are 12 bits. The 12 bit hub addresses require that these routines be placed between $400-$1000 in hub and it’s full as is cog and LUT. The address tables are in hub and are again in a fixed hub location - can’t recall right now as I’ve been moving them.
These tables are huge with a long entry for every Z80 instruction. I’d have to “patch” every one of these (there are 3 addresses in every long!).
I can’t use spin2 (pnut) in any of my code ie no other cog can run spin2!!! This is because of its non- flexible nature of doing what it wants to do. It’s straight out of the MS playbook of you don’t need to know, we know what’s best for you
It’s precisely why we work with the prop, and why Chip wants to get back to the metal which cannot be done with PCs any more, or even on most ARM chips either. That’s the fundamental reason we are here. To deprive that fundamental removes the reason.
And, for the benefit of other non P1 people, we had the same problem with P1. To overcome the shortcomings of PropTool, two others (Brad and Mark) wrote P1 spin/pasm compilers (bst and homespun) that were PropTool binary equivalent but added the @ @ @ operator to get the absolute address, and to add #define and #include for conditional compilation. This was almost 10 years ago.
These guys did this without PropTool source access and no help from Parallax as far as I understand. These were required to build Catalina because I believe absolute and conditional addressing was a requirement. In fact Ross modified homespun to tailor its functions. PropGCC uses OpenSpin which has #define and IIRC #include and I think Roy did @ @ @ too. These have never been added to PropTool despite the call for them for more than 10 years, and as you’ve heard, is Parallax’s primary tool for bothP1 and P2.
bst and homespun were the basis of many code development on P1. Without them, many P1 applications would not have been written.
Anyway, this is all moot as far as I’m concerned. I am no longer writing spin2 code (for pnun/PropTool) and any pasm code I publish will be restricted to only support pasm because it’s almost impossible to release pasm code that is compatible with both pasm and spin2 using pnut/PropTool without jumping through hoops and moving or patching code after loading.
I posted a simple example on my “Struggling to come to terms with spin2 and pasm” or something similar to this title. I’m on an iPad so it’s not easy to copy a link.
However, right now there are far more pressing matters that impact the future of Parallax and P2.
PNut, PropTool and a bunch of other things absolutely must be finished and released for early adopters. Yes, many different opinions will exist on how things are implemented, and when they should have been implemented, but at this stage anything and everything is a distraction and delay which cannot be entertained. Chip can only complete the tools if he does so in the way he thinks best, and if we all trust in him and support him with our patience to do that.
Once "tools" version 1 is actually released, of course improvements could be made, and new features added.
But crucially, the first release means customers can start buying product and using it.
There are many waiting for the tools and product that do not require alternative memory handling, etc. Getting the ball rolling is the priority now, with what we have today.
Slightly off topic, there's a sense of deja vu here! Was it the very same Chip that developed a bunch of PIC tools many moons ago, because at that time Microchip was just getting started and didn't have the tools available that Chip wanted to work with ?!
Maybe some 3rd parties will do the same (or continue to do the same) with P2. Seems there is an opportunity as I don't see Parallax being able to launch the new hardware and produce all the tools to suit every language and user. Not all at once anyway.
I'm sorry, but I don't believe for one minute that Chip is some delicate flower who must be protected from any and all criticism lest it distract him. Chip is a smart and talented guy. He produced the P2 hardware in the full light of day, taking input from many sides and creating a balanced and wonderful result. Yet for some reason all talk of tools has been shrouded in darkness and mystery.
In fact there were a great variety of tools available even before the hardware was released. @"Peter Jakacki" created TAQOZ, which is a very full featured Forth system that does a tremendous amount with very few resources used. @"Dave Hein" created p2gcc and loadp2. @RossH ported the Catalina C compiler to P2. @ozpropdev created a Python based loader, a debugger, and various other tools. I created a number of tools that people have found useful. This list is very incomplete; there is certainly a lot of interesting work being made by many forum users.
Yet for some reason all of these early tools have been steadfastly ignored and deprecated by Parallax. Only the "official" tools count, and until those are done it's claimed that the P2 will not be usable. I don't buy it, and frankly I find it insulting. Moreover, I think a lot of early adopters are very frustrated at Parallax's refusal to talk about their tool strategy. We know (vaguely) that Chip and Jeff are working on Spin2 and PropTool, but we don't know what platforms are being considered or what the aim is. @"Ken Gracey" mentioned in the newsletter that someone was working on MicroPython. Who? Are they basing their port on mine? Is there a time frame for when it will be delivered? What C compiler are they using, and will that be released to the rest of us eventually?
The contrast between Parallax's openness on hardware and closeness on software is startling and dismaying. I'm sorry to sound so negative, but I really want the P2 to be a success, and I fear that Parallax is squandering an opportunity here.
Everyone is passionate about P2, that's obvious. And after 13+ years the chips are in stock. The first Parallax tool is needed, and once that's done I'm sure time and resources will become available to be more open. Sometimes first, people just have to get the job done.
Let's be positive!.
Also merged two similar threads to this one.
Parallax are a hardware company. Chip designs truly brilliant hardware, and the P2 looks like being an absolute stunner. Sure, his approach to software is ... well, unique would not be too strong a word.
But this is all part and parcel of the Propeller! It's why we love it! If you want boring old compilers, bloated and overblown languages and fancy hand-holding toolsets, buy an Arduino. We prefer to live on the edge!
Yes, yes, and yes. We are passionate about the P2, Yes, chips are in stock. Yes more is needed. But no, people have not been waiting for "someone" to get the job done, the forum has been getting the job done for many many years. However, and this is a huge however, it's just not being supported or even acknowledged by Parallax mostly. Yes, Chip is busy. Yes, Ken is busy. Yes, there is no official P2 project manager who can oversee the project and doesn't get bogged down in the details themself. But if there were then all those baskets full of goodies that have been languishing at Parallax's doorstep all these years and are piling up day by day could be scooped up and put to very good use. Hey, maybe we might even become more passionate and motivated to do even more.
@ersmith
Hear! Hear! While I find the P2 hardware thrilling and amazing, when it comes to P2 tools and documentation I am both bedazzled and dismayed at the same time. Despite the huge huge high quality contributions in both of these departments, nothing seems to be "officially" adopted or even acknowledged. When I look at all the awesome work that has been done and is being done in terms of tools, compilers, documentation, diagrams, examples etc I am totally bedazzled but when I look at the official "documentation" and the official tools (PNut), I must admit I shake my head and I guess that means that internally, though I deny that it is so, that I am in fact dismayed.
There, that's out in the open, and Eric, you mentioned names and projects and while many and most of the regulars have contributed vast amounts, and even us Aussies have been in there strong
As for getting the nice diagrams into the documentation: It's a google doc with suggestions enabled, the real question is why no one has bothered to put them in there yet?
Eric,
I could not have put it better myself. But I will add to this.
Many have written lots of code for the various flavours of the P2 while it was being created using the FPGA. Remember P2HOT. There was lots of code that was just "wasted" when P@HOT was killed. In hindsight probably the wrong decision but that's another story.
Even before P2HOT came into being there were even earlier incarnations. Peter converted his TACHOS to run on the various flavours. And a modified version of that (TAQOZ) resides in the P2 ROM. My Serial/Debugger/Monitor was developed way back in 2013 for the P2, running in LMM. Of course we now have hubexec but the naming of the registers lmm_x etc is a derivation of that code, and is present in the P2 ROM. This also had a dis-assembler but the instruction set change so often that it fell by the wayside. And besides, there was no space in the P2 ROM. My SD Driver was running on the earliest P2 FPGAs, and a cut down version resides in the P2 ROM so that you can boot directly from an SD Card without requiring a FLASH chip.
IIRC PropGCC was running on one to the P2 FPGAs. We has P2ASM written by one of the Dave's (sorry cannot recall which one). This was used to get a listing of the P2 ROM as we still cannot get a usable listing from pnut. Of course we have Eric's fastspin that produces a great listing.
Unfortunately criticism is due to Parallax. Chip almost always in his wisdom disregards anything done by us forum members. Now don't get me wrong. Chip has every right to do so. But to me, and I know many others, we are quite upset by the total disregard for the work we do and time spent on it.
Eric has done an absolutely fantastic job with his compiler(s). But at every turn, IMHO Eric has been snubbed by keeping the workings of spin/pnut private.
Ross has ported Catalina to the P2.
Come on Parallax. We've put our heart and soul in helping you develop the P2 and tools. And you cannot take any criticism, which IMHO is totally justified.
Peter designed the very first P2 board, the P2D2 pcb, and sent them over to Parallax so they could populate the very first working P2 boards.
And the first peeps from those boards were the TAQOZ Serial/Monitor prompts.
If there is a problem, often they can be sorted. If there's no discussion then you can absolutely be guaranteed they will never be changed/fixed/resolved. It's only by discussion that you can get a handle as to whether it's a real or perceived problem. I can assure you the problems I've encountered are very real to me, and it seems others too. Remember, in a group of maybe 10 at best, a sample of more that one is 20% at least.
Eric, there's no darkness and mystery around our tools because we don't have much to offer at this point. It's less clear what we will do with the software tools created by the community. I don't think the situation is really like you described above. You mentioned that we ignore and deprecate tools made by anybody but us. About a month or two ago, you met with Jeff, Chip, and myself and we took a look at everything that FlexGUI can do. In fact, we also featured the community efforts mentioned above in a newsletter https://mailchi.mp/bb7fe7af3351/propeller-2revision-c-p2x8c4m64p-es-delivery-update. In fact, every single tool we know of is listed on the Propeller 2 site right here https://propeller.parallax.com/
We value everything you and others have contributed. We just haven't had much public communication to make that clear. I'm sorry we're not doing a good job in this regard. Communication is a responsibility of mine, so it's no wonder anybody knows what our official plan is exactly. I'm actually far too busy trying to generate the income to cover the P2 project. Until recently, it's been a challenge to define where we're headed with tools - Chip has moved to debugger documentation and Jeff just recently started Propeller Tool revisions.
Customers need to know is that we have limitations to our resource level (i.e., limited staff and funds). Lots of sacrifices have been made by our company to finish the P2 hardware. To keep the company going, most of our team works on the educational business. Only Jeff and Chip - and part-time from our Editor - can work on anything P2 within Parallax [but I'll join in 10 days].
It is important to Chip that we produce an official tool so we can connect the hardware and software together the way he envisioned (and yes, he can handle the feedback as you noted). Almost every commercial product made with the P1 used Propeller Tool and Spin, so it seems reasonable Chip should complete his effort.
Having boot-strapped the effort, we also need to focus on near-term returns. Moving the compiler from X86 assembler to C makes wonderful business sense in the long-term for Mac/Linux IDEs, but this is something Chip would do. He may think it would take three weeks, but I can guarantee three to six months. Or, we can finish what he started and have Windows support - and get customers started. Not knowing all the variables, an observer would find this approach to be an absolute business mistake these days. Multi-platform support will take us time.
The MicroPython code we've been working with is from the guys in Oz. I've only recently gained an understanding how it works. I'd like to see how the alternatives work (see below).
I'd also like to ask you to respect that we up with the responsibility of supporting everything we offer - whether official Parallax or not [some customers may not know the difference because we are not clear, and we want to help them all]. This means we take telephone calls and e-mail inquiries on software we cannot support or control. Some of these systems are official Parallax offerings made by others, too, like Brett's Propeller IDE or Hanno's PropScope. What are we to do when Apple releases an update that breaks these tools? Simply having their code base in GitHub isn't enough sometimes. We just finished a total rewrite of the BlocklyProp Solo tool, which was started externally. We don't have "not invented here syndrome" but we certainly need to understand what we're doing when we start to offer and support software we haven't written.
How about this proposal after this coming week (I am fully booked on distance learning classes for teachers):
1. Let's talk! I don't think forums are the best place to discuss our adoption of your tools or others. I'd like to meet with you directly and learn exactly what you'd like to see us do. Business, the MicroPython port, technical issues, whatever. Tell me exactly what you envision. I think we just need to understand each other to appreciate what the statements made on forums mean for both parties. I don't have all the pieces in mind yet. Note: I want to talk with ALL tool/hardware developers and can schedule meetings with them too. Send me a message kgracey@parallax.com
2. What is the Parallax tool plan? We need to communicate this, openly. I think we made some steps forward last week and we need to tell people what they can expect from Parallax. Give us two weeks.
I'm sure that transparency and communication can create a better understanding.
Thoughts?
Thanks,
Ken Gracey
kgracey@Parallax.com
916 625 3010 direct