Shop OBEX P1 Docs P2 Docs Learn Events
Zog - A ZPU processor core for the Prop + GNU C, C++ and FORTRAN.Now replaces S - Page 33 — Parallax Forums

Zog - A ZPU processor core for the Prop + GNU C, C++ and FORTRAN.Now replaces S

1303133353638

Comments

  • David BetzDavid Betz Posts: 14,511
    edited 2011-01-31 10:42
    I thought the switch was -mno-bytesbig. Could that be the problem?
  • David BetzDavid Betz Posts: 14,511
    edited 2011-01-31 10:52
    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.
  • Heater.Heater. Posts: 21,230
    edited 2011-01-31 11:04
    Sorry I was not very clear. I'm looking at exactly what you say. In endian.c I have the following declaration:
    unsigned int  a_number = 0x76543210;
    

    and that's what comes out as:
    00003ca4 <a_number>:
        3ca4:       76              loadsp 24
        3ca5:       54              storesp 16
        3ca6:       32              xor
        3ca7:       10              addsp 0
    

    in endian.lst wether I have the no-bytesbig or not.
  • David BetzDavid Betz Posts: 14,511
    edited 2011-01-31 11:13
    That's unfortunate. I guess that switch doesn't work. So much for making a little-endian ZOG. Too bad. Thanks for checking this!
  • Heater.Heater. Posts: 21,230
    edited 2011-01-31 11:50
    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
  • Heater.Heater. Posts: 21,230
    edited 2011-01-31 12:44
    It's not looking good, here is a reply from
  • jazzedjazzed Posts: 11,803
    edited 2011-01-31 12:54
    Heater, have you had a chance to try one of David's .zip with your SDRAM board?
  • Heater.Heater. Posts: 21,230
    edited 2011-01-31 13:04
    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.
  • David BetzDavid Betz Posts: 14,511
    edited 2011-01-31 13:32
    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.
  • jazzedjazzed Posts: 11,803
    edited 2011-01-31 14:04
    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.
  • Heater.Heater. Posts: 21,230
    edited 2011-02-01 03:50
    OK my GG_SDRAM is up and running.

    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....
  • Heater.Heater. Posts: 21,230
    edited 2011-02-09 04:15
    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:)
  • jazzedjazzed Posts: 11,803
    edited 2011-02-09 07:35
    Heater. wrote: »
    OK my GG_SDRAM is up and running.
    Is your fridge still causing grief?

    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.
  • Heater.Heater. Posts: 21,230
    edited 2011-02-09 08:43
    Jazzed,

    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.
  • jazzedjazzed Posts: 11,803
    edited 2011-02-09 08:48
    Do you have the fridge problem with other hardware?
  • Heater.Heater. Posts: 21,230
    edited 2011-02-09 09:00
    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.
  • Heater.Heater. Posts: 21,230
    edited 2011-02-13 09:30
    OK Guys, Just found 10 mins to do some zogging.

    I have on my Debian box a setenv.linux like so:
    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.

    Anyway looked like something good happened:)
  • Heater.Heater. Posts: 21,230
    edited 2011-02-13 09:37
    Ah...I just found the InitSerialTerm(...) in initio.c. With that in uncommented I now have:
    Hello, world!
    CLKFREQ: 80000000
    CNT b56cfe23
    CNT b59319c3
    cogid() = 13
    poeqw......etc etc
    
    Coming out on the terminal.

    Excellent! Never realized I had 13 COGs available on this board:)
  • Heater.Heater. Posts: 21,230
    edited 2011-02-13 09:47
    Something needs fixing with zogload. It is using 100% of my CPU. All the fans go turbo and everything gets very noisy around here:)
  • jazzedjazzed Posts: 11,803
    edited 2011-02-13 12:40
    Heater. wrote: »
    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.

    and ZOG turns 50 ....
  • Heater.Heater. Posts: 21,230
    edited 2011-02-13 13:14
    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?

    I have to get my efforts with Lonesock's floating point working in here some how.
  • jazzedjazzed Posts: 11,803
    edited 2011-02-13 13:51
    Heater. wrote: »
    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.
  • David BetzDavid Betz Posts: 14,511
    edited 2011-02-13 19:05
    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.
  • Andrey DemenevAndrey Demenev Posts: 377
    edited 2011-05-20 02:38
    I am giving ZPU a try, and I'm very surprised with the size of generated code. I am compiling a simple dummy program
    int main(void)
    {
        return 2;
    }
    
    command line :
    /home/andrey/zpugcc/bin/zpu-elf-gcc -phi -Wl,--relax -Wl,--gc-sections  test.c
    
    And zpu-elf-size -d a.out says
    text	   data	    bss	    dec	    hex	filename
       2132	    952	     20	   3104	    c20	a.out
    
    What the ......?!!! Over 2KiB code? 952 bytes data? I'm shocked
  • Heater.Heater. Posts: 21,230
    edited 2011-05-20 04:27
    Andrey,

    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.
  • Heater.Heater. Posts: 21,230
    edited 2011-05-20 04:48
    Andrey,

    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.out
    
    Pretty 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:
    ./zpugcc/install/bin/zpu-elf-gcc  -nostdlib -O3 -phi -Wl,--relax -Wl,--gc-sections  test.c
    
    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:
    ./zpugcc/install/bin/zpu-elf-objcopy -O binary a.out a.bin
    
    You do end up with a runnable program of 6 bytes in size in this case.
  • Andrey DemenevAndrey Demenev Posts: 377
    edited 2011-05-20 06:00
    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
  • Heater.Heater. Posts: 21,230
    edited 2011-05-20 06:27
    Andrey,
    Useless

    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.
  • Andrey DemenevAndrey Demenev Posts: 377
    edited 2011-05-20 06:40
    Heater. wrote: »
    Then there is the udiv and umod routines that get implanted by the compiler somehow.

    udivmodsi4 is calld by __divsi3 and __modsi3, which in turn are called by emulations of DIV and MOD instructions
  • lonesocklonesock Posts: 917
    edited 2011-05-20 10:55
    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.

    http://repo.or.cz/w/llvm/zpu.git

    Jonathan
Sign In or Register to comment.