Did you build GCC under Linux or Cygwin? I understand wanting to remain compatible with other ZPU implementations. I'll just write the byte swapping code for my file I/O for now. Who did the ZPU implementation for "the cpu that must not be named"?
I have only built zpu-gcc under Debian stable (lenny) and testing (sid).
I tried to build it under Ubuntu but the build failed and I could not figure out why. I think it was Jazzed who had the same problem. It might be time to try that again as both zpu-gcc and Ubuntu have moved on a bit.
However the zpu-gcc built under Debian did work OK when moved to Ubuntu.
Actually the ZPU for the "chip that will remain nameless" does not exist yet. Basically I made a ZPU interpreter in C. It is attached to the fisrst post in this thread. It was a prototype for the rather unobvious and optimized way that ZOG is written. Just to be sure I got the logic right. That zpu_in_c runs under Linux and I have managed to compiled it for "...nameless". I still don't have a "...nameless" chip so it has never been tested. Let alone a "...nameless" chip with an external memory attached.
There is no point to ZPU on that chip without external memory as it is programmed in GCC anyway. ZPU is only a way of overcoming the internal memory limitations of that device.
I have a board with the unmentionable chip but no external RAM attached. Also, I haven't done anything with it since I started playing with the Propeller. I'll try building GCC under cygwin sometime soon but I think your idea of maintaining compatiblity with other ZPU implementations is probably good. Is anyone using the FPGA version of the ZPU? I just ordered a "Multiple Classis Computer MCC-216-VGA" that has an FPGA to implement classic computers and game machines. Maybe I'll try bringing up the ZPU on that.
I'll try building GCC under cygwin sometime soon ...
Good luck with Cygwin, I've tried. Building GCC with Ubuntu 10 also fails. I've used Fedora to build GCC for ARM/AVR. Having GAS for Propeller LMM would be a good step for "native" Propeller GCC.
@Heater, Have you considered adding an EEPROM bootloader to debug_zog.spin? I know it's silly if one has access to an SDcard, but I have at least one case where SDcard is not available but would still like to use external memory.
Thanks.
--Steve
BTW, I should be able to ship an SDRAM board set to you next week. The board may not be the final design or it could be for some features. Either way, I don't expect the SDRAM interface to change.
An EEPROM boot loader has crossed my mind occasionally. What do you have in mind for how it should work?
Are we talking just using a 64K EEPROM with the lower 32K basically fixed with something like debug_zog/run_zog + loader in it with ZPU code placed in the upper 32K?
32K does not seem enough for anything much, especially as we are looking at such huge amounts of external RAM to play in.
Looking forward to that SDRAM board. It's just about becoming essential here. The Whetstone benchmark almost wont fit in 64K.
An EEPROM boot loader has crossed my mind occasionally. What do you have in mind for how it should work?
Are we talking just using a 64K EEPROM with the lower 32K basically fixed with something like debug_zog/run_zog + loader in it with ZPU code placed in the upper 32K?
Essentially that's my thinking, except that up to 128KB is available with an at24c1024b. Anything more than 32K is helpful.
One stuffing option on the SDRAM protoboard includes a VGA connector - that disallows using the SDCARD so having another way to load larger programs helps. The main reason for including the VGA on the SDRAM protoboard was for experiments with SDRAM as a video memory; I was told 5MB/s reads should be fast enough to load lines of video - feasibility of this is TBD.
Looking forward to that SDRAM board. It's just about becoming essential here. The Whetstone benchmark almost wont fit in 64K.
I'm planning to send you a board with a TV video DAC, SDcard, and PS2 connectors (atTiny85 blank or with I2C slave mouse).
Sorry for the delay, but I've been banging my head The I2C PS2 keyboard/mouse interface has been a bear to get working. The bear has lost it's grip now.
Thinking out loud here: Another version of the SDRAM board will be produced that offers only SDRAM (same interface as today), SDCARD, and optional TV A/V. The original board would still be available. The new version could be combined with a new "I2C peripheral playground" module which would offer an I2C connected Propeller, some ports like USB and PS2 footprints, SDCARD, possibly an ADC, and prototyping area. The I2C attached slave Propeller could have it's boot program updated by the master Propeller.
I think I asked this before but anyway I'm confusing myself as to how HUB, external RAM and COG memory should be laid out in the ZPU memory map.
Currently ZPU executing code from HUB has no possibility of accessing external RAM except if it loads up VMCOG and uses the access functions.
Code executing from external RAM can see the 32K HUB located at $10000000 in its memory map.
This does not seem good to me. As I don't have a final application for Zog in mind at this time perhaps I cannot decide on a good solution.
Seems to me that code running from HUB should have the possibility to have a VMCOG running and hence be able to transparently use external memory if required. That is to say that "*pointer_to_ext_mem = something;" should work.
Conversely code running from ext RAM should be able to see HUB memory as it does now.
I'm thinking like this:
When running from HUB the address map puts HUB memory at zero, as it does now. It then has external memory, if required, at $10000000.
When running code from external memory the opposite is true. Addresses zero to $10000000 are ext RAM. After that is HUB space.
Ummmm... I've just been trying to debug my open/close syscall code and finally realized why it isn't working. The syscall code in debug_zog.spin doesn't work for anything but USE_HUB_MEMORY mode since it directly accesses the stack using long[framep + 8] style memory accesses. Is that correct or is the stack supposed to be in hub memory even if the code is in VMCOG memory?
Jazzed: If you provide a I2C connection to tie to another prop, why not just use those two pins for a faster protocol....after boot, of course.
Doug
The problem is the EEPROM will ACK certain bit sequences and cause trouble by pulling the pin low. Extra hardware is required to make sure that doesn't happen. Just using I2C is easier.
Sorry, the SYSCALL read and write to the console was created with only support for running from HUB. Then it was forgotten about as normally we use the UART emulation for console I/O.
When running from Ext RAM all code, data and stack is in external memory.
Looks like we need external memory versions of the syscall stuff that access ZPU memory via VMCOG (or the SdramCache).
I'll look at adding a new syscall interface for external memory builds later tonight. I need to add some code to syscall anyway to byte swap the read/write buffers and filename strings.
I'm working on adding general SD file I/O to ZOG and I have a problem with the currently used scheme of byte swapping the entire image before writing it to memory. This works well for 16 and 32 bit values but not so well for byte-oriented data. This can be partially handled by byte swapping again when things like constant strings are output to the terminal. Unfortunately, this isn't really a general solution to the problem. You need to know if the data you are fetching from ZOG memory is long, word, or byte data. This isn't always possible. For instance, when reading a file from the SD card, you can't just swap everything because then the ZOG code will see byte-oriented data out of order.
Is there a version of the ZOG VM that does the byte swapping at runtime instead of expecting it to have already been done before the code was loaded?
Perhaps I'm a bit too tired to appreciate your problem at the moment, these simple endianness issues have managed to totally confuse me at the best of times.
I'm having a bit of trouble with this statement: "You need to know if the data you are fetching from ZOG memory is long, word, or byte data....For instance, when reading a file from the SD card, you can't just swap everything because then the ZOG code will see byte-oriented data out of order."
I don't think you should need to know if the data output to a file comes from a LONG or WORD or any other size item.
The way I see it is I/O follows the Unix tradition of:
1) Everything is a file. Even if it is a serial port etc.
2) All reads and writes are byte oriented.
That is to say that when writing to files it is no different from writing bytes to the terminal. There is no concept of words or longs or any other structure. If the bytes come out in the right order on the terminal then they must come out in the right order on the file. And the same when reading from the console input or reading from a file.
Now that leaves the possibility that the data on the file is written from a system of opposite endianness to the system that reads it without them both agreeing a byte ordering for the on file data. But that is not something to fix in Zog as such.
Perhaps I'm not quite getting the issue here.
I have wondered about asking Bill to make a byte swapping VMCOG in the past. But there seems to be no point as what we have now is compatible with running from HUB memory and does not add any performance overhead.
This will result in 'DCBA' being printed rather than the expected 'ABCD' since the literal string will get byte swapped before being loaded into ZOG memory. Am I missing something here? Is there an additional reordering of bytes that happens internal to ZOG?
This will result in 'DCBA' being printed rather than the expected 'ABCD' since the literal string will get byte swapped before being loaded into ZOG memory. Am I missing something here? Is there an additional reordering of bytes that happens internal to ZOG?
Well, as you probably suspected, my little test program prints "ABCD" not "DCBA" like I expected. I guess my endian issues are more subtle than I had thought. I'll start dumping the sectors I'm getting off of the SD card to make sure I understand what is happening.
I was going to try a test with that code snippet as well today. I was fairly sure it should work as I have done some endianness testing before with the "hello" and "endian" test programs.
I guess my endian issues are more subtle than I had thought.
Don't worry, didn't I say "...simple endianness issues have managed to totally confuse me at the best of times."
Where exactly are you seeing a problem?
Are your reading a file written from Zog or one created on the PC?
Hopefully I can find some time to play along a bit today. Seems I don't have to be in the office this weekend:)
I got file reading working using fsdos.c. I'm just using raw sector I/O on the syscall side and letting fsdos.c do all of the FAT filesystem handling in ZOG itself. This gives me the ability to open multiple files at the same time. I'm having a problem with writing though. The filesystem gets corrupted if I try to create or write to a file. I'll have to track that down next. Also, I need to find a way to put the newlib library code in the flash chip on the C3 because linking with the stdio stuff leaves very little SRAM left out of the 64k of SPI SRAM on the C3. Looks like I'll need to learn something about ld linker scripts.
Once I have time for VMCOG again (one to two weeks from now, after I finish testing the boards I am working on) I was thinking of making a mixed flash/sram version.
Currently I am thinking of addresses 0-4M being reserved for ram, and 4M-8M for flash.
I will have to add "erase sector" (4K) and "load page" (512 byte program) commands to VMCOG, but the read's would be the same, and I'd disable the write commands.
On PropCade this would allow for 128K ram using 4 SPI ram's, and 4M flash using two 2MB flash dip chips.
I got file reading working using fsdos.c. I'm just using raw sector I/O on the syscall side and letting fsdos.c do all of the FAT filesystem handling in ZOG itself. This gives me the ability to open multiple files at the same time. I'm having a problem with writing though. The filesystem gets corrupted if I try to create or write to a file. I'll have to track that down next. Also, I need to find a way to put the newlib library code in the flash chip on the C3 because linking with the stdio stuff leaves very little SRAM left out of the 64k of SPI SRAM on the C3. Looks like I'll need to learn something about ld linker scripts.
Just got file writing working as well. I can now open two files at once! I guess this gives me what I need to try getting my Basic bytecode compiler running on the C3. After that, I'll try moving the stdio library into flash so I can free up SRAM for the main code. I don't want to put all of my code in flash because I don't want to have to constantly reprogram the flash whenever I want to load a new program. The chip is soldered to the board and can only be written so many times.
I wasn't really interested in flashing an entire program. I just wanted a DLL-style library in flash. The main program would still be loaded into the 64k of SRAM. The idea would be to have the entire of newlib in flash. That way it wouldn't take up any of the limited SRAM and still have about the same access time. I guess I should look at the shared library support in GCC.
We are not going to use shared libraries to get code into flash. They would require of a big complicated dynamic linker to link them when the program is loaded/started. Basically it would require an operating system!
Rather what we need to be able to do is:
1) Link all the lib functions into a static library - libwhatever.a
2) When building the program link it with the static library.
3) BUT relocate all the library objects to FLASH memory addresses
I think the trick is that all code is normally in a section called ".text". That section is located by the current linker script. If we can rename the library code section to something else ".libtext" using objdump (or is it objcopy?). Then we can get the linker to locate the ".libtext" section at the flash address.
I have no idea how to do this at the moment:(
I can see a possible little problem already. When building a program only the library objects that are actually used are linked in to the binary.
So two different programs being loaded to RAM may expect the layout of the FLASH content to be totally different depending on what objects they actually use.
I'd like to see split I/D, so all of the text segment (including constants) could go into flash, and only keep the data segment in ram.
A modern flash chip can be programmed 100k+ times (usually >1M) so I think it would be quite an advantage to put .text in it - and save the ram for data.
We are not going to use shared libraries to get code into flash. They would require of a big complicated dynamic linker to link them when the program is loaded/started. Basically it would require an operating system!
Rather what we need to be able to do is:
1) Link all the lib functions into a static library - libwhatever.a
2) When building the program link it with the static library.
3) BUT relocate all the library objects to FLASH memory addresses
I think the trick is that all code is normally in a section called ".text". That section is located by the current linker script. If we can rename the library code section to something else ".libtext" using objdump (or is it objcopy?). Then we can get the linker to locate the ".libtext" section at the flash address.
I have no idea how to do this at the moment:(
I can see a possible little problem already. When building a program only the library objects that are actually used are linked in to the binary.
So two different programs being loaded to RAM may expect the layout of the FLASH content to be totally different depending on what objects they actually use.
A modern flash chip can be programmed 100k+ times (usually >1M) so I think it would be quite an advantage to put .text in it - and save the ram for data.
I just looked up the Atmel AT26DF081A flash chip that Andre' used in the C3. It can be reprogrammed 100k times. That's a lot better than a PIC chip I used once that could only be programmed 10k times. You might be right that just putting all of .text in flash is the best approach. That's easier too! :-)
I just looked up the Atmel AT26DF081A flash chip that Andre' used in the C3. It can be reprogrammed 100k times. That's a lot better than a PIC chip I used once that could only be programmed 10k times. You might be right that just putting all of .text in flash is the best approach. That's easier too! :-)
Comments
I tried to build it under Ubuntu but the build failed and I could not figure out why. I think it was Jazzed who had the same problem. It might be time to try that again as both zpu-gcc and Ubuntu have moved on a bit.
However the zpu-gcc built under Debian did work OK when moved to Ubuntu.
Actually the ZPU for the "chip that will remain nameless" does not exist yet. Basically I made a ZPU interpreter in C. It is attached to the fisrst post in this thread. It was a prototype for the rather unobvious and optimized way that ZOG is written. Just to be sure I got the logic right. That zpu_in_c runs under Linux and I have managed to compiled it for "...nameless". I still don't have a "...nameless" chip so it has never been tested. Let alone a "...nameless" chip with an external memory attached.
There is no point to ZPU on that chip without external memory as it is programmed in GCC anyway. ZPU is only a way of overcoming the internal memory limitations of that device.
Not yet but I'm seriously contemplating following along with
Thanks.
--Steve
BTW, I should be able to ship an SDRAM board set to you next week. The board may not be the final design or it could be for some features. Either way, I don't expect the SDRAM interface to change.
An EEPROM boot loader has crossed my mind occasionally. What do you have in mind for how it should work?
Are we talking just using a 64K EEPROM with the lower 32K basically fixed with something like debug_zog/run_zog + loader in it with ZPU code placed in the upper 32K?
32K does not seem enough for anything much, especially as we are looking at such huge amounts of external RAM to play in.
Looking forward to that SDRAM board. It's just about becoming essential here. The Whetstone benchmark almost wont fit in 64K.
One stuffing option on the SDRAM protoboard includes a VGA connector - that disallows using the SDCARD so having another way to load larger programs helps. The main reason for including the VGA on the SDRAM protoboard was for experiments with SDRAM as a video memory; I was told 5MB/s reads should be fast enough to load lines of video - feasibility of this is TBD.
I'm planning to send you a board with a TV video DAC, SDcard, and PS2 connectors (atTiny85 blank or with I2C slave mouse).
Sorry for the delay, but I've been banging my head
Thinking out loud here: Another version of the SDRAM board will be produced that offers only SDRAM (same interface as today), SDCARD, and optional TV A/V. The original board would still be available. The new version could be combined with a new "I2C peripheral playground" module which would offer an I2C connected Propeller, some ports like USB and PS2 footprints, SDCARD, possibly an ADC, and prototyping area. The I2C attached slave Propeller could have it's boot program updated by the master Propeller.
I think I asked this before but anyway I'm confusing myself as to how HUB, external RAM and COG memory should be laid out in the ZPU memory map.
Currently ZPU executing code from HUB has no possibility of accessing external RAM except if it loads up VMCOG and uses the access functions.
Code executing from external RAM can see the 32K HUB located at $10000000 in its memory map.
This does not seem good to me. As I don't have a final application for Zog in mind at this time perhaps I cannot decide on a good solution.
Seems to me that code running from HUB should have the possibility to have a VMCOG running and hence be able to transparently use external memory if required. That is to say that "*pointer_to_ext_mem = something;" should work.
Conversely code running from ext RAM should be able to see HUB memory as it does now.
I'm thinking like this:
When running from HUB the address map puts HUB memory at zero, as it does now. It then has external memory, if required, at $10000000.
When running code from external memory the opposite is true. Addresses zero to $10000000 are ext RAM. After that is HUB space.
Any ideas?
Doug
Sorry, the SYSCALL read and write to the console was created with only support for running from HUB. Then it was forgotten about as normally we use the UART emulation for console I/O.
When running from Ext RAM all code, data and stack is in external memory.
Looks like we need external memory versions of the syscall stuff that access ZPU memory via VMCOG (or the SdramCache).
Is there a version of the ZOG VM that does the byte swapping at runtime instead of expecting it to have already been done before the code was loaded?
Thanks,
David
I'm having a bit of trouble with this statement: "You need to know if the data you are fetching from ZOG memory is long, word, or byte data....For instance, when reading a file from the SD card, you can't just swap everything because then the ZOG code will see byte-oriented data out of order."
I don't think you should need to know if the data output to a file comes from a LONG or WORD or any other size item.
The way I see it is I/O follows the Unix tradition of:
1) Everything is a file. Even if it is a serial port etc.
2) All reads and writes are byte oriented.
That is to say that when writing to files it is no different from writing bytes to the terminal. There is no concept of words or longs or any other structure. If the bytes come out in the right order on the terminal then they must come out in the right order on the file. And the same when reading from the console input or reading from a file.
Now that leaves the possibility that the data on the file is written from a system of opposite endianness to the system that reads it without them both agreeing a byte ordering for the on file data. But that is not something to fix in Zog as such.
Perhaps I'm not quite getting the issue here.
I have wondered about asking Bill to make a byte swapping VMCOG in the past. But there seems to be no point as what we have now is compatible with running from HUB memory and does not add any performance overhead.
You beat me to it.
I was going to try a test with that code snippet as well today. I was fairly sure it should work as I have done some endianness testing before with the "hello" and "endian" test programs.
Don't worry, didn't I say "...simple endianness issues have managed to totally confuse me at the best of times."
Where exactly are you seeing a problem?
Are your reading a file written from Zog or one created on the PC?
Hopefully I can find some time to play along a bit today. Seems I don't have to be in the office this weekend:)
Currently I am thinking of addresses 0-4M being reserved for ram, and 4M-8M for flash.
I will have to add "erase sector" (4K) and "load page" (512 byte program) commands to VMCOG, but the read's would be the same, and I'd disable the write commands.
On PropCade this would allow for 128K ram using 4 SPI ram's, and 4M flash using two 2MB flash dip chips.
That's great.
Is it all working from 64K?
It is not possible to blow a current ZPU binary to FLASH and have it just work.
The program includes variable space.
Also at address zero there is the restart vector. But that address is recycled as the ZPU pseudo register _memreg.
So it looks like it's time to get into GCC linker scripts to move library stuff into FLASH.
We are not going to use shared libraries to get code into flash. They would require of a big complicated dynamic linker to link them when the program is loaded/started. Basically it would require an operating system!
Rather what we need to be able to do is:
1) Link all the lib functions into a static library - libwhatever.a
2) When building the program link it with the static library.
3) BUT relocate all the library objects to FLASH memory addresses
I think the trick is that all code is normally in a section called ".text". That section is located by the current linker script. If we can rename the library code section to something else ".libtext" using objdump (or is it objcopy?). Then we can get the linker to locate the ".libtext" section at the flash address.
I have no idea how to do this at the moment:(
I can see a possible little problem already. When building a program only the library objects that are actually used are linked in to the binary.
So two different programs being loaded to RAM may expect the layout of the FLASH content to be totally different depending on what objects they actually use.
A modern flash chip can be programmed 100k+ times (usually >1M) so I think it would be quite an advantage to put .text in it - and save the ram for data.