Actually, I'm not sure what you're saying. The bytecodes will of course be generated in the same order since that is the execution order. The only thing that -mno-bytesbig does is affect the order in which bytes are assembled into larger values like words and longs. Try doing something like including an initialized value like "int foo = 0x12345678;" and look at the order of the bytes in the image.
I just fired of a query about this to the ZPU mailing list.
I'm not totally sure what they are up to, zpu-gcc seems to be progressing but there is also an effort to target LLVM at the ZPU. Like for example this http://markmail.org/message/gluah2rubysjfk7t
Sadly not. I managed to find 10 mins to fix up a Prop Plug for use with the board on Friday. Since then I have been traveling to and from the snowy forests of central Finland. Back home tonight so I'll see what I can do tomorrow.
There is a much newer version of the C3/SDRAM version of ZOG about to be uploaded to the C3 FTP site. There will be a Windows binary release that contains all of the tools need to build ZOG programs for either the C3 or the Propeller Platform/SDRAM as well as a source release of the stuff that Steve and I have been working on. The ZPU tools remain the same as the ones currently used for ZOG. I've attached a zip file with the source release to this message.
That's great David. Now all I have to do is finish adding keyboard/mouse support
... and TvFullColor, ... and program your board, and the other 15 things on my TODO list
Heater, David's .zip should also work with Linux - that's how I've been testing it.
I have some TV demos which didn't make it into that .zip to post later.
After a minor panic with my Prop Plug not working. Turned out to be an intermittent USB connection due to a dicky USB cable, a thin extendible thing with the "yoyo" in the middle. Odd because that same USB cable has been working with a Prop ASC board with no problem for a long time.
So far the SdramTest is working although I might never find out if "test all" works. Every time the fridge in my house turns off the USB connection gets broken and BST crashes! This happens often enough that there may never be time to get to the end of the RAM test. I've tried a few different power supplies to fix this problem with other boards without success so far.
Somewhat off topic but this guy seems to have implemented a multi-core with share memory system on an FPGA using the ZPU core. Kind of like a ZPU propeller.
Perhaps anyone who can read German here could enlighten us as to what he was up to. Maybe he should have just used a Propeller anyway:)
The SdramTest.spin should do a quick test before getting to the command prompt.
I've not seen a board failure after the quick test passes and Zog is quite happy.
The full test takes a very long time. A PASM version would be useful.
The fridge is still causing grief.
However the other day "her indoors" was away for a few days and as a result the fridge was empty. So I yanked it's plug and ran the SRAM test. No problem.
Just now I'm furiously trying to meet some project deadlines at work so Zogging will be delayed yet again.
My old home made demo board had the same problem which I attributed to it being a lash up.
The Prop ASC does not suffer from "fridge syndrome" but then it is powered from the PC's USB port.
Strangely enough I forgotten if the TriBlade was a victim. I'll have to fire it up again.
export OS=linux
export PORT=/dev/ttyUSB0
export BOARD=sdram
export ZOGPATH=`pwd`
export ZPUPATH=~/zpugcc/toolchain/install/bin/
alias zogload=$ZOGPATH/bin/$OS/zogload
alias zogcc=$ZPUPATH/zpu-elf-gcc
So, source setenv.linux and make seems to run along nicely and build slots of stuff without error.
Then cd tests/hello; make; make run produces a nice output like so:
$ make run
make[1]: Entering directory `/home/michael/zog_dbetz/libsrc'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/michael/zog_dbetz/libsrc'
Loading through port /dev/ttyUSB0 to board sdram
Propeller Version 1 on /dev/ttyUSB0
Writing 14856 bytes to Propeller RAM.
Verifying ... Upload OK!
22404 bytes sent
Entering terminal mode...
Looks good but Ah..stuck. I have no TV or keyboard to connect to the SRAM board.
Hmm...come to that I don't have an SD card for it yet either.
Something needs fixing with zogload. It is using 100% of my CPU. All the fans go turbo and everything gets very noisy around here:)
Congrats on getting something running heater!
rx_timeout in the zogload/src/osint_linux.c file uses poll for checking data.
timeout_us should probably be set to a non-zero value
I've been drag-racing between zog and bigspin ... with some changes, zog wins by a nose.
It's looks like it's going to take me a while to find my way around all this new stuff. I don't recognize anything any more:) Does anyone have a map?
${ZOGPATH}
Various scripts for setting up boards/environments, documentation.
${ZOGPATH}/bin
Only appears if make has run. Contains linux/zogload or cygwin/zogload
${ZOGPATH}/include
Header files.
${ZOGPATH}/libsrc
Library code and board specific LD scripts.
${ZOGPATH}/tests
Various demo programs. initio.c sets up console I/O for applications per application.
${ZOGPATH}/zogload
This is where all the action is. src contains C files. spin contains zog.spin and others.
serial_helper.spin is the main downloader/launch point file for ZOG downloaded to RAM.
sd_loader.spin and other *_loader.spin files are like serial_helper.spin.
ZOG.spin is running short of COG space. I have a newer/faster version that has some extra space. See zog package in the BigSpin thread.
I guess it is a bit confusing where to find things in my zog directory tree. As jazzed said, the main ZOG code is under the zogload directory. You should recognize your own code in zogload/spin/zog.spin. Also, zogload/spin/serial_helper.spin is basically a hacked version of your old run-zog.spin program. All I've done is make a PC loader that knows how to write bootloaders to EEPROM and download code to external RAM or the SD card (zogload). I'm working on a version of zogload that can run with just hub RAM so you don't have to use a C3, SDRAM board or Dracblade to run ZOG. Anyway, the heart of this is still your code. I just added a bunch of stuff around the edges. Please let me know of any suggestions you have for improvements.
You will need a optimization option like -Os or -O3 to get the size down a bit.
It's interesting to look at the code with
$./zpugcc/install/bin/zpu-elf-objdump -D a.out > test.dump
That main function is 19 bytes with no optimization and reduces to 5 bytes with -Os or -O3. Not bad hey?.
So what about the other 2K?
Well looking in the dump file we see that things start of with a start up sequence at address zero (Which is also used as a pseudo register _memreg when running).
This is start sequence is short but is followed by about 1K of code that implements optional ZPU opcodes in case your hardware implementation does not have those opcodes.(loadh, storeh etc ) ZOG does not need any of that as it implements all opcodes. So we should create our own crt0.s with all that stripped out.
Also looking in the dump file we see that after our "main" we have some built in functions are included even if not used, __divsi3, __modsi3, udivmodsi4, etc. These are very long winded and I always wondered how to get rid of them.
So, OK this needs a bit of work on crt0.s which will require downloading the tool chain sources to get the source. Not sure about the div/mod routines but there must be a way to shorten or eliminate them.
I'm sure a lot can be done to get the size right down.
BUT:
1) It would be better if _start and _memreg were defined in their correct location (0) in assembler.
2) At some point your code may need those mod and div routines.
Heater, that's nice! But useless That way we are missing initialization (code in .init section) - at least. And at most - who knows, with programs a little bigger than that.
That is instruction emulation stuff pulling things from stdlib. I wonder why this all was put into startup file? Another strange thing is that if you dump code of crt0.o, you'll see that microcode is in .data section
What we need to do is take the crt0.s from the zpu-gcc sources and remove all that microcode/emulate stuff. Just leaving the initialization routines and whatever else we need from there. It's not much left I think. The emulation code is in crt0.s not stdlib despite the fact that "nostdlib" also leaves it out of the build.
The start up file contains the emulate stuff because it has been put together for use with ZPU cores implemented in FPGAs. A lot of people seem to be using the ZPU core without the full set of instructions in hardware so that is the way to be sure the compiler supports every possibility.
Then there is the udiv and umod routines that get implanted by the compiler somehow. Not sure what to do about them, it's a shame there is no unsigned div/mod opcodes in the ZPU. Perhaps we should define them in ZPU and provide alternate routines to use them.
Not sure about why the microcode/emulate stuff is in the .data section, it's a while since I had a look at it. But it makes no difference I think.
There is already a WIP ZPU target for LLVM, just when I compile it I can't get the ZPU target to work. I'd love for this to work, though, because I could also use clang as the C compiler front end.
Comments
and that's what comes out as:
00003ca4 <a_number>: 3ca4: 76 loadsp 24 3ca5: 54 storesp 16 3ca6: 32 xor 3ca7: 10 addsp 0in endian.lst wether I have the no-bytesbig or not.
I'm not totally sure what they are up to, zpu-gcc seems to be progressing but there is also an effort to target LLVM at the ZPU. Like for example this http://markmail.org/message/gluah2rubysjfk7t
... and TvFullColor, ... and program your board, and the other 15 things on my TODO list
Heater, David's .zip should also work with Linux - that's how I've been testing it.
I have some TV demos which didn't make it into that .zip to post later.
After a minor panic with my Prop Plug not working. Turned out to be an intermittent USB connection due to a dicky USB cable, a thin extendible thing with the "yoyo" in the middle. Odd because that same USB cable has been working with a Prop ASC board with no problem for a long time.
So far the SdramTest is working although I might never find out if "test all" works. Every time the fridge in my house turns off the USB connection gets broken and BST crashes! This happens often enough that there may never be time to get to the end of the RAM test. I've tried a few different power supplies to fix this problem with other boards without success so far.
Now, how to tackle the Zog package....
Perhaps anyone who can read German here could enlighten us as to what he was up to. Maybe he should have just used a Propeller anyway:)
The SdramTest.spin should do a quick test before getting to the command prompt.
I've not seen a board failure after the quick test passes and Zog is quite happy.
The full test takes a very long time. A PASM version would be useful.
The fridge is still causing grief.
However the other day "her indoors" was away for a few days and as a result the fridge was empty. So I yanked it's plug and ran the SRAM test. No problem.
Just now I'm furiously trying to meet some project deadlines at work so Zogging will be delayed yet again.
The Prop ASC does not suffer from "fridge syndrome" but then it is powered from the PC's USB port.
Strangely enough I forgotten if the TriBlade was a victim. I'll have to fire it up again.
I have on my Debian box a setenv.linux like so:
So, source setenv.linux and make seems to run along nicely and build slots of stuff without error.
Then cd tests/hello; make; make run produces a nice output like so:
Looks good but Ah..stuck. I have no TV or keyboard to connect to the SRAM board.
Hmm...come to that I don't have an SD card for it yet either.
Anyway looked like something good happened:)
Coming out on the terminal.
Excellent! Never realized I had 13 COGs available on this board:)
Congrats on getting something running heater!
rx_timeout in the zogload/src/osint_linux.c file uses poll for checking data.
timeout_us should probably be set to a non-zero value
I've been drag-racing between zog and bigspin ... with some changes, zog wins by a nose.
and ZOG turns 50 ....
Does anyone have a map?
I have to get my efforts with Lonesock's floating point working in here some how.
${ZOGPATH}
Various scripts for setting up boards/environments, documentation.
${ZOGPATH}/bin
Only appears if make has run. Contains linux/zogload or cygwin/zogload
${ZOGPATH}/include
Header files.
${ZOGPATH}/libsrc
Library code and board specific LD scripts.
${ZOGPATH}/tests
Various demo programs. initio.c sets up console I/O for applications per application.
${ZOGPATH}/zogload
This is where all the action is. src contains C files. spin contains zog.spin and others.
serial_helper.spin is the main downloader/launch point file for ZOG downloaded to RAM.
sd_loader.spin and other *_loader.spin files are like serial_helper.spin.
ZOG.spin is running short of COG space. I have a newer/faster version that has some extra space. See zog package in the BigSpin thread.
int main(void) { return 2; }command line : And zpu-elf-size -d a.out says What the ......?!!! Over 2KiB code? 952 bytes data? I'm shockedYou will need a optimization option like -Os or -O3 to get the size down a bit.
It's interesting to look at the code with
$./zpugcc/install/bin/zpu-elf-objdump -D a.out > test.dump
That main function is 19 bytes with no optimization and reduces to 5 bytes with -Os or -O3. Not bad hey?.
So what about the other 2K?
Well looking in the dump file we see that things start of with a start up sequence at address zero (Which is also used as a pseudo register _memreg when running).
This is start sequence is short but is followed by about 1K of code that implements optional ZPU opcodes in case your hardware implementation does not have those opcodes.(loadh, storeh etc ) ZOG does not need any of that as it implements all opcodes. So we should create our own crt0.s with all that stripped out.
Also looking in the dump file we see that after our "main" we have some built in functions are included even if not used, __divsi3, __modsi3, udivmodsi4, etc. These are very long winded and I always wondered how to get rid of them.
So, OK this needs a bit of work on crt0.s which will require downloading the tool chain sources to get the source. Not sure about the div/mod routines but there must be a way to shorten or eliminate them.
I'm sure a lot can be done to get the size right down.
Would you prefer something a bit smaller?
$ ./zpugcc/install/bin/zpu-elf-size -d a.out text data bss dec hex filename 6 0 24 30 1e a.outPretty good is it not? Needs a bit of work to get it running though.First I modify test.c like so:
int _memreg[2]; void _start(void) { main(); } int main(void) { return 2; }Where _start provides the missing label for the init code and _memreg is the pseudo registers used by GCC some times.Then I compile with:
That gives us a tiny executable binary.
BUT:
1) It would be better if _start and _memreg were defined in their correct location (0) in assembler.
2) At some point your code may need those mod and div routines.
Still if you convert that a.out to binary:
You do end up with a runnable program of 6 bytes in size in this case.
That is instruction emulation stuff pulling things from stdlib. I wonder why this all was put into startup file? Another strange thing is that if you dump code of crt0.o, you'll see that microcode is in .data section
Oh yeah, I forgot to mention that:)
What we need to do is take the crt0.s from the zpu-gcc sources and remove all that microcode/emulate stuff. Just leaving the initialization routines and whatever else we need from there. It's not much left I think. The emulation code is in crt0.s not stdlib despite the fact that "nostdlib" also leaves it out of the build.
The start up file contains the emulate stuff because it has been put together for use with ZPU cores implemented in FPGAs. A lot of people seem to be using the ZPU core without the full set of instructions in hardware so that is the way to be sure the compiler supports every possibility.
Then there is the udiv and umod routines that get implanted by the compiler somehow. Not sure what to do about them, it's a shame there is no unsigned div/mod opcodes in the ZPU. Perhaps we should define them in ZPU and provide alternate routines to use them.
Not sure about why the microcode/emulate stuff is in the .data section, it's a while since I had a look at it. But it makes no difference I think.
udivmodsi4 is calld by __divsi3 and __modsi3, which in turn are called by emulations of DIV and MOD instructions
http://repo.or.cz/w/llvm/zpu.git
Jonathan