Sphinx was limited by the 32K of hub RAM. P2 will have 512K of RAM, which is 16 times what P1 has.
Of course, but P2 users are also going to expect to create much larger programs, hence my mention of memory ratio. (the ratio between largest possible binary size, and max available (practical) compiler memory)
That ratio on P2 remains at 1:1, exactly the same as P1.
The Sphinx Spin compiler worked on single objects at a time, and then linked them all together with a separate linker. So the available RAM limited the size of the object, and not so much the size of the whole program. With 512K of RAM a compiler should be able to handle a fairly large object. Of course it will have limits, but I would guess that most objects could be compiled with 512K available.
Just add a HyperRAM and you've got enough memory to compile anything, by whatever methodology you'd want.
So the idea would be to use the HyperRAM as a RAM-disk for temporary files? How would that be better than using an SD card? Would it be faster?
You wouldn't have to read and write files to perform a compilation. You could do it all in memory, maybe addressed, or using it as a RAM-disk. I think it would be a lot faster, and no write-wear.
Are you saying there would be a way to map the HyperRAM into hub address space and use it directly? How would that work?
I mean that you could keep track of where you put things into it and retrieve them whenever needed.
Darn! I thought you meant you had added an external memory bus while I wasn't looking! :-)
Sphinx was limited by the 32K of hub RAM. P2 will have 512K of RAM, which is 16 times what P1 has.
Of course, but P2 users are also going to expect to create much larger programs, hence my mention of memory ratio. (the ratio between largest possible binary size, and max available (practical) compiler memory)
That ratio on P2 remains at 1:1, exactly the same as P1.
Isn't that true of any self hosting computer system? It certainly was when I was writing programs for a 64K system on a system with only 64K of ram, and even less was available since the OS used up part of that 64K memory. That was why we had external storage.
Sphinx was limited by the 32K of hub RAM. P2 will have 512K of RAM, which is 16 times what P1 has.
Of course, but P2 users are also going to expect to create much larger programs, hence my mention of memory ratio. (the ratio between largest possible binary size, and max available (practical) compiler memory)
That ratio on P2 remains at 1:1, exactly the same as P1.
Isn't that true of any self hosting computer system? It certainly was when I was writing programs for a 64K system on a system with only 64K of ram, and even less was available since the OS used up part of that 64K memory. That was why we had external storage.
Yes, systems for software development typically have external storage attached the the processor. It can be a disk or an SD card or even a HyperRAM as Chip suggested. This allows the development tools to create images that can fill the entire addressable memory space. If you don't have that external storage available, you will be restricted to compiling programs that are smaller than the available memory.
On the subject of "RAM-disk" I do this with my SD files in Tachyon which are actually built on a virtual memory layer so that I can just address the data that I'm interested in and if it is not already cached it then flushes one of four sector buffers and reads it in. With this method I can address up to 4GB in a file so why wouldn't you do something similar for a Prop hosted compiler? So the compiler can write the image easily as if it is in RAM without actually having to use a HyerRAM, just the SD card where you have your source code. In fact I'm quite sure I could write a Spin2 compiler in Tachyon, either hosted on a P1 or P2, both of which are up and running
On the subject of "RAM-disk" I do this with my SD files in Tachyon which are actually built on a virtual memory layer so that I can just address the data that I'm interested in and if it is not already cached it then flushes one of four sector buffers and reads it in. With this method I can address up to 4GB in a file so why wouldn't you do something similar for a Prop hosted compiler? So the compiler can write the image easily as if it is in RAM without actually having to use a HyerRAM, just the SD card where you have your source code. In fact I'm quite sure I could write a Spin2 compiler in Tachyon, either hosted on a P1 or P2, both of which are up and running
I like the idea of getting away with using a SPI flash as the additional memory needed for on-chip development/compilation. No extra pins required!
On the subject of "RAM-disk" I do this with my SD files in Tachyon which are actually built on a virtual memory layer so that I can just address the data that I'm interested in and if it is not already cached it then flushes one of four sector buffers and reads it in. With this method I can address up to 4GB in a file so why wouldn't you do something similar for a Prop hosted compiler? So the compiler can write the image easily as if it is in RAM without actually having to use a HyerRAM, just the SD card where you have your source code. In fact I'm quite sure I could write a Spin2 compiler in Tachyon, either hosted on a P1 or P2, both of which are up and running
I like the idea of getting away with using a SPI flash as the additional memory needed for on-chip development/compilation. No extra pins required!
True, but SD is cheap and standard unlike SPI Flash which although it could be integrated into the filesystem, they have all these weird and wonderful block sizes and commands. It's a pity that we can't buy a chip SD memory but I can solder microSD direct to the pcb but then again a small socket positioned next to the chip so that the card inserts over it is a way to go too.
I like to share pins, so really all that the SD would require is a chip select and it could share clock and data with the SPI Flash.
So the idea would be to use the HyperRAM as a RAM-disk for temporary files? How would that be better than using an SD card? Would it be faster?
RAM avoids any endurance issues and avoids write delays, and HyperRAM is 8 bits wide, Double data rate.
All of that means significant boiler-plate speed gains over 1b SPI SD.
That said, HyperRAM does need refresh management, so it is not quite as simple as SRAM to include.
They spec a tCMS, which is in microseconds, so the possible R/W burst length count becomes clock-dependent.
This would be managed by the RAM-Disk emulation code, so would be invisible to the user.
I have to admit, I'm completely unenthusiastic about target-hosted dev systems. That's so last century. Nobody wants another TRS-80 BASIC or its Prop-based equivalent. Chip, please put your energy into a professional cross-platform dev system that's divorced from the target, and forget this nonsense about a Prop-based Spin dev system.
I have to admit, I'm completely unenthusiastic about target-hosted dev systems. That's so last century. Nobody wants another TRS-80 BASIC or its Prop-based equivalent. Chip, please put your energy into a professional cross-platform dev system that's divorced from the target, and forget this nonsense about a Prop-based Spin dev system.
Personally, I would always choose a PC hosted development system, but I can see some merit in a self-hosted example for education.
The important distinction that occurs here is my PC hosted developments target Microcontrollers, whilst a 'self-hosted' design has crossed over the boundary, to become a Microprocessor system.
ie it needs to have Flash Drive/Ram Drive resource, as well as the P2, so is no longer single-chip-microcontroller design.
ie if Parallax chose to offer a P2 module with P2 plus S71KL512SC0BHV000 (512Mb FLASH+64Mb DRAM 24FBGA), that could have its own niche.
I have to admit, I'm completely unenthusiastic about target-hosted dev systems. That's so last century. Nobody wants another TRS-80 BASIC or its Prop-based equivalent. Chip, please put your energy into a professional cross-platform dev system that's divorced from the target, and forget this nonsense about a Prop-based Spin dev system.
Thanks,
-Phil
You wouldn't believe the flakiness I encounter daily with my PC's. Well, you might. The darn things must have termites, or something. It just keeps getting worse, too. I kind of want off the boat.
I got my son a Raspberry Pi for his birthday and we made a NOOBS micro SD card for it today. This thing is just another PC! Maybe a more stable PC, and certainly cheaper, but it pretty much inhales the current universe of PC-minded software. Personally, I don't see what the fun of programming it would be, because you're never going to displace the preeminence of all kinds of OS-related junk that's in the way of you actually CONTROLLING it and achieving reliability. It's more like a Maker Faire attraction, where there's a bunch of construction paper, pipe cleaners, glue, and scissors lying around, and you get to make some crude creation that runs in a Window. That's just not interesting to me. I can hardly even recommend it to my son. It's a decent Web browser, though, connected to an HDTV.
Anyway, Phil, I just loathe the state of computing. I wish I felt differently. Today Delphi started crashing, relentlessly. I suppose if I just had the latest 100MB+ install of SuperWhizBang IDE, things might be awesome, but I'm convinced I'd only realize that my efforts were even more futile. Self-hosting might be a reactionary Luddite fantasy, but it sure seems good to me.
Anyway, Phil, I just loathe the state of computing. I wish I felt differently. Today Delphi started crashing, relentlessly. I suppose if I just had the latest 100MB+ install of SuperWhizBang IDE, things might be awesome, but I'm convinced I'd only realize that my efforts were even more futile. Self-hosting might be a reactionary Luddite fantasy, but it sure seems good to me.
+1
Just as the real benefit of the Space Race wasn't so much about putting boot prints on the moon, it's lasting benefit has been to develop new technologies and spawn countless new industries (at the time). I see a self-hosted system cutting through the cruft and letting us concentrate on getting the job done, and if that job is a compiler then it means we don't have to worry about what PCs and O/Ses that it will run on. Anyone with a P2 can develop tools for the P2, and some of that technology can be put to good use in target systems too, much like the Pi capitalizes on all the O/S software that it can run (and needs to run).
Maybe my P2 board that I design for XYZ product won't use most of that stuff, but I know I can easily debug and develop it in the first place with little more than a monitor, keyboard, and SD card so that the P2 becomes the PC and ICE all-in-one.
I have to say I'm with Phil here. Self hosting is niche at best. Compilation requires a decent amount of dynamic memory allocation and management, so you need a LOT more memory to develop something that fills it with any efficiency.
On my PC, I have 8 cores. Each of them can be compiling and optimizing a C file in parallel, then linking is the only single-core process at the end, so it's relatively quick. I like huge screen real estate when I'm coding - 2 HD monitors at a minimum with a font size that makes most people my age squint at the screen, and then at me. I like text editors with macro support, file-level search and replace, and so on, and so on, ...
Is it cool to let the Prop compile for itself? Sure. Is it useful beyond simple novelty? Debatable.
Is it the way most developers of microcontroller software work? Absolutely not.
I have to say I'm with Phil here. Self hosting is niche at best. Compilation requires a decent amount of dynamic memory allocation and management, so you need a LOT more memory to develop something that fills it with any efficiency.
On my PC, I have 8 cores. Each of them can be compiling and optimizing a C file in parallel, then linking is the only single-core process at the end, so it's relatively quick. I like huge screen real estate when I'm coding - 2 HD monitors at a minimum with a font size that makes most people my age squint at the screen, and then at me. I like text editors with macro support, file-level search and replace, and so on, and so on, ...
Is it cool to let the Prop compile for itself? Sure. Is it useful beyond simple novelty? Debatable.
Is it the way most developers of microcontroller software work? Absolutely not.
So you are talking top end compilation which sounds like what you would do to target PC software that might require a 100MB binary but we are talking about the P2 with 512k RAM for code and data so the binary would be less than this. The requirement for the P2 compiler would be far far less than what you are comparing it to, so the argument and personal preferences don't really apply plus I laugh to hear that all "8-cores" of the PC are actually compiling and optimizing.
The Elev8 firmware currently takes about 35 seconds or so to compile and optimize, single core, on my PC. I'm working on adding multi-core support to SimpleIDE to get that down to something more reasonable because it's painful to iterate.
My machine at work has 40 cores and 192Gb of RAM, and yes, I semi-regularly hit 100% usage on the CPU with some of what I do, which is why I have the 2nd one. :-P
I am put off by the flaky PC's nowadays. In DOS days the PC was reliable. The later the version of Windows, the slower the PCs seem to become, and bugs seem to become more prevalent, not less.
Take for instance Outlook 2016/365. The outdated Outlook Express & Windows Live to me had less problems and better screen layout, and of course was free. These programs no longer work on Windows 10 using POP email servers. So I've been forced to the not free Outlook 2016/365. Yes, I have both Office 2013 and Office 365 licences, which have Outlook as part of the package.
Firstly, I don't like the screen layout and there is no option to go to the older Outlook Express or Window Live screen layouts.
Next, my Office 2013 automatically updated to 2016 even tho I didn't ask it to. Now Office 365 has interfered/updated Office 2016 so I am unsure what I really have installed.
FOr the past few months, Outlook will only work on a metered hotspot (from my iPhone or iPad). If it is unmetered, Outlook crashes with a message to close - cannot even get access my old emails in this mode. MS acknowledged the problem a few months ago, and even stated there is a fix that would be available shortly, then stated it is available.
But, last month my Office products now state that my programs are unlicensed, which is utter rubbish.
I am about to give Outlook the flick, having downloaded Thunderbird.
Now, a self-hosting Prop OS is a different system as far as I am concerned. I want to be able to be free of the PC when and where I want. Hence my development of Prop OS, together with Michael's spin compiler. I would love to be able to boot my P1 straight to the microSD Card, and not require any EEPROM at all. Having the OS and microSD provides a means of transferring files to and from a PC without requiring a PropPlug or alternative USB interface. With a simple 1pin PS2 keyboard and 1pin Composite Video, I can run the OS completely sans PC.
So I am all for the self-hosting ability. You don't have to use it, but you can if you wish.
At some point, the P2 has to make money for Parallax. In that light, what do you see as the P2's primary market, and how does a self-hosted Spin compiler contribute to that market?
Maybe my P2 board that I design for XYZ product won't use most of that stuff, but I know I can easily debug and develop it in the first place with little more than a monitor, keyboard, and SD card so that the P2 becomes the PC and ICE all-in-one.
While I like the idea of self-hosted development as it is done interactively with Tachyon or Espruino, I don't think I'd like to have to find space on my desk for another monitor and keyboard just to do P2 development. Or will this self-hosted system include a standards-compliant web browser, word processor, etc? The model I would likely use is to do all of my development on a PC and then use an interactive language like Tachyon or Espruino for debugging on the target or just to poke at the hardware to see how it works. I wouldn't be likely to do major development on the target board.
I am put off by the flaky PC's nowadays. In DOS days the PC was reliable. The later the version of Windows, the slower the PCs seem to become, and bugs seem to become more prevalent, not less.
Take for instance Outlook 2016/365. The outdated Outlook Express & Windows Live to me had less problems and better screen layout, and of course was free. These programs no longer work on Windows 10 using POP email servers. So I've been forced to the not free Outlook 2016/365. Yes, I have both Office 2013 and Office 365 licences, which have Outlook as part of the package.
Firstly, I don't like the screen layout and there is no option to go to the older Outlook Express or Window Live screen layouts.
Next, my Office 2013 automatically updated to 2016 even tho I didn't ask it to. Now Office 365 has interfered/updated Office 2016 so I am unsure what I really have installed.
FOr the past few months, Outlook will only work on a metered hotspot (from my iPhone or iPad). If it is unmetered, Outlook crashes with a message to close - cannot even get access my old emails in this mode. MS acknowledged the problem a few months ago, and even stated there is a fix that would be available shortly, then stated it is available.
But, last month my Office products now state that my programs are unlicensed, which is utter rubbish.
I am about to give Outlook the flick, having downloaded Thunderbird.
Now, a self-hosting Prop OS is a different system as far as I am concerned. I want to be able to be free of the PC when and where I want. Hence my development of Prop OS, together with Michael's spin compiler. I would love to be able to boot my P1 straight to the microSD Card, and not require any EEPROM at all. Having the OS and microSD provides a means of transferring files to and from a PC without requiring a PropPlug or alternative USB interface. With a simple 1pin PS2 keyboard and 1pin Composite Video, I can run the OS completely sans PC.
So I am all for the self-hosting ability. You don't have to use it, but you can if you wish.
I would be curious to know if you use your Prop OS and Michael's Spin compiler yourself for development of non-trivial programs?
At some point, the P2 has to make money for Parallax. In that light, what do you see as the P2's primary market, and how does a self-hosted Spin compiler contribute to that market?
To me, I see two market areas for P2/Parallax : Embedded control, at the Microcontroller end, and Education which can cover both Microcontroller and Microprocessor usages of P2.
The first out the gate will be Embedded control, as that is less work.
In the Microprocessor space, the P2 is no longer strictly a stand-alone MCU, but connected to something like HyperRAM+HyperFLASH, and WiFi, or Display+Keyboard.
That configuration could likely host (as one example) Project Oberon which does allow students to see a complete system function. Project Oberon already works on differing MPU targets.
..
While I like the idea of self-hosted development as it is done interactively with Tachyon or Espruino, I don't think I'd like to have to find space on my desk for another monitor and keyboard just to do P2 development. Or will this self-hosted system include a standards-compliant web browser, word processor, etc? The model I would likely use is to do all of my development on a PC and then use an interactive language like Tachyon or Espruino for debugging on the target or just to poke at the hardware to see how it works. I wouldn't be likely to do major development on the target board.
My desk is similar, & I also use Spice and Spreadsheets to graph MCU test results, and scripts to generate tables, and PC-side software often needs to be developed to talk to the MCUs.
A serious Programmers editor is a must, as is various IDEs for MCUs.
All that, excludes any self-hosting for me, but things like Project Oberon also appeal as educational.
Once you have an OS type MPU environment, RTOS/DOS-Like could be possible. ie in the space between Linux, and bare-metal MPU development.
Maybe my P2 board that I design for XYZ product won't use most of that stuff, but I know I can easily debug and develop it in the first place with little more than a monitor, keyboard, and SD card so that the P2 becomes the PC and ICE all-in-one.
While I like the idea of self-hosted development as it is done interactively with Tachyon or Espruino, I don't think I'd like to have to find space on my desk for another monitor and keyboard just to do P2 development. Or will this self-hosted system include a standards-compliant web browser, word processor, etc? The model I would likely use is to do all of my development on a PC and then use an interactive language like Tachyon or Espruino for debugging on the target or just to poke at the hardware to see how it works. I wouldn't be likely to do major development on the target board.
My thoughts exactly. Cute idea, but my desk isn't big enough for a second set of peripherals and I don't have a KVM switch, so self hosting on a prop is useless tech in this house. Having a REPL, though, is irreplaceable as Peter has expressed countless times with regards to ease of debugging, particularly if the board is Internet-enabled and the REPL can be accessed remotely.
I could go so far as to embrace a built-in minimalist debug monitor and light-weight scripting language (not Spin). Back when I was doing fruit sizers in the '80s, everything was done with the Zilog Z8. I used the Z8671 with the ROM-based BASIC interpreter. With this interpreter, it was possible to execute lines of BASIC either from a stored program ("run" mode) or immediately after they were typed into the terminal ("immediate" mode). The language also included a GO@ command that let you branch to any location in memory to execute machine code.
The immediate execution mode came in very handy for debugging. It did not need a bunch of settings or preliminary definitions to work, like Spin's CON, VAR, and OBJ sections provide. Just type and go.
The real programming (i.e. Z8 Assembly) was done off-line on either a CPM machine or a PC, and the resulting hex files uploaded to the targets (RS422-networked master/slave system) for storage in battery-backed RAM. I would not have wanted to do that development on the target system.
So if something like that were available on the P2, it would be a useful feature. But the scripting language must not be Spin. It requires too many preliminaries to get a program running. Again, type and go is vital.
____________
As far as the educational environment is concerned, the schools already have PCs, Chromebooks, or Macs. Plugging and unplugging keyboards, mice, and monitors to be used with a self-hosted Spin system would be completely unpalatable in that environment. It's hard enough to keep a couple dozen PCs running without the students man-handling connectors. And in the very common situations where the PCs are laptops, the schools would have to purchase extra monitors and keyboards to use with a self-hosted system. And where would a student store his work in progress? Where I taught, each student stored his programs on the school's server under his own account. With a self-hosted system, this would have to be done with multiple SD cards, unless you also had to have either Ethernet or Wifi connected to each one. But then, the schools IT staff would have to learn Propeller stuff to manage a situation like that. They simply won't buy it -- a total non-starter.
I don't see self-hosting as the primary development system for major commercial projects. But the ability to self- host in the field is an added benefit. In particular, the ability to swap microSD cards as an upgrade path is a credible alternative.
Education and hackers market is different. Here the ability to self-host is an additional feature. You can use any PC as a terminal to the self-hosting, where the student/hacker can use any PC available without requiring specific software on the PC. Alternately, a keyboard and monitor (or small portable LCD) will work just as well for the terminal. BUT, that does not preclude PC hosting development/debugging, and nor does it require the prop platform to be connected as the SD provides the code transfer mechanism if a direct connection (USB or wireless or Internet) is not available/wanted.
I could go so far as to embrace a built-in minimalist debug monitor and light-weight scripting language (not Spin). Back when I was doing fruit sizers in the '80s, everything was done with the Zilog Z8. I used the Z8671 with the ROM-based BASIC interpreter. With this interpreter, it was possible to execute lines of BASIC either from a stored program ("run" mode) or immediately after they were typed into the terminal ("immediate" mode). The language also included a GO@ command that let you branch to any location in memory to execute machine code.
Exactly that should be possible, even in Microcontroller mode.
The Zilog Z8 and Intel 8052 both offered ROM basic versions.
Looking at the Basic52 v1.31 available on the web, I see ~ 8000 lines of ASM51 code -> 8189 bytes of binary image.
( this has Sine/Cos/Tan/Sqrt/Pow & AutoBAUD )
Probably too large for one COG, but Hubexec makes that not an issue.
For Microprocessor mode, whatever final flavours might exist, I'd certainly like to see HyperRAM code running on P2 before the final silicon sign off. (just like USB functional testing has proven important)
Education and hackers market is different. Here the ability to self-host is an additional feature. You can use any PC as a terminal to the self-hosting, where the student/hacker can use any PC available without requiring specific software on the PC.
If you're already using a PC, I don't see any advantage in self-hosting. And once the code is entered into the Prop, there's still the issue of saving it elsewhere. With PC hosting, that's easy; with self-hosting, cumbersome.
You can use any PC as a terminal to the self-hosting, where the student/hacker can use any PC available without requiring specific software on the PC.
Ummm... Don't you require a terminal emulator? That is something that must be installed. If you're going to install that you may as well install the tools to do PC-hosted development.
I think self hosting would be useful in some instances. Any instrument that uses a PC or video display and keyboard for operator input/output would be a candidate for a self hosting system. Some of the spectrometers I looked after upgraded from DOS through most if not all the incarnations of Windows, and those upgrades were not simple or inexpensive. Far better from a cost and reliability standpoint to use a stable self hosting system for this type of application.
You are not alone in your frustration, or even despair at the state of computing today. I don't know any computer user, professional or otherwise, that is not thumping the table once a week and asking "Why, why, why?". Or more likely, WTF?
Things get changed all the time. Computers seem to do what their vendors want more than their purchasers. Nothing is predictable or reliable.
I think there is a lot to be said for the self hosting idea.
Back in the day we switched on our C64 or Sinclair or whatever and could immediately type code into it and run that code. With a storage mechanism, cassette tape, the thing could save our code over power cycles.
That essentially future proofed your code, as long as the machine lived and you had a TV to plug it into.
That made it very easy for kids and other beginners to get into programming. (Including my old dad who was busy learning how to program for the first time, in BASIC on a TRS-80, after he retired.)
There is clearly demand for this simplicity today. Check out the Espruino that runs Javascript on a tiny MCU. Or MircoPython.
As long a you can get a terminal interface into those to run the REPL you are in business. No IDE required. No dependence on any other particular machine or OS.
Of course one does not hook a screen, keyboard and mouse up to those little devices. No TV. Rather you use a web browser over USB or Bluetooth. Which can run on any mainstream machine today, and we can imagine well into the future.
Even a browser is not required, just a serial terminal interface.
These things are not suitable for hard-core, real-time developments, but they are programming of MCUs for the masses in the same spirit as the C64 and such.
Is the P2 suitable for this approach?
Well, as far as I can tell it should be possible to get JS, like Espruino or Jerryscript or others, running on the P2.
How we make use of all those cores in JS or Python or whatever is another matter...
Heater: You say you like self-hosting systems and Espruino but have you ever done anything with one other than type in simple programs? Have you developed a complex system with a self-hosted system?
Maybe I am still slow on reading, but why does the self hosting ability excludes external development?
If we have a build in development system on chip you do not need to use it, but can if there is a need.
I really liked the monitor of P2-hot. Something like that should go in for sure. Maybe able to be blocked by a fuse.
Having a Spin compiler and a simple (even serial) editor in there would be to much for the remaining ROM space, I guess.
But since the planned configuration will boot from flash anyways, there could be some need for a spin compiler running on the P2. But this does not have to be in ROM. In the opposite, if the next OpenSpin compiler written in C/C++ would be able to be also compiled by the next PropGcc and then run on a P2, things would be wonderful.
But having a basic monitor/debugger in ROM would be very helpful. Maybe a Assembler/Disassembler. With HubExec I think a lot of development will be done in Assembler, you are not restricted to them d...ed 512 longs. And that could fit in ROM and Assembler/Disassembler need just to change when the opcodes change.
All of this just using the existing auto baud serial interface for programming.
Else we would need to define pins for input (what) keyboard and output (what) video where?
Self hosting in the 8-bit time was easy, just plug in your TV. Not so easy now and for the next 20+ years.
I am still not sure about how that up to 16kb ROM is available after boot. To use encryption the second stage loader need to have access to the SHA routine, so the ROM content has to be somewhere in the HUB memory map. Where?
Maybe I am still slow on reading, but why does the self hosting ability excludes external development?
In theory, it doesn't. In practice, limited and precious resources have to be allocated in a timely manner to those tasks deemed most important. If less important tasks become a distraction from more important ones, that's a problem. I would contend that self-hosting falls way down the priority list. And, given how long it's taken to get this far, priorities have to be governed by what sells, not what's the most fun.
Comments
Isn't that true of any self hosting computer system? It certainly was when I was writing programs for a 64K system on a system with only 64K of ram, and even less was available since the OS used up part of that 64K memory. That was why we had external storage.
I like the idea of getting away with using a SPI flash as the additional memory needed for on-chip development/compilation. No extra pins required!
True, but SD is cheap and standard unlike SPI Flash which although it could be integrated into the filesystem, they have all these weird and wonderful block sizes and commands. It's a pity that we can't buy a chip SD memory but I can solder microSD direct to the pcb but then again a small socket positioned next to the chip so that the card inserts over it is a way to go too.
I like to share pins, so really all that the SD would require is a chip select and it could share clock and data with the SPI Flash.
You can use this Flash-Drive model, and it is simple, but designers do need to watch the endurance/wear specs of the chip chosen.
There are FLASH+RAM versions of HyperRAM now, so one 24FPGA package can give 512Mbit Flash, 64Mbit RAM
RAM avoids any endurance issues and avoids write delays, and HyperRAM is 8 bits wide, Double data rate.
All of that means significant boiler-plate speed gains over 1b SPI SD.
That said, HyperRAM does need refresh management, so it is not quite as simple as SRAM to include.
They spec a tCMS, which is in microseconds, so the possible R/W burst length count becomes clock-dependent.
This would be managed by the RAM-Disk emulation code, so would be invisible to the user.
Thanks,
-Phil
Personally, I would always choose a PC hosted development system, but I can see some merit in a self-hosted example for education.
The important distinction that occurs here is my PC hosted developments target Microcontrollers, whilst a 'self-hosted' design has crossed over the boundary, to become a Microprocessor system.
ie it needs to have Flash Drive/Ram Drive resource, as well as the P2, so is no longer single-chip-microcontroller design.
ie if Parallax chose to offer a P2 module with P2 plus S71KL512SC0BHV000 (512Mb FLASH+64Mb DRAM 24FBGA), that could have its own niche.
You wouldn't believe the flakiness I encounter daily with my PC's. Well, you might. The darn things must have termites, or something. It just keeps getting worse, too. I kind of want off the boat.
I got my son a Raspberry Pi for his birthday and we made a NOOBS micro SD card for it today. This thing is just another PC! Maybe a more stable PC, and certainly cheaper, but it pretty much inhales the current universe of PC-minded software. Personally, I don't see what the fun of programming it would be, because you're never going to displace the preeminence of all kinds of OS-related junk that's in the way of you actually CONTROLLING it and achieving reliability. It's more like a Maker Faire attraction, where there's a bunch of construction paper, pipe cleaners, glue, and scissors lying around, and you get to make some crude creation that runs in a Window. That's just not interesting to me. I can hardly even recommend it to my son. It's a decent Web browser, though, connected to an HDTV.
Anyway, Phil, I just loathe the state of computing. I wish I felt differently. Today Delphi started crashing, relentlessly. I suppose if I just had the latest 100MB+ install of SuperWhizBang IDE, things might be awesome, but I'm convinced I'd only realize that my efforts were even more futile. Self-hosting might be a reactionary Luddite fantasy, but it sure seems good to me.
+1
Just as the real benefit of the Space Race wasn't so much about putting boot prints on the moon, it's lasting benefit has been to develop new technologies and spawn countless new industries (at the time). I see a self-hosted system cutting through the cruft and letting us concentrate on getting the job done, and if that job is a compiler then it means we don't have to worry about what PCs and O/Ses that it will run on. Anyone with a P2 can develop tools for the P2, and some of that technology can be put to good use in target systems too, much like the Pi capitalizes on all the O/S software that it can run (and needs to run).
Maybe my P2 board that I design for XYZ product won't use most of that stuff, but I know I can easily debug and develop it in the first place with little more than a monitor, keyboard, and SD card so that the P2 becomes the PC and ICE all-in-one.
On my PC, I have 8 cores. Each of them can be compiling and optimizing a C file in parallel, then linking is the only single-core process at the end, so it's relatively quick. I like huge screen real estate when I'm coding - 2 HD monitors at a minimum with a font size that makes most people my age squint at the screen, and then at me. I like text editors with macro support, file-level search and replace, and so on, and so on, ...
Is it cool to let the Prop compile for itself? Sure. Is it useful beyond simple novelty? Debatable.
Is it the way most developers of microcontroller software work? Absolutely not.
So you are talking top end compilation which sounds like what you would do to target PC software that might require a 100MB binary but we are talking about the P2 with 512k RAM for code and data so the binary would be less than this. The requirement for the P2 compiler would be far far less than what you are comparing it to, so the argument and personal preferences don't really apply plus I laugh to hear that all "8-cores" of the PC are actually compiling and optimizing.
My machine at work has 40 cores and 192Gb of RAM, and yes, I semi-regularly hit 100% usage on the CPU with some of what I do, which is why I have the 2nd one. :-P
Take for instance Outlook 2016/365. The outdated Outlook Express & Windows Live to me had less problems and better screen layout, and of course was free. These programs no longer work on Windows 10 using POP email servers. So I've been forced to the not free Outlook 2016/365. Yes, I have both Office 2013 and Office 365 licences, which have Outlook as part of the package.
Firstly, I don't like the screen layout and there is no option to go to the older Outlook Express or Window Live screen layouts.
Next, my Office 2013 automatically updated to 2016 even tho I didn't ask it to. Now Office 365 has interfered/updated Office 2016 so I am unsure what I really have installed.
FOr the past few months, Outlook will only work on a metered hotspot (from my iPhone or iPad). If it is unmetered, Outlook crashes with a message to close - cannot even get access my old emails in this mode. MS acknowledged the problem a few months ago, and even stated there is a fix that would be available shortly, then stated it is available.
But, last month my Office products now state that my programs are unlicensed, which is utter rubbish.
I am about to give Outlook the flick, having downloaded Thunderbird.
Now, a self-hosting Prop OS is a different system as far as I am concerned. I want to be able to be free of the PC when and where I want. Hence my development of Prop OS, together with Michael's spin compiler. I would love to be able to boot my P1 straight to the microSD Card, and not require any EEPROM at all. Having the OS and microSD provides a means of transferring files to and from a PC without requiring a PropPlug or alternative USB interface. With a simple 1pin PS2 keyboard and 1pin Composite Video, I can run the OS completely sans PC.
So I am all for the self-hosting ability. You don't have to use it, but you can if you wish.
At some point, the P2 has to make money for Parallax. In that light, what do you see as the P2's primary market, and how does a self-hosted Spin compiler contribute to that market?
'Just wondering ...
-Phil
The first out the gate will be Embedded control, as that is less work.
In the Microprocessor space, the P2 is no longer strictly a stand-alone MCU, but connected to something like HyperRAM+HyperFLASH, and WiFi, or Display+Keyboard.
That configuration could likely host (as one example) Project Oberon which does allow students to see a complete system function. Project Oberon already works on differing MPU targets.
My desk is similar, & I also use Spice and Spreadsheets to graph MCU test results, and scripts to generate tables, and PC-side software often needs to be developed to talk to the MCUs.
A serious Programmers editor is a must, as is various IDEs for MCUs.
All that, excludes any self-hosting for me, but things like Project Oberon also appeal as educational.
Once you have an OS type MPU environment, RTOS/DOS-Like could be possible. ie in the space between Linux, and bare-metal MPU development.
My thoughts exactly. Cute idea, but my desk isn't big enough for a second set of peripherals and I don't have a KVM switch, so self hosting on a prop is useless tech in this house. Having a REPL, though, is irreplaceable as Peter has expressed countless times with regards to ease of debugging, particularly if the board is Internet-enabled and the REPL can be accessed remotely.
The immediate execution mode came in very handy for debugging. It did not need a bunch of settings or preliminary definitions to work, like Spin's CON, VAR, and OBJ sections provide. Just type and go.
The real programming (i.e. Z8 Assembly) was done off-line on either a CPM machine or a PC, and the resulting hex files uploaded to the targets (RS422-networked master/slave system) for storage in battery-backed RAM. I would not have wanted to do that development on the target system.
So if something like that were available on the P2, it would be a useful feature. But the scripting language must not be Spin. It requires too many preliminaries to get a program running. Again, type and go is vital.
____________
As far as the educational environment is concerned, the schools already have PCs, Chromebooks, or Macs. Plugging and unplugging keyboards, mice, and monitors to be used with a self-hosted Spin system would be completely unpalatable in that environment. It's hard enough to keep a couple dozen PCs running without the students man-handling connectors. And in the very common situations where the PCs are laptops, the schools would have to purchase extra monitors and keyboards to use with a self-hosted system. And where would a student store his work in progress? Where I taught, each student stored his programs on the school's server under his own account. With a self-hosted system, this would have to be done with multiple SD cards, unless you also had to have either Ethernet or Wifi connected to each one. But then, the schools IT staff would have to learn Propeller stuff to manage a situation like that. They simply won't buy it -- a total non-starter.
-Phil
I don't see self-hosting as the primary development system for major commercial projects. But the ability to self- host in the field is an added benefit. In particular, the ability to swap microSD cards as an upgrade path is a credible alternative.
Education and hackers market is different. Here the ability to self-host is an additional feature. You can use any PC as a terminal to the self-hosting, where the student/hacker can use any PC available without requiring specific software on the PC. Alternately, a keyboard and monitor (or small portable LCD) will work just as well for the terminal. BUT, that does not preclude PC hosting development/debugging, and nor does it require the prop platform to be connected as the SD provides the code transfer mechanism if a direct connection (USB or wireless or Internet) is not available/wanted.
Exactly that should be possible, even in Microcontroller mode.
The Zilog Z8 and Intel 8052 both offered ROM basic versions.
Looking at the Basic52 v1.31 available on the web, I see ~ 8000 lines of ASM51 code -> 8189 bytes of binary image.
( this has Sine/Cos/Tan/Sqrt/Pow & AutoBAUD )
Probably too large for one COG, but Hubexec makes that not an issue.
For Microprocessor mode, whatever final flavours might exist, I'd certainly like to see HyperRAM code running on P2 before the final silicon sign off. (just like USB functional testing has proven important)
-Phil
You are not alone in your frustration, or even despair at the state of computing today. I don't know any computer user, professional or otherwise, that is not thumping the table once a week and asking "Why, why, why?". Or more likely, WTF?
Things get changed all the time. Computers seem to do what their vendors want more than their purchasers. Nothing is predictable or reliable.
I think there is a lot to be said for the self hosting idea.
Back in the day we switched on our C64 or Sinclair or whatever and could immediately type code into it and run that code. With a storage mechanism, cassette tape, the thing could save our code over power cycles.
That essentially future proofed your code, as long as the machine lived and you had a TV to plug it into.
That made it very easy for kids and other beginners to get into programming. (Including my old dad who was busy learning how to program for the first time, in BASIC on a TRS-80, after he retired.)
There is clearly demand for this simplicity today. Check out the Espruino that runs Javascript on a tiny MCU. Or MircoPython.
As long a you can get a terminal interface into those to run the REPL you are in business. No IDE required. No dependence on any other particular machine or OS.
Of course one does not hook a screen, keyboard and mouse up to those little devices. No TV. Rather you use a web browser over USB or Bluetooth. Which can run on any mainstream machine today, and we can imagine well into the future.
Even a browser is not required, just a serial terminal interface.
These things are not suitable for hard-core, real-time developments, but they are programming of MCUs for the masses in the same spirit as the C64 and such.
Is the P2 suitable for this approach?
Well, as far as I can tell it should be possible to get JS, like Espruino or Jerryscript or others, running on the P2.
How we make use of all those cores in JS or Python or whatever is another matter...
If we have a build in development system on chip you do not need to use it, but can if there is a need.
I really liked the monitor of P2-hot. Something like that should go in for sure. Maybe able to be blocked by a fuse.
Having a Spin compiler and a simple (even serial) editor in there would be to much for the remaining ROM space, I guess.
But since the planned configuration will boot from flash anyways, there could be some need for a spin compiler running on the P2. But this does not have to be in ROM. In the opposite, if the next OpenSpin compiler written in C/C++ would be able to be also compiled by the next PropGcc and then run on a P2, things would be wonderful.
But having a basic monitor/debugger in ROM would be very helpful. Maybe a Assembler/Disassembler. With HubExec I think a lot of development will be done in Assembler, you are not restricted to them d...ed 512 longs. And that could fit in ROM and Assembler/Disassembler need just to change when the opcodes change.
All of this just using the existing auto baud serial interface for programming.
Else we would need to define pins for input (what) keyboard and output (what) video where?
Self hosting in the 8-bit time was easy, just plug in your TV. Not so easy now and for the next 20+ years.
I am still not sure about how that up to 16kb ROM is available after boot. To use encryption the second stage loader need to have access to the SHA routine, so the ROM content has to be somewhere in the HUB memory map. Where?
Enjoy!
Mike
-Phil