Chris Micro: "Since a certain time I have a dream that I can migrate all my software to any new microcontroller plattform"
You are not alone in that dream. That's why C was invented. That's why GCC exists. That's why I'm busy on this crazy project to get GCC for the Propeller.
Chris Micro: "The structure of ZOG seems much easier to implement than the propeller core. So this seems to be the architecture I have to use for my project."
As we are talking about portable C code here we should not really care about the location if the I/O ports. Everything should go through inb(port) and outb(port, data) or some higher level functions.
The ZPU architecture does not define any peripheral port addresses although the instruction set does dictate that I/O ports are in memory space notin a dedicated I/O space like on an Intel x86.
As it happens there is a sort of standard or two among ZPU implementations about the location of peripheral ports. For example in the instructions for compiling code for Zog I use the option "-phi" for GCC. This is one of about three different ZPU platforms that the GCC supports out of the box. The "phi" platform puts IO ports in the "negative" address space. So for example UART input is at address 0x80000024.
Thing is that your code, data and memory heap are growing up from zero in memory. The ZPU stack is growing down from 0xFFFFFFFF. So putting the I/O ports at 0x8000xxxx keeps them well out of the way in the middle.
Anyway these ports are easily moved in any particular implementation of the ZPU and the C run time code is easily changed to accommodate it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Bill: "there should be a way to tell gcc and the linker to have separate cseg/dseg/sseg"
It's all done with linker scripts. I'm sure it must be possible for ZOG as that is how it is done for GCC for the AVRs.
Problem is GCC has the most complicated incomprehensible linker scripts I have ever seen. I have yet to even find the ZPU linker scripts yet!
Bill: "....crawl on it! (note I did not say "run" on purpose)"
Now you are ragging on Zog. He won't be happy.
You are of course welcome to tweak Zog. I'd like to have a go at optimizing it myself first though. As it happens Zog was tested and got running during the worst bout of flue I have had for ten years. With that fever I was not able to start thinking about anything slightly complicated.
I have a handle on the getchar/putchar. Pretty straight forward. I even have dhrystone compiled for Zog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Cluso: "What about GLMM (gigantically large memory model)"
Great I see you are thinking about that 64bit Propeller I mentioned the other day. Let's face it we are soon going to be complaining about the 4Gbyte memory limit[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
>>You are not alone in that dream. That's why C was invented. That's why GCC exists.
>>That's why I'm busy on this crazy project to get GCC for the Propeller.
Oh, really C? is that a new programming language?
Well, let's take this as a joke. I'm a C-Programmer since 15 years and I use the GCC with AVR-Studio for the AVR-series since 5 years.
So, let's ask: what is the difference between programming a AVR in C or running a ZOG emulation on it?
First let us focus on the disadvantages of such a project:
- extreme speed loss due to the emulation
- no direct access to the peripherals
And now, is there any possible gain in using a ZOG?
Yes it is: code compatibility without recompilation! ( I hate to compile source code for some programs I want to install on my linux systems and I want to have the times back when the people simply put a floppy disk into the computer an run the program without installation )
If you create a ZOG emulator with defined interface addresses ( like I mentioned above ) and the binary code runs on every microcontroller which implemented the ZOG.
Now you could ask: what's about java? Behind java there stands the same philosophy: creating a virtual processor so that code can run on every machine.
My answer: The java virtual machine takes to much code to be implemented, the ZOG seems to be a simplier solution.
OK Chris, I see where you are going with the "universal executable binary" idea.
I could continue my last reply and start "You are not alone in that dream. That's why Java was invented...."
But I see you have already rejected that idea for the same reasons I have.
The ZPU architecture is much smaller/simpler hence Zog. It fits in a COG after all. Try that with Java[noparse]:)[/noparse]
As it stands the ZPU has only ports defined for standard in, standard out and a timer. That could indeed be supported on about any implementation.
How we extend that to cover all the interesting things micro-controllers can do is not clear to me. They are all so different. Especially as many things we use micro-controllers for require the performance that Zog does not have.
P.S.
In line with your thinking, in a way, I am creating a Zog in C that will run on the XMOS devices. Those devices have a similar problem with limited memory space and external RAM attachment as the Prop.
P.P.S.
Those of a nervous disposition should not read the previous paragraph.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Humanoido: "Where are the FORTRAN and C++ downloads?".
The ready to run binaries for GCC that are supplied by ZyLin do not support compiling C++ or FORTRAN. It is necessary to download the source release of GCC from their Git repository. Tweak the build script a bit and then rebuild the compilers from the source.
I have done this on Linux. It can be done on Windows with CygWin.
If you are up to tackling this I can make some instructions.
I have only just tested Zog with C so no guarantees for C++ and FORTRAN running yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Humanoido: "Where are the FORTRAN and C++ downloads?".
The ready to run binaries for GCC that are supplied by ZyLin do not support compiling C++ or FORTRAN. It is necessary to download the source release of GCC from their Git repository. Tweak the build script a bit and then rebuild the compilers from the source.
I have done this on Linux. It can be done on Windows with CygWin.
...
IMO MinGW would be ideal, however I'm guessing that would be a bit more difficult, even with MSYS.
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
>In line with your thinking, in a way, I am creating a Zog in C that will run on the XMOS devices
That is what I planed to do with the PropEmulator ( I have a XMOS development kit which I didn't use yet). But the Zog seems to be the better way.
>How we extend that to cover all the interesting things micro-controllers can do is not clear to me. They are all so different.
Forget about "to cover all". It is sufficient to "cover" the most essential.
Probably there is a common basis which the most microcontroller have:
- serial port
- digital I/O
- analog out
- analog in
- system time in usec
when this elements are covered the Zog would be very useful.
I'd kind of forgotten about the PropEmulator. Seems like an excellent thing to run on the XMOS.
Consider that an XMOS core has 8 threads handled in hardware. Those threads are totally deterministic (***) and they have access to shared RAM. An excellent place to run a Prop simulation with 8 COGs. Might want make use of the XMOS timer features to ensure the shared RAM is accessed in "round robin" HUB fashion.
(***) Sadly the XMOS execution of it's threads is NOT totally deterministic. I would like to think that with say 8 threads running the execution speed of a particular thread is in no way affected by what the other threads are doing and that each thread gets an equal share of cycles in "lock-step". XMOS fails here because:
a) Divide instructions take more clocks. If a thread does a divide the other threads stutter.
b) If the other 7 threads in our example terminate. Then the remaining thread is suddenly running at full core speed.
Bottom line is that if you want timing determinism on XMOS you cannot rely on instruction cycle counting like on the Prop you have to make use of the XMOS timers an such.
Oh wow, way off topic....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
If my special secret sauce plan works, on hits it will be on average 8 cycles per instruction slower regular LMM, ie 26 cycles per single long instruction vs. 18.
Misses will involve a delay while a 256 byte page is loaded, which depends on what it is loaded from (SPI RAM, I2C eeprom, SD etc)
My best WAG is that VLMM will have over 98% hits, and run (overall) at >1/2 speed of LMM with a 16KB working set. Your mileage, and WAGs, may vary. It will be possible to measure number of hits and misses empirically.
Note: VLMM is a paper design at the moment, but I will start on it after VMCOG is running.
jazzed said...
Bill, how fast is your VLMM kernel on hits and misses?
Later I may do a 4GB virtual -> 2Mb physical VLMM, using a 4GB SDHC card and 2MB working set on Morpheus. I'd reserve 512KB for the frame buffer, and use all the memory on a Mem+ for the working set.
I can do it, it is just a matter of can I afford to spend the time on it?
It may be worth doing for something like Zog instead of regular VLMM.
Cluso99 said...
Bill: What about GLMM (gigantically large memory model). I thing that's the pc model LOL
I was hoping you'd do the first run at optimization, with me giving sage advice (ie ribbing) from the sidelines.
I am overloaded with projects right now anyway!
I was not ragging on Zog. I was actually ragging on GCC. See various threads about how much faster LCC and other compilers compile.
With all optimizations, I think Zog can hit 1MIPS - 32 bit MIPS. That was the goal for the 3M project that led to the Xerox Star...
Sorry to hear about the flu!
Excellent re/ Dhrystone, will be a great way of seeing the effect of optimization (and different memory strategies). Later, look at the old Byte benchmark suite. It could even be used to compare Zog/ZiCog/MotoCog/Catalina/ICC etc...
Now that you have a start on stdin/stdout, it might be worthwhile to think about stderr and ioctl()
ioctl could be used as a generic escape mechanism for interfacing to other drivers and hardware...
heater said...
Bill: "there should be a way to tell gcc and the linker to have separate cseg/dseg/sseg"
It's all done with linker scripts. I'm sure it must be possible for ZOG as that is how it is done for GCC for the AVRs.
Problem is GCC has the most complicated incomprehensible linker scripts I have ever seen. I have yet to even find the ZPU linker scripts yet!
Bill: "....crawl on it! (note I did not say "run" on purpose)"
Now you are ragging on Zog. He won't be happy.
You are of course welcome to tweak Zog. I'd like to have a go at optimizing it myself first though. As it happens Zog was tested and got running during the worst bout of flue I have had for ten years. With that fever I was not able to start thinking about anything slightly complicated.
I have a handle on the getchar/putchar. Pretty straight forward. I even have dhrystone compiled for Zog.
Optimizations or other progress on Zog will take a back seat again for a week or so as I get back to real work.
GCC may compile more slowly than others but who cares? For the small Prop sized programs we are dealing with they all compile in an instant on a modern PC. I must admit rebuilding my C++/Qt projects is becoming a drag though and they are not so huge.
What we need is execution speed, on the Prop, in the compiled result. Zog may hit 1MIP if we try hard enough but we still have to face the fact that it is a stack based machine which looks like it needs more instructions to the same work as other architectures. Plus the lack of registers leading to more memory accesses. ZIPS == MIPS ? true : false;
I have the whole BYTE Unix Benchmark suite here since a couple of days ago. Only Dhrystone compiled so far.
Not sure about the stderr and ioclt stuff. The C run time IO supplied with ZPU GCC does end up in read_byte/write_byte functions for the UART console I/O. It has some file open/close etc stuff which are basically stubs that don't do anything. Needs a little looking into.
Cluso: I have yet to look at SphinxOS but that sounds like an excellent idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
re Sphinx: You just treat it like an FDX/TV/KBD object...
stdo.out(ch)
stdo.hex(ch,8)
stdo.dec(ch)
stdo.str(string("xyz",13))
and
ch:=stdi.rx
etc. The drivers are resident, so you just use a simple stub driver that knows where the buffer is in hub. It's really simple.
I have attached the StdIn & StdOut calling objects for you to look at (not many lines)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
V0.4 just adds a primitive UART output such that the C run time library function outbyte() works.
The C test program has been changed so that Zog prints a hello message to the console.
Single stepping is not switched on as delivered. Look for #define SINGLE_STEP.
I added a Makefile to build the test program binary load image from test.c
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I know what you mean... VMCOG has to slow down for approx. two weeks for the same reason.
I think at 1 MIP it will be usable for a LOT of applications, and when more speed is needed, pasm in a cog should do [noparse]:)[/noparse]
Let's not forget that there will be an instant 8x increase in speed on the Prop2 (whenever it arrives), and with the new indexed hub addressing modes and cog indexing the ZOG interpreter can probably get another 1.5x to 2x speedup ... this means we will be looking at ZOG running at somewhere between 8 to 16 MIPS!
Even if it will be a bit slow, it will be setting up an infrastructure for running much faster later.
More of the Unix benchmarks will run as the infrastructure gets built up (stdio, file i/o etc).
One interesting thought... gcc will be able to compile the C fat libraries, so potentially file system handling can be done in ZOG code, with only the lowest level readsector/writesector being in pasm.
Why would this be good?
Because all the FS code would be in the VM, automatically swapped in/out as needed!
heater said...
Optimizations or other progress on Zog will take a back seat again for a week or so as I get back to real work.
GCC may compile more slowly than others but who cares? For the small Prop sized programs we are dealing with they all compile in an instant on a modern PC. I must admit rebuilding my C++/Qt projects is becoming a drag though and they are not so huge.
What we need is execution speed, on the Prop, in the compiled result. Zog may hit 1MIP if we try hard enough but we still have to face the fact that it is a stack based machine which looks like it needs more instructions to the same work as other architectures. Plus the lack of registers leading to more memory accesses. ZIPS == MIPS ? true : false;
I have the whole BYTE Unix Benchmark suite here since a couple of days ago. Only Dhrystone compiled so far.
Not sure about the stderr and ioclt stuff. The C run time IO supplied with ZPU GCC does end up in read_byte/write_byte functions for the UART console I/O. It has some file open/close etc stuff which are basically stubs that don't do anything. Needs a little looking into.
Cluso: I have yet to look at SphinxOS but that sounds like an excellent idea.
V0.4 just adds a primitive UART output such that the C run time library function outbyte() works.
The C test program has been changed so that Zog prints a hello message to the console.
Single stepping is not switched on as delivered. Look for #define SINGLE_STEP.
I added a Makefile to build the test program binary load image from test.c
Bill, you just reminded me of the "magic 3Ms" (1 MIP, 1MB RAM, 1 MegaPixel monochrome display) as was talked about for workstations years ago. www.cs.bris.ac.uk/history/
We have a little work to do!
I'm not hanging on for the Prop II. All that extra speed and memory spoils the challenge[noparse]:)[/noparse]
Well, Morpheus can have much more than 1MB, and I could easily make a 1.2Mpixel mono driver (1280x1024) for it... and with two Props, it has far more than 1MIP [noparse]:)[/noparse]
I know what you mean about waiting for Prop2 :-(
Personally, I have a bunch of Prop1 designs in the pipeline including one specifically designed for VMCOG emulations.
VERY cool re/ FAT code compiling...
heater said...
Bill, you just reminded me of the "magic 3Ms" (1 MIP, 1MB RAM, 1 MegaPixel monochrome display) as was talked about for workstations years ago. www.cs.bris.ac.uk/history/
We have a little work to do!
I'm not hanging on for the Prop II. All that extra speed and memory spoils the challenge[noparse]:)[/noparse]
Just playing around here but I can't get printf to work with Zog.
But there is a "print" function in the supplied libs that goes straight out to the UART port so that works.
Moving on from there, "sprintf" works into a string which can then be output with "print".
BUT trying to use sprintf with a %d immediately blows the binary up to something that will not fit in HUB.
Conclusion:
1) printf is probably looking for a stdout handle or such which is not set up.
2) Time to move into external memory with VMCOG. (On my TriBlade)
Just now playing with FIBO. Any idea where the Catalina FIBO results are posted.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I see the UART works with an address which is a good start. Any chance you can provide a cognew/cogstop interface with a similar method? There are several drivers in the OBEX that could benefit. I have the VGA driver compiling (GNU doesn't like 0b.... notation) but can't test without an interface.
Well I could create a cognew/cogstop interface in a similar way but what am I starting and stopping?
I guess I don't get what you are aiming at, are these C objects you are talking about?
Actually I'm wondering about what to do about the whole I/O business. The ZPU uses memory mapped I/O which means you have to check every memory access to see if it into I/O space. This is a serious time waster. Just now I only check accesses when reading/writing LONGS. Not during any PUSHEs or POPs. But still it pains me to have to do that.
Ideally I'd like to add I/O instructions to the instruction set. The ZPU developers don't like that idea for there baby but we might have to go it alone a little bit here in the name of efficiency.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Well I could create a cognew/cogstop interface in a similar way but what am I starting and stopping?
I guess I don't get what you are aiming at, are these C objects you are talking about?
Yes, they are C "objects" ... have a look. All we need is a cognew/cogstop interface. The memory access is managable from C.
Presumably if those objects do anything useful on the Prop they already have interfaces to Prop features, like pins, timers, video, cognew, cogstop, some means of passing data to other COGs through HUB RAM etc.
Zog has none of that at the moment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
sprintf probably pulls in libc, thus the bloated binary.
I agree with jazzed re/ cognew and cogstop... and I agree with you about I/O instructions, as memory mapped I/O in this context causes a performance hit.
How about adding just one special instruction: SYSTEM
heater said...
Point me at an example for consideration.
Presumably if those objects do anything useful on the Prop they already have interfaces to Prop features, like pins, timers, video, cognew, cogstop, some means of passing data to other COGs through HUB RAM etc.
Zog has none of that at the moment.
In the "ICC model" device drivers are written by users rather than have the kernel add the devices. There are gives/takes between that and Ross' Catalina model. In some ways I like the Catalina model best since some things can be done with smaller spin code. Somewhere a happy median can be achieved.
I'll post an example for you in the morning; it will be essentially the C VGA example form OBEX with 0b... replaced with 0x... numbers, and have stubs for things like wordfill, wordmove, and cognew/cogstop. The code is mostly generic and works with ICC although it is a little "fat" for one library file. The propeller.h file used in ICC provides wait***, locks, and other interfaces via propeller asm (pins are mapped to the cog addresses in the LMM kernel).
I like Bill's system HAL model since that would be more friendly to simulations, etc.... Of course the smallest possible impact on ZOG's kernel is very important. I prefer a performance method to do system stuff like a special opcode or something from your imagination. The UART device model you added is I guess in retrospect inefficient, but i thought you were at least a little happy with it since you used it.
You remember the soft interrupt idea from BIOS and DOS (or something older ... I'm too young at 50 and too focused in other areas to know better). I don't know how that's done, but an opcode would provide a less intrusive method on code performance than memory address decoding.
Whatever you decide is fine by me of course. I was just thinking about how easy it has been for others to add something new to ICC in that model. Code quality/control may be harder, but at least one person doesn't have to do everything.
Comments
You are not alone in that dream. That's why C was invented. That's why GCC exists. That's why I'm busy on this crazy project to get GCC for the Propeller.
Chris Micro: "The structure of ZOG seems much easier to implement than the propeller core. So this seems to be the architecture I have to use for my project."
For sure the ZPU is about as simple as it gets. But wait, the GNU C Compiler has already been targeted at the 8 bit AVRs
electrons.psychogenic.com/modules/arms/art/3/AVRGCCProgrammingGuide.php#installgcc
I have used it. Works fine. No need for a ZPU virtual machine on Atmeg8.
As we are talking about portable C code here we should not really care about the location if the I/O ports. Everything should go through inb(port) and outb(port, data) or some higher level functions.
The ZPU architecture does not define any peripheral port addresses although the instruction set does dictate that I/O ports are in memory space notin a dedicated I/O space like on an Intel x86.
As it happens there is a sort of standard or two among ZPU implementations about the location of peripheral ports. For example in the instructions for compiling code for Zog I use the option "-phi" for GCC. This is one of about three different ZPU platforms that the GCC supports out of the box. The "phi" platform puts IO ports in the "negative" address space. So for example UART input is at address 0x80000024.
Thing is that your code, data and memory heap are growing up from zero in memory. The ZPU stack is growing down from 0xFFFFFFFF. So putting the I/O ports at 0x8000xxxx keeps them well out of the way in the middle.
Anyway these ports are easily moved in any particular implementation of the ZPU and the C run time code is easily changed to accommodate it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
It's all done with linker scripts. I'm sure it must be possible for ZOG as that is how it is done for GCC for the AVRs.
Problem is GCC has the most complicated incomprehensible linker scripts I have ever seen. I have yet to even find the ZPU linker scripts yet!
Bill: "....crawl on it! (note I did not say "run" on purpose)"
Now you are ragging on Zog. He won't be happy.
You are of course welcome to tweak Zog. I'd like to have a go at optimizing it myself first though. As it happens Zog was tested and got running during the worst bout of flue I have had for ten years. With that fever I was not able to start thinking about anything slightly complicated.
I have a handle on the getchar/putchar. Pretty straight forward. I even have dhrystone compiled for Zog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Great I see you are thinking about that 64bit Propeller I mentioned the other day. Let's face it we are soon going to be complaining about the 4Gbyte memory limit[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
>>That's why I'm busy on this crazy project to get GCC for the Propeller.
Oh, really C? is that a new programming language?
Well, let's take this as a joke. I'm a C-Programmer since 15 years and I use the GCC with AVR-Studio for the AVR-series since 5 years.
So, let's ask: what is the difference between programming a AVR in C or running a ZOG emulation on it?
First let us focus on the disadvantages of such a project:
- extreme speed loss due to the emulation
- no direct access to the peripherals
And now, is there any possible gain in using a ZOG?
Yes it is: code compatibility without recompilation! ( I hate to compile source code for some programs I want to install on my linux systems and I want to have the times back when the people simply put a floppy disk into the computer an run the program without installation )
If you create a ZOG emulator with defined interface addresses ( like I mentioned above ) and the binary code runs on every microcontroller which implemented the ZOG.
Now you could ask: what's about java? Behind java there stands the same philosophy: creating a virtual processor so that code can run on every machine.
My answer: The java virtual machine takes to much code to be implemented, the ZOG seems to be a simplier solution.
I could continue my last reply and start "You are not alone in that dream. That's why Java was invented...."
But I see you have already rejected that idea for the same reasons I have.
The ZPU architecture is much smaller/simpler hence Zog. It fits in a COG after all. Try that with Java[noparse]:)[/noparse]
As it stands the ZPU has only ports defined for standard in, standard out and a timer. That could indeed be supported on about any implementation.
How we extend that to cover all the interesting things micro-controllers can do is not clear to me. They are all so different. Especially as many things we use micro-controllers for require the performance that Zog does not have.
P.S.
In line with your thinking, in a way, I am creating a Zog in C that will run on the XMOS devices. Those devices have a similar problem with limited memory space and external RAM attachment as the Prop.
P.P.S.
Those of a nervous disposition should not read the previous paragraph.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The ready to run binaries for GCC that are supplied by ZyLin do not support compiling C++ or FORTRAN. It is necessary to download the source release of GCC from their Git repository. Tweak the build script a bit and then rebuild the compilers from the source.
I have done this on Linux. It can be done on Windows with CygWin.
If you are up to tackling this I can make some instructions.
I have only just tested Zog with C so no guarantees for C++ and FORTRAN running yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
That is what I planed to do with the PropEmulator ( I have a XMOS development kit which I didn't use yet). But the Zog seems to be the better way.
>How we extend that to cover all the interesting things micro-controllers can do is not clear to me. They are all so different.
Forget about "to cover all". It is sufficient to "cover" the most essential.
Probably there is a common basis which the most microcontroller have:
- serial port
- digital I/O
- analog out
- analog in
- system time in usec
when this elements are covered the Zog would be very useful.
Consider that an XMOS core has 8 threads handled in hardware. Those threads are totally deterministic (***) and they have access to shared RAM. An excellent place to run a Prop simulation with 8 COGs. Might want make use of the XMOS timer features to ensure the shared RAM is accessed in "round robin" HUB fashion.
(***) Sadly the XMOS execution of it's threads is NOT totally deterministic. I would like to think that with say 8 threads running the execution speed of a particular thread is in no way affected by what the other threads are doing and that each thread gets an equal share of cycles in "lock-step". XMOS fails here because:
a) Divide instructions take more clocks. If a thread does a divide the other threads stutter.
b) If the other 7 threads in our example terminate. Then the remaining thread is suddenly running at full core speed.
Bottom line is that if you want timing determinism on XMOS you cannot rely on instruction cycle counting like on the Prop you have to make use of the XMOS timers an such.
Oh wow, way off topic....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Misses will involve a delay while a 256 byte page is loaded, which depends on what it is loaded from (SPI RAM, I2C eeprom, SD etc)
My best WAG is that VLMM will have over 98% hits, and run (overall) at >1/2 speed of LMM with a 16KB working set. Your mileage, and WAGs, may vary. It will be possible to measure number of hits and misses empirically.
Note: VLMM is a paper design at the moment, but I will start on it after VMCOG is running.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
Later I may do a 4GB virtual -> 2Mb physical VLMM, using a 4GB SDHC card and 2MB working set on Morpheus. I'd reserve 512KB for the frame buffer, and use all the memory on a Mem+ for the working set.
I can do it, it is just a matter of can I afford to spend the time on it?
It may be worth doing for something like Zog instead of regular VLMM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
I am overloaded with projects right now anyway!
I was not ragging on Zog. I was actually ragging on GCC. See various threads about how much faster LCC and other compilers compile.
With all optimizations, I think Zog can hit 1MIPS - 32 bit MIPS. That was the goal for the 3M project that led to the Xerox Star...
Sorry to hear about the flu!
Excellent re/ Dhrystone, will be a great way of seeing the effect of optimization (and different memory strategies). Later, look at the old Byte benchmark suite. It could even be used to compare Zog/ZiCog/MotoCog/Catalina/ICC etc...
Now that you have a start on stdin/stdout, it might be worthwhile to think about stderr and ioctl()
ioctl could be used as a generic escape mechanism for interfacing to other drivers and hardware...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
GCC may compile more slowly than others but who cares? For the small Prop sized programs we are dealing with they all compile in an instant on a modern PC. I must admit rebuilding my C++/Qt projects is becoming a drag though and they are not so huge.
What we need is execution speed, on the Prop, in the compiled result. Zog may hit 1MIP if we try hard enough but we still have to face the fact that it is a stack based machine which looks like it needs more instructions to the same work as other architectures. Plus the lack of registers leading to more memory accesses. ZIPS == MIPS ? true : false;
I have the whole BYTE Unix Benchmark suite here since a couple of days ago. Only Dhrystone compiled so far.
Not sure about the stderr and ioclt stuff. The C run time IO supplied with ZPU GCC does end up in read_byte/write_byte functions for the UART console I/O. It has some file open/close etc stuff which are basically stubs that don't do anything. Needs a little looking into.
Cluso: I have yet to look at SphinxOS but that sounds like an excellent idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
stdo.out(ch)
stdo.hex(ch,8)
stdo.dec(ch)
stdo.str(string("xyz",13))
and
ch:=stdi.rx
etc. The drivers are resident, so you just use a simple stub driver that knows where the buffer is in hub. It's really simple.
I have attached the StdIn & StdOut calling objects for you to look at (not many lines)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
V0.4 just adds a primitive UART output such that the C run time library function outbyte() works.
The C test program has been changed so that Zog prints a hello message to the console.
Single stepping is not switched on as delivered. Look for #define SINGLE_STEP.
I added a Makefile to build the test program binary load image from test.c
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I think at 1 MIP it will be usable for a LOT of applications, and when more speed is needed, pasm in a cog should do [noparse]:)[/noparse]
Let's not forget that there will be an instant 8x increase in speed on the Prop2 (whenever it arrives), and with the new indexed hub addressing modes and cog indexing the ZOG interpreter can probably get another 1.5x to 2x speedup ... this means we will be looking at ZOG running at somewhere between 8 to 16 MIPS!
Even if it will be a bit slow, it will be setting up an infrastructure for running much faster later.
More of the Unix benchmarks will run as the infrastructure gets built up (stdio, file i/o etc).
One interesting thought... gcc will be able to compile the C fat libraries, so potentially file system handling can be done in ZOG code, with only the lowest level readsector/writesector being in pasm.
Why would this be good?
Because all the FS code would be in the VM, automatically swapped in/out as needed!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
We have a little work to do!
I'm not hanging on for the Prop II. All that extra speed and memory spoils the challenge[noparse]:)[/noparse]
I've already tried compiling this FAT code elm-chan.org/fsw/ff/00index_e.html no problem.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Well, Morpheus can have much more than 1MB, and I could easily make a 1.2Mpixel mono driver (1280x1024) for it... and with two Props, it has far more than 1MIP [noparse]:)[/noparse]
I know what you mean about waiting for Prop2 :-(
Personally, I have a bunch of Prop1 designs in the pipeline
VERY cool re/ FAT code compiling...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
But there is a "print" function in the supplied libs that goes straight out to the UART port so that works.
Moving on from there, "sprintf" works into a string which can then be output with "print".
BUT trying to use sprintf with a %d immediately blows the binary up to something that will not fit in HUB.
Conclusion:
1) printf is probably looking for a stdout handle or such which is not set up.
2) Time to move into external memory with VMCOG. (On my TriBlade)
Just now playing with FIBO. Any idea where the Catalina FIBO results are posted.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I guess I don't get what you are aiming at, are these C objects you are talking about?
Actually I'm wondering about what to do about the whole I/O business. The ZPU uses memory mapped I/O which means you have to check every memory access to see if it into I/O space. This is a serious time waster. Just now I only check accesses when reading/writing LONGS. Not during any PUSHEs or POPs. But still it pains me to have to do that.
Ideally I'd like to add I/O instructions to the instruction set. The ZPU developers don't like that idea for there baby but we might have to go it alone a little bit here in the name of efficiency.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Presumably if those objects do anything useful on the Prop they already have interfaces to Prop features, like pins, timers, video, cognew, cogstop, some means of passing data to other COGs through HUB RAM etc.
Zog has none of that at the moment.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I agree with jazzed re/ cognew and cogstop... and I agree with you about I/O instructions, as memory mapped I/O in this context causes a performance hit.
How about adding just one special instruction: SYSTEM
C prototype:
int system(int vector, arg1, .. argN)
Example:
and so on... giving a complete escape mechanism for any type of messaging, driver loading etc needed.
Note the (rd|wr)(byte|word|long) for giving raw hub access!
Also note this gives easy access to Spin objects via hub transfers, adding cnt, locks etc becomes easy.
Heck, it allows adding extra operations written in spin!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
I'll post an example for you in the morning; it will be essentially the C VGA example form OBEX with 0b... replaced with 0x... numbers, and have stubs for things like wordfill, wordmove, and cognew/cogstop. The code is mostly generic and works with ICC although it is a little "fat" for one library file. The propeller.h file used in ICC provides wait***, locks, and other interfaces via propeller asm (pins are mapped to the cog addresses in the LMM kernel).
I like Bill's system HAL model since that would be more friendly to simulations, etc.... Of course the smallest possible impact on ZOG's kernel is very important. I prefer a performance method to do system stuff like a special opcode or something from your imagination. The UART device model you added is I guess in retrospect inefficient, but i thought you were at least a little happy with it since you used it.
You remember the soft interrupt idea from BIOS and DOS (or something older ... I'm too young at 50 and too focused in other areas to know better). I don't know how that's done, but an opcode would provide a less intrusive method on code performance than memory address decoding.
Whatever you decide is fine by me of course. I was just thinking about how easy it has been for others to add something new to ICC in that model. Code quality/control may be harder, but at least one person doesn't have to do everything.