Yes, I saw it, but haven't had time to investigate. Getting this baby one working took minutes - getting its big brother working one would probably take hours.
Perhaps later this week.
Ross.
Hi,
After some of such hours I got the "big brother compiler" at least working in MinGW. I had to throw out
//#include <net.h> and everything that needs it.
The compiled code of c.c is 63kB. The separate virtual machine eu.exe has a length of 58kB. So it seems to be possible to run these with P2. :-)
Christof
Yes, I saw it, but haven't had time to investigate. Getting this baby one working took minutes - getting its big brother working one would probably take hours.
Perhaps later this week.
Ross.
Hi,
After some of such hours I got the "big brother compiler" at least working in MinGW. I had to throw out
//#include <net.h> and everything that needs it.
The compiled code of c.c is 63kB. The separate virtual machine eu.exe has a length of 58kB. So it seems to be possible to run these with P2. :-)
Christof
Good work. I gave up on MinGW but I got it to at least compile itself under Linux before I ran out of spare time. Is there some trick to getting it working under MinGW? All I get is link errors.
As quick and dirty hack just to get an idea of size, I commented out the dozen or so lines that are not ANSI C compliant, and I get c.c to compile to a code size of about 50kb (COMPACT mode) or 80kb (NATIVE mode) with Catalina. The code that needs to be converted to ANSI C would not add much, so yes I think it could run on a P2.
However, this version is 2500 lines - 5 times larger than the baby version - so while it could probably compile useful C programs, it might not be able to compile itself on the Propeller.
This was wrong: "There seems to be something wrong with the access of global variables. The compiler compiles address 0 for the first variable. And eu.c puts this at the absoute address 0! It should be an offset to a data segment, which comes after the bytecode, as far as I understand. I don't understand, why this gives no address violation with MingGW. I then switched over to a fork: https://github.com/ghaerr/swieros Here this problem is addressed and the access is different with a offset but I still don't think it is correct. And now areas, which are allocated with malloc will be adressed wrongly, I think?"
Some simple programs, precompiled with MinGW can be executed, but not the compiler at the moment.
Edit: I seem to have something gotten wrong about the adresses.
Edit2:
Had contact with Robert. The asm output print is done before addresses are known, as code length is unknown. They are then corrected just before the bytecode file is written as pc-relative addresses. So code AND data is relocatible. Switched back to Roberts Github.
@Electrodude said:
I think @msrobots just means turning on the write-protect for the top 16KB of hubram.
Yes, and several of us asked for that feature for this purpose. Chip then extended it for additional use with the excellent debug system.
Eventually, I plan on returning to this topic of a stand alone P2 dev system. For my personal one, I'm going to put a P1 and or P2 on two cards that will go into an Apple ][ computer system. For me personally again, that'll be fun, and it's got a nice keyboard and all of that stuff.
Having a shell, and the basics of a Dos in the 16k ROM area would be fantastic!
I think having more than one SD card set up would be good too. Basically one is the system SD card, and the other one is for general purpose data storage output all of that stuff. But those are all things that come later after the minimum requirements.
And I agree with serial being that minimum Communications requirement.
If it were me I would do the old school ps/2 keyboard and mouse, just because it's super lean and efficient.
(Hey everyone! I am still building a business involving laser metal printing and read the happenings here regularly, but have very small amounts of Prop Time (TM lol), most of which is P1 product related. We have a polymer material management cabinet product that uses the P1.)
Perhaps another discussion about what "stand alone", and "self hosted" means to or for everyone, and what planned use cases look like would be valuable?
I will start another thread, drop a link, and put mine up to start.
@msrobots said:
...
You might not like the idea, because you will need to overwrite TAQOZ in ROM with your OS/Shell/Bios.
Is that possible without the new chip revision ? I would think if it's in ROM then it can't be overwritten, can it ?
@"Christof Eb." agreed but I would like to know what use cases for such a computer would be intended (apart from the obvious - P2 standalone dvelopment) or controlled/scriptable sensor hub or sensor data processor ?
yes it can.
The chip ROM is a serial one in Verilog, so it just loads itself in the upper 16k of RAM at reset. If you do not need the ROM you can simply overwrite or even patch it.
One nice feature chip added is that you can write protect the upper 16k and write access is just possible when in a debug interrupt. It then magically appears at the top 16k of 1024k not 512k.
@Cluso99 wrote the Monitor so that it executes in place in the ROM/RAM, sadly @"Peter Jakacki" did not, just unpacking and starting TAQOZ in the lower 128k(?) of HUB and clobbering it.
But with a bit of trickery one should be able to patch the new BIOS into the ROM area, either using the existing monitor (witch can be called from user programs currently if not write protected), or just replacing the whole Area with something completely different.
But that would lead to completely free HUB ram (except those 16k) and no COG needed to run a OS.
@Cluso99's Monitor has currently simple SD access, can dump memory areas, load files to a HUB location and start COGs. Simple SD means you can just read, not write. But this can be added.
Each program running in that scenario would need to add a Debug interrupt to its COG to access the BIOS routines by using some predefined registers for parameter and then do a BRK #0 to jump into the BIOS, do its stuff and return to the interrupted COG.
sadly i am running 96 hour weeks and have no time to do that, but there is a silver lining on the horizon, I will have January off...
yes. That is my fear too. Getting 60 in January and will renew the contract as every year. This one was to much. Thus the reason to train my successors and hopefully slide slowly into retirement.
But I need to get some code out of this forum and fail miserable. Maybe @Publison can help when not to busy.
ONE: some link to @mpark' spinx for P1 source.
TWO: current REV Rom listing to get the source of @Cluso99's Monitor.
THREE: current source of Chips debugger to maybe steal some of the multi-cog serial stuff.
Some time. Coming soon...
Any links welcome, want to start playing with the concept,
If you're using FlexProp, the default serial code (like BASIC print or C printf) handles multiple COGs already, so you don't have to do anything special.
@ersmith said:
We've had standalone P2 development systems (TAQOZ, MicroPython come to mind). In practice nobody used them, at least as standalone systems -- it just isn't that compelling a use case Possibly a standalone Spin2 compiler might get some traction, since at least it would be able to use the existing libraries of objects.
Perhaps you hit the nail very well here, when you named libraries. Perhaps a self hosted system is simply then attractive, if it helpes to achieve projects more easy and faster.
A while ago I did a project with Esp32 and Micropython. It turned out, that I only needed the builtin compiled libraries. It was really very fast to complete this project! I then tried a different project with Raspi pico and Micropython and for this project I had to use a lot of code written in Micropython. It was so slow then, that it was no fun to use and I gave up after spending a lot of time trying to optimise.
we had a standalone P2 computer that is self hosted and dependent on no forein OS or libraries but we create, maintain and share libraries for that system instead ?
Would that help to achieve projects easier and faster ?
If you're using FlexProp, the default serial code (like BASIC print or C printf) handles multiple COGs already, so you don't have to do anything special.
thanks, @ersmith.
my question would be if I can compile anything else as Assembler with Flex just using the top 16k area and leave the rest of HUB untouched.
Comments
Thanks, I’ll try that immediately.
Hi,
After some of such hours I got the "big brother compiler" at least working in MinGW. I had to throw out
//#include <net.h> and everything that needs it.
The compiled code of c.c is 63kB. The separate virtual machine eu.exe has a length of 58kB. So it seems to be possible to run these with P2. :-)
Christof
Good work. I gave up on MinGW but I got it to at least compile itself under Linux before I ran out of spare time. Is there some trick to getting it working under MinGW? All I get is link errors.
I'll have another go another day.
Ross.
As quick and dirty hack just to get an idea of size, I commented out the dozen or so lines that are not ANSI C compliant, and I get c.c to compile to a code size of about 50kb (COMPACT mode) or 80kb (NATIVE mode) with Catalina. The code that needs to be converted to ANSI C would not add much, so yes I think it could run on a P2.
However, this version is 2500 lines - 5 times larger than the baby version - so while it could probably compile useful C programs, it might not be able to compile itself on the Propeller.
Ross.
Hi Ross,
I reinstalled MinGW with 32bit following this: https://ics.uci.edu/~pattis/common/handouts/mingweclipse/mingw.html
With this I can compile c.c and eu.c.
I was able to integrate the virtual machine eu.c into the shell example of FlexProp.
This was wrong: "There seems to be something wrong with the access of global variables. The compiler compiles address 0 for the first variable. And eu.c puts this at the absoute address 0! It should be an offset to a data segment, which comes after the bytecode, as far as I understand. I don't understand, why this gives no address violation with MingGW. I then switched over to a fork: https://github.com/ghaerr/swieros Here this problem is addressed and the access is different with a offset but I still don't think it is correct. And now areas, which are allocated with malloc will be adressed wrongly, I think?"
Some simple programs, precompiled with MinGW can be executed, but not the compiler at the moment.
Edit: I seem to have something gotten wrong about the adresses.
Edit2:
Had contact with Robert. The asm output print is done before addresses are known, as code length is unknown. They are then corrected just before the bytecode file is written as pc-relative addresses. So code AND data is relocatible. Switched back to Roberts Github.
Yes, and several of us asked for that feature for this purpose. Chip then extended it for additional use with the excellent debug system.
Eventually, I plan on returning to this topic of a stand alone P2 dev system. For my personal one, I'm going to put a P1 and or P2 on two cards that will go into an Apple ][ computer system. For me personally again, that'll be fun, and it's got a nice keyboard and all of that stuff.
Having a shell, and the basics of a Dos in the 16k ROM area would be fantastic!
I think having more than one SD card set up would be good too. Basically one is the system SD card, and the other one is for general purpose data storage output all of that stuff. But those are all things that come later after the minimum requirements.
And I agree with serial being that minimum Communications requirement.
If it were me I would do the old school ps/2 keyboard and mouse, just because it's super lean and efficient.
(Hey everyone! I am still building a business involving laser metal printing and read the happenings here regularly, but have very small amounts of Prop Time (TM lol), most of which is P1 product related. We have a polymer material management cabinet product that uses the P1.)
Perhaps another discussion about what "stand alone", and "self hosted" means to or for everyone, and what planned use cases look like would be valuable?
I will start another thread, drop a link, and put mine up to start.
yes it can.
The chip ROM is a serial one in Verilog, so it just loads itself in the upper 16k of RAM at reset. If you do not need the ROM you can simply overwrite or even patch it.
One nice feature chip added is that you can write protect the upper 16k and write access is just possible when in a debug interrupt. It then magically appears at the top 16k of 1024k not 512k.
@Cluso99 wrote the Monitor so that it executes in place in the ROM/RAM, sadly @"Peter Jakacki" did not, just unpacking and starting TAQOZ in the lower 128k(?) of HUB and clobbering it.
But with a bit of trickery one should be able to patch the new BIOS into the ROM area, either using the existing monitor (witch can be called from user programs currently if not write protected), or just replacing the whole Area with something completely different.
But that would lead to completely free HUB ram (except those 16k) and no COG needed to run a OS.
@Cluso99's Monitor has currently simple SD access, can dump memory areas, load files to a HUB location and start COGs. Simple SD means you can just read, not write. But this can be added.
Each program running in that scenario would need to add a Debug interrupt to its COG to access the BIOS routines by using some predefined registers for parameter and then do a BRK #0 to jump into the BIOS, do its stuff and return to the interrupted COG.
sadly i am running 96 hour weeks and have no time to do that, but there is a silver lining on the horizon, I will have January off...
Mike
Ouch! How long have you been doing that many hours? That can't be good for the health long term.
since February, training some guys in Germany so it is also night shift here in California. So I barely see sunlight.
Mike
That sounds more insane splitting yourself like that. Shouldn't you be concentrating on delivering the training only?
The two rules of business:
Rule one: never divulge all information.
Mike
still searching for @mparks Spinx or Sphinx or whatever it was called, just finding David's Stuff not @mpark's.
Mike
What the frig is sensitive? Just sounds like someone has you going to an early grave.
yes. That is my fear too. Getting 60 in January and will renew the contract as every year. This one was to much. Thus the reason to train my successors and hopefully slide slowly into retirement.
But I need to get some code out of this forum and fail miserable. Maybe @Publison can help when not to busy.
ONE: some link to @mpark' spinx for P1 source.
TWO: current REV Rom listing to get the source of @Cluso99's Monitor.
THREE: current source of Chips debugger to maybe steal some of the multi-cog serial stuff.
Some time. Coming soon...
Any links welcome, want to start playing with the concept,
Mike
Not sure where you'll find mpark's forum posts, but here's what I had as far as sources/code goes...
dgately
cool, thank you
Chip's debugger is checked in to https://github.com/parallaxinc/P2_PNut_Public/ along with the other PNut sources.
If you're using FlexProp, the default serial code (like BASIC print or C printf) handles multiple COGs already, so you don't have to do anything special.
Perhaps you hit the nail very well here, when you named libraries. Perhaps a self hosted system is simply then attractive, if it helpes to achieve projects more easy and faster.
A while ago I did a project with Esp32 and Micropython. It turned out, that I only needed the builtin compiled libraries. It was really very fast to complete this project! I then tried a different project with Raspi pico and Micropython and for this project I had to use a lot of code written in Micropython. It was so slow then, that it was no fun to use and I gave up after spending a lot of time trying to optimise.
What if...
we had a standalone P2 computer that is self hosted and dependent on no forein OS or libraries but we create, maintain and share libraries for that system instead ?
Would that help to achieve projects easier and faster ?
thanks, @ersmith.
my question would be if I can compile anything else as Assembler with Flex just using the top 16k area and leave the rest of HUB untouched.
Mike
Yes, you can. There is a parameter for a compiler. Look at NeoYume or MegaYume for the example of how to use it.