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

1356738

Comments

  • heaterheater Posts: 3,370
    edited February 2010 Vote Up0Vote Down
    In an idle moment I just started coding the ZPU emulator in PASM working from the ZyLin Java simulator code and my C version of same. So far I have 44 of the 47 ops in place and have only used 255 longs !

    What's missing? Basically the support infrastructure:

    Dispatch table in HUB.
    A fetch and dispatch loop.
    The essential push and pop functions for this stack based machine.
    BYTE, WORD and LONG ZPU memory access functions.
    Some arithmetic functions.

    All of the above won't take 240 longs so it looks as if everything is going to fit in a single COG !!

    Sorry Bill this is going so easily there may never be a Spin version of the ZPU. Hope we can test VMCog from this PASM version soon.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Bill HenningBill Henning Posts: 6,439
    edited February 2010 Vote Up0Vote Down
    Wow! Great progress!

    Maybe there will even be room for moving the dispatch table into the cog...

    Please see VMCOG.spin for the Spin access functions, by writing pasm equivalents, you will be interfaced [noparse]:)[/noparse]

    I hope to have VMCOG running in a couple of days...
    heater said...
    In an idle moment I just started coding the ZPU emulator in PASM working from the ZyLin Java simulator code and my C version of same. So far I have 44 of the 47 ops in place and have only used 255 longs !

    What's missing? Basically the support infrastructure:

    Dispatch table in HUB.
    A fetch and dispatch loop.
    The essential push and pop functions for this stack based machine.
    BYTE, WORD and LONG ZPU memory access functions.
    Some arithmetic functions.

    All of the above won't take 240 longs so it looks as if everything is going to fit in a single COG !!

    Sorry Bill this is going so easily there may never be a Spin version of the ZPU. Hope we can test VMCog from this PASM version soon.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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 / @Mikronauts on Twitter
    RoboPi: The most advanced Robot controller for the Raspberry Pi (Propeller based)
  • heaterheater Posts: 3,370
    edited February 2010 Vote Up0Vote Down
    Attached is version 0.1 of the ZPU virtual machine for the Prop.

    First off I have to say this does NOT work yet.

    Basically it has all the ZPU opcodes in place and runs around executing NOPs in the ZPU memory space in HUB.
    The ZPU memory area is loaded from a binary image file, nops.bin (full of NOPs), with a "file" statement.

    A simple user interface is provided by a serial link back to the terminal in BST or whatever.

    So far the entire VM uses 365 LONGS in COG. A typical ZPM opcode takes 35 PASM instructions to execute.

    I have not done any testing on this yet, apart from NOP, so for sure it does not work. Just thought someone out there might be interested to see how it looks and having a backup on the forum is convenient[noparse]:)[/noparse]

    I haven't paid any attention to optimization so if anyone has any sneaky speed up tricks now is the time to say.

    Bad news is that the smallest Hello World program I have managed to compile with the ZPU version of GCC is about 12K bytes! I have to get down to working without having to drag in a lot of C library stuff.

    I had a change of heart about the name for this project. It's been renamed "ZOG" for Z in a Cog.
    The Cogz name was just not working for me but ZOG is stuck in my head. RossH seemed to settle on ZOG as well.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Bill HenningBill Henning Posts: 6,439
    edited February 2010 Vote Up0Vote Down
    Nice start!

    one optimization I almost always use is that I keep the top of the stack in a cog register - then all the operations like 'neg' and 'rev' become MUCH faster, so do add, etc.

    Oh... you might want to google Zog and look at the Wikipedia entry - I don't think its a good name.
    heater said...
    Attached is version 0.1 of the ZPU virtual machine for the Prop.

    First off I have to say this does NOT work yet.

    Basically it has all the ZPU opcodes in place and runs around executing NOPs in the ZPU memory space in HUB.
    The ZPU memory area is loaded from a binary image file, nops.bin (full of NOPs), with a "file" statement.

    A simple user interface is provided by a serial link back to the terminal in BST or whatever.

    So far the entire VM uses 365 LONGS in COG. A typical ZPM opcode takes 35 PASM instructions to execute.

    I have not done any testing on this yet, apart from NOP, so for sure it does not work. Just thought someone out there might be interested to see how it looks and having a backup on the forum is convenient[noparse]:)[/noparse]

    I haven't paid any attention to optimization so if anyone has any sneaky speed up tricks now is the time to say.

    Bad news is that the smallest Hello World program I have managed to compile with the ZPU version of GCC is about 12K bytes! I have to get down to working without having to drag in a lot of C library stuff.

    I had a change of heart about the name for this project. It's been renamed "ZOG" for Z in a Cog.
    The Cogz name was just not working for me but ZOG is stuck in my head. RossH seemed to settle on ZOG as well.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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

    Post Edited (Bill Henning) : 2/9/2010 10:17:20 PM GMT
    www.mikronauts.com / E-mail: mikronauts _at_ gmail _dot_ com / @Mikronauts on Twitter
    RoboPi: The most advanced Robot controller for the Raspberry Pi (Propeller based)
  • heaterheater Posts: 3,370
    edited February 2010 Vote Up0Vote Down
    Zog - King of Albania.

    Zog - To frolic amongst friends upon turf or the earth in hopes of mentally, physically and emotionally crushing one's enemies in ritual sporting; these games are usually followed by friendly banter accompanied by games centered around consuming beer

    "I can't wait to Zog on Sunday!"

    "I love Zog"

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Bill HenningBill Henning Posts: 6,439
    edited February 2010 Vote Up0Vote Down
    LOL, true.

    We should not let conspiracy umm fans dictate words anyway [noparse]:)[/noparse]
    heater said...
    Zog - King of Albania.

    Zog - To frolic amongst friends upon turf or the earth in hopes of mentally, physically and emotionally crushing one's enemies in ritual sporting; these games are usually followed by friendly banter accompanied by games centered around consuming beer

    "I can't wait to Zog on Sunday!"

    "I love Zog"
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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 / @Mikronauts on Twitter
    RoboPi: The most advanced Robot controller for the Raspberry Pi (Propeller based)
  • RossHRossH Posts: 4,057
    edited February 2010 Vote Up0Vote Down
    What? You've never heard of ZOG? "Zog is over a thousand feet high, but other than that, it is unknown what powers he possessed."

    ZOG will be very, very, unhappy if you decide to change the name.

    Ross.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Catalina - a FREE C compiler for the Propeller - see Catalina
    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • heaterheater Posts: 3,370
    edited February 2010 Vote Up0Vote Down
    Not to mention the famous Professor Philo Zog inventor of the giant robot called Electro, which he controls by remote-control electra waves. en.wikipedia.org/wiki/Elektro_(comics)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited February 2010 Vote Up0Vote Down
    Bill: "...keep the top of the stack in a cog register..."

    Sounds good but I can't see how to make it work.

    If I understand correctly the idea is that every time a PUSH is done the pushed value, which is now top of stack, is cached locally. Then the next instruction starting with POP only has to adjust the stack pointer and use the cached top of stack value. No actual read from the stack is required. A second POP would have to do the read as normal. This sounds great, it removes a lot of redundant reads.

    BUT what to do in the face of instructions that can basically write anywhere in memory which may or may not write to the stack top thus making the cached stack top value out of date? Or instructions that end with a POP?

    For example STOREH which does:

    address = pop();
    value = pop();
    WriteWord(addr, val);

    Looks like it requires a "dirty" bit. Any instruction that ends with a PUSH, caches the pushed value and sets the dirty bit to "clean", the cached value is valid.
    Any other instruction sets the dirty bit to "dirty", the cached value may be old.
    Any instruction that starts with a POP checks the dirty bit and skips reading the stack if "clean"
    Any second POP within an instruction should always do the stack read as normal.

    Think that covers it.

    All this dirty bit setting/checking takes time and space but compared to the long winded reads from external RAM must be quite a gain.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.

    Post Edited (heater) : 2/10/2010 8:56:03 AM GMT
  • heaterheater Posts: 3,370
    edited February 2010 Vote Up0Vote Down
    But then we could keep an internal stack of the last two items pushed and all the ops that basically do:

    x = pop()
    y = pop()
    z = some_operation(x, y)
    push(z)

    would hardly ever have to go to external memory for their operands. That's about 50% of the ops.

    Maintaining the internal stack and it's state of cleanliness might be an optimization to far...

    We are going to give Catalina a run for it's money after all [noparse]:)[/noparse]

    Bill: Do you have a test version of your VM that has no external memory? Say just serving up 16K of HUB RAM.
    When I have tested Zog a bit I'd like to move it's memory space to another COG and access it via your mailbox interface.
    Just for testing.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.

    Post Edited (heater) : 2/10/2010 9:38:52 AM GMT
  • Bill HenningBill Henning Posts: 6,439
    edited February 2010 Vote Up0Vote Down
    SP    LONG  0
    TOS  LONG  0
    NOS  LONG 0
    
    pushpc:
       sub  sp,#4
       wrlong TOS,sp
       mov TOS,pc
    pushpc_ret: ret
    
    poppc:
       mov  pc,TOS
       add sp,#4
       rdlong TOS,SP
    poppc_ret: ret
    
    rev:
       rev TOS
       jmp #next
    
    neg:
       neg TOS
       jmp #next
    
    popadd:
        add sp,#4
        rdlong NOS,sp
        add TOS,nos
        jmp #next
    
    sub:
        add sp,#4
        rdlong NOS,sp
        sub NOS,TOS
        mov TOS,NOS
        jmp #next
    
    storeh:
        ' TOS holds the value when we get here, as it is the Top Of Stack
        add sp,#4
        rdlong NOS,SP  ' we pop the address
        wrword NOS, TOS ' write it
        add sp,#4
        rdlong TOS,sp ' and get new TOS off the stack
        jmp #next
    
    fetch_long: ' ie replace TOS with long pointed to by TOS
        rdlong TOS, TOS
        jmp #next
    
    
    



    I think the above gives you the idea [noparse]:)[/noparse]

    See the 'sub' case, where TOS & NOS have to be flipped as subtraction is not commutative

    See a quick&dirty STOREH implementation

    See neg, rev

    Does not need a 'Dirty' bit, just careful use of TOS, NOS and SP - note NOS is just a special temporary, and is NOT always the number below TOS - just a place holder for it, in case we need to access it.

    Another optimization:

    set SP to zog_base+zog_sp, only pushsp needs the "zog_sp" - there you can give it that by subtracting zog_base; VAST majority of accesses then sped up by removing an add

    same for PC - set it to zog_base+zog_pc, only subtract out base before pushing it, and add on pops - again, vast majority of accesses want to deal with (zog_base + zog_pc), thus good optimization

    I use these technique in several unpublished byte code interpreters I've built over the years, HUGE speedup [noparse]:)[/noparse]
    heater said...
    Bill: "...keep the top of the stack in a cog register..."

    Sounds good but I can't see how to make it work.

    If I understand correctly the idea is that every time a PUSH is done the pushed value, which is now top of stack, is cached locally. Then the next instruction starting with POP only has to adjust the stack pointer and use the cached top of stack value. No actual read from the stack is required. A second POP would have to do the read as normal. This sounds great, it removes a lot of redundant reads.

    BUT what to do in the face of instructions that can basically write anywhere in memory which may or may not write to the stack top thus making the cached stack top value out of date? Or instructions that end with a POP?

    For example STOREH which does:

    address = pop();
    value = pop();
    WriteWord(addr, val);

    Looks like it requires a "dirty" bit. Any instruction that ends with a PUSH, caches the pushed value and sets the dirty bit to "clean", the cached value is valid.
    Any other instruction sets the dirty bit to "dirty", the cached value may be old.
    Any instruction that starts with a POP checks the dirty bit and skips reading the stack if "clean"
    Any second POP within an instruction should always do the stack read as normal.

    Think that covers it.

    All this dirty bit setting/checking takes time and space but compared to the long winded reads from external RAM must be quite a gain.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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

    Post Edited (Bill Henning) : 2/10/2010 3:22:48 PM GMT
    www.mikronauts.com / E-mail: mikronauts _at_ gmail _dot_ com / @Mikronauts on Twitter
    RoboPi: The most advanced Robot controller for the Raspberry Pi (Propeller based)
  • Bill HenningBill Henning Posts: 6,439
    edited February 2010 Vote Up0Vote Down
    [noparse]:)[/noparse]

    See all the sample code in my previous reply ... I've been using this technique for quite a while, and it gives a huge speedup.

    The latest VMCOG can easily serve up 16K of hub:

    vm.start(@mailbox,$7C00,64) ' See VMDebug.spin, this will make virtual addresses $0000-$3FFF available for use right now.

    The $7C00 is so VMCOG can run under SphinxOS.

    Currently vm.rdvbyte(addr) and vm.wrvbyte(addr,val) messages work fine (see VMCOG.spin for implementation of those spin methods, shows you how to poke values into the mailbox and get results from it.

    I hope to get rdvword/rdvlong/wrvword/wrvlong running today.

    You will find commands 1,3,6 and 9 very useful for debugging.

    1 - shows you the TLB, including dirty bit, physical address, and access count
    3 - read a byte from specified virtual address
    6 - write a byte to specified virtual address
    9 - shows you a hex dump of a virtual page (as long as it is in the working set)

    Later I may change to a command line monitor style debugger instead of menu's.
    heater said...
    But then we could keep an internal stack of the last two items pushed and all the ops that basically do:

    x = pop()
    y = pop()
    z = some_operation(x, y)
    push(z)

    would hardly ever have to go to external memory for their operands. That's about 50% of the ops.

    Maintaining the internal stack and it's state of cleanliness might be an optimization to far...

    We are going to give Catalina a run for it's money after all [noparse]:)[/noparse]

    Bill: Do you have a test version of your VM that has no external memory? Say just serving up 16K of HUB RAM.
    When I have tested Zog a bit I'd like to move it's memory space to another COG and access it via your mailbox interface.
    Just for testing.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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

    Post Edited (Bill Henning) : 2/10/2010 3:23:42 PM GMT
    www.mikronauts.com / E-mail: mikronauts _at_ gmail _dot_ com / @Mikronauts on Twitter
    RoboPi: The most advanced Robot controller for the Raspberry Pi (Propeller based)
  • heaterheater Posts: 3,370
    edited February 2010 Vote Up0Vote Down
    OK Bill, that's starting to make sense. I'm not going to get into any such optimizations until Zog is tested and happily running some GCC output.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Bill HenningBill Henning Posts: 6,439
    edited February 2010 Vote Up0Vote Down
    Sounds like a plan...

    FYI, I just uploaded VMCOG v0.25 - this version adds aligned word and long reads from the working set

    I am working on aligned word and long writes right now, and once those work as well, I will add support for non-aligned word/long reads/writes

    non-aligned is a pain because it may cross page boundaries.
    heater said...
    OK Bill, that's starting to make sense. I'm not going to get into any such optimizations until Zog is tested and happily running some GCC output.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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 / @Mikronauts on Twitter
    RoboPi: The most advanced Robot controller for the Raspberry Pi (Propeller based)
  • RossHRossH Posts: 4,057
    edited February 2010 Vote Up0Vote Down
    heater said...

    We are going to give Catalina a run for it's money after all [noparse]:)[/noparse]
    Them's fightin' words! Nominate your second - and make sure they can stand the sight of blood!

    Ross.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Catalina - a FREE C compiler for the Propeller - see Catalina
    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • Cluso99Cluso99 Posts: 12,580
    edited February 2010 Vote Up0Vote Down
    Nothing like a challenge to bring out the best in a design. Apple used to run two design teams and the best design won out (not sure it they still do that).

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • heaterheater Posts: 3,370
    edited February 2010 Vote Up0Vote Down
    I don' think Zog stands much of a chance.

    But with Bill's suggested optimizations and the VM cache Zog might not be totally embarrassed. Especially in some odd contrived cases like running code directly from an attached SPI FLASH with data and stack in HUB.

    Actually, that sounds like a damn useful use-case. How great it would be if Spin could execute from the program FLASH leaving all the RAM for working data.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited February 2010 Vote Up0Vote Down
    The madness grows: How about C++ for the Propeller?

    Just for Humanoido's list.

    For the Propeller ZPU emulator this:
    class aclass
    {
    public:
        aclass()
        {
            a = 42;
        }
    
        int get()
        {
            return (a);
        }
    
        void set(int val)
        {
            a = val;
        }
    private:
        int a;
    };
    
    int main (int argc, char* argv[noparse][[/noparse] ])
    {
        aclass* aobj = new aclass();
        aclass* bobj = new aclass();
    
        bobj->set(aobj->get());
        *aobj = *bobj;
    
            return (aobj->get());
    }
    
    


    Produces this:
        .file    "hello.cpp"
    .text
        .globl    main
        .type    main, @function
    main:
        im -2
        pushspadd
        popsp
        im 4
        storesp 4
        impcrel (_Znwm)
        callpcrel
        im _memreg+0
        load
        storesp 12
        im 42
        nop
        im _memreg+0
        load
        store
    .L3:
        im 4
        storesp 4
        impcrel (_Znwm)
        callpcrel
        im 42
        nop
        im _memreg+0
        load
        store
    .L6:
        loadsp 8
        load
        loadsp 0
        im _memreg+0
        load
        store
        loadsp 0
        loadsp 16
        store
    .L1:
        im _memreg+0
        store
        im 4
        pushspadd
        popsp
        poppc
        .size    main, .-main
        .ident    "GCC: (GNU) 3.4.2"
    
    


    After doing this:
    zpu-elf-g++   -Os   -phi   -Wl,--relax -Wl,--gc-sections   -S   -o hello.s   hello.cpp
    
    



    We will have Catalina and ICC totally on the mat when we get to being able to run that[noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • jazzedjazzed Posts: 11,795
    edited February 2010 Vote Up0Vote Down
    I look forward to GCC on ZOG.

    Do you think it require external memory? Not a problem if it does, but would be nice to do reasonable stuff without it.

    I finally made a Fedora uSD card so I can use the toolchain on my laptop. If you have a pointer to linux binaries, that would save a ton of work.

    How would one download the program to the Propeller (without resident CPM, or other OS) ?

    BTW, one offshoot of my 32 bit addressable Spin interpreter investigations/development would be running spin from any media including uSD as you suggested above. Having a compiler option to put stack and variables in HUB ram would make that possible ... preliminary discussion has started in this area. Not trying to hijack the thread of course.

    Post Edited (jazzed) : 2/11/2010 5:31:00 PM GMT
  • heaterheater Posts: 3,370
    edited February 2010 Vote Up0Vote Down
    Jazzed: Great you want to play along.

    You can download the binary release of GCC for ZPU from this page:

    opensource.zylin.com/zpudownload.html

    Make a directory for your zpu tool chain and change to it, I called mine zpu:

    $ mkdir zpu

    $ cd zpu

    Put the down loaded package there and unpack it:

    $ tar -xvjf zpugcclinux.tar.bz2

    That will have created an "install" directory full of ZPU goodies.

    Now you should be able to run GCC for ZPU.

    $ ./bin/zpu-elf-gcc bla bla bla ...

    See post above for options I use in compiling.

    Zog will run fine without external memory. For sure the first versions will only use HUB RAM.
    How useful that turns out to be remains to be seen. Catalina and ICC may be better/faster there although ZPU should have smaller binaries.

    For now the ZPU binaries are downloaded within the Spin program. They are just included into a DAT section in a "file" statement. No other OS or software required.

    I have yet to think about how this will work in future. Especially when we have external memory. Don't tempt me with getting CP/M to do it[noparse]:)[/noparse]

    Zog could of course be fixed in the Propeller boot ROM as normal and include a simple secondary boot loader to get the ZPU binary down. But we should also think about integration with other objects in Spin like Catalina does. Early days yet. Or think about booting ZPU code from SD etc.

    Spin from external RAM or FLASH would be great. Same with Zog. Similarly I have yet to figure out how to separate the code and data sections from a ZPU compilation.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited February 2010 Vote Up0Vote Down
    By the way the pre-compiled GCC for ZPU does not include C++ you will have to compile GCC from the sources to get that.
    I can give instructions if anyone wants.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • RossHRossH Posts: 4,057
    edited February 2010 Vote Up0Vote Down
    heater,

    C++ polluting our beautiful Propeller???? Noooooooooo!

    Ross.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Catalina - a FREE C compiler for the Propeller - see Catalina
    Catalina - a FREE ANSI C compiler for the Propeller.
    Download it from http://catalina-c.sourceforge.net/
  • heaterheater Posts: 3,370
    edited February 2010 Vote Up0Vote Down
    I find that C++ is an excellent enhancement to C. Provided you stay away from classes and templates [noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited February 2010 Vote Up0Vote Down
    FORTRAN for the Propeller anyone?

    Zog is now at the stage where it can, on the Propeller, limp around a simple C while(1); loop compiled with GCC.

    As a bit of a retro computing fan I had to try and get GCC to compile some FORTRAN for Zog which it can then run on the Propeller. Results:

    This FORTRAN program:

          PROGRAM HELLOW
    *     The PRINT statement is like WRITE,
    *     but prints to the standard output unit
            PRINT*, '(A)', 'Hello, world'
            STOP
          END
    
    


    Becomes this Zog assembler for the Prop.
        .file    "test.for"
    .data
        .balign 4;
        .type    __g77_cilist_0.0, @object
        .size    __g77_cilist_0.0, 20
    __g77_cilist_0.0:
        .long    0
        .long    6
        .long    0
        .long    0
        .long    0
        .section    .rodata
        .balign 4;
    .LC0:
        .ascii    "(A)"
        .balign 4;
    .LC3:
        .ascii    "Hello, world"
        .balign 4;
    .LC4:
        .section    .rodata.cst4,"aM",@progbits,4
        .balign 4;
    .LC1:
        .long    1
        .balign 4;
    .LC2:
        .long    9
    .text
        .globl    MAIN__
        .type    MAIN__, @function
    MAIN__:
        im -3
        pushspadd
        popsp
        im __g77_cilist_0.0
        storesp 4
        impcrel (s_wsle)
        callpcrel
        im 3
        storesp 16
        im .LC0
        storesp 12
        im .LC1
        storesp 8
        im .LC2
        storesp 4
        impcrel (do_lio)
        callpcrel
        im 12
        storesp 16
        im .LC3
        storesp 12
        im .LC1
        storesp 8
        im .LC2
        storesp 4
        impcrel (do_lio)
        callpcrel
        impcrel (e_wsle)
        callpcrel
        im 0
        storesp 8
        im .LC4
        storesp 4
        impcrel (s_stop)
        callpcrel
        .size    MAIN__, .-MAIN__
        .ident    "GCC: (GNU) 3.4.2"
    
    


    It does not quite link into a complete executable program yet but we are nearly able to run FORTRAN on the Propeller!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • trodosstrodoss Posts: 577
    edited February 2010 Vote Up0Vote Down
    @heater,
    If you have FORTRAN compiling, why not go for COBOL [noparse];)[/noparse]
    http://cobolforgcc.sourceforge.net/

    Sounds like Zog is making progress. Keep up the great work!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Game(s) Mythic Flight
    Utilities Font Editors (AIGeneric, Potato_Text, etc.)
  • Bill HenningBill Henning Posts: 6,439
    edited February 2010 Vote Up0Vote Down
    Very cool!

    What's next - ADA?
    heater said...
    FORTRAN for the Propeller anyone?

    Zog is now at the stage where it can, on the Propeller, limp around a simple C while(1); loop compiled with GCC.

    As a bit of a retro computing fan I had to try and get GCC to compile some FORTRAN for Zog which it can then run on the Propeller. Results:

    This FORTRAN program:

          PROGRAM HELLOW
    *     The PRINT statement is like WRITE,
    *     but prints to the standard output unit
            PRINT*, '(A)', 'Hello, world'
            STOP
          END
    
    


    Becomes this Zog assembler for the Prop.
        .file    "test.for"
    .data
        .balign 4;
        .type    __g77_cilist_0.0, @object
        .size    __g77_cilist_0.0, 20
    __g77_cilist_0.0:
        .long    0
        .long    6
        .long    0
        .long    0
        .long    0
        .section    .rodata
        .balign 4;
    .LC0:
        .ascii    "(A)"
        .balign 4;
    .LC3:
        .ascii    "Hello, world"
        .balign 4;
    .LC4:
        .section    .rodata.cst4,"aM",@progbits,4
        .balign 4;
    .LC1:
        .long    1
        .balign 4;
    .LC2:
        .long    9
    .text
        .globl    MAIN__
        .type    MAIN__, @function
    MAIN__:
        im -3
        pushspadd
        popsp
        im __g77_cilist_0.0
        storesp 4
        impcrel (s_wsle)
        callpcrel
        im 3
        storesp 16
        im .LC0
        storesp 12
        im .LC1
        storesp 8
        im .LC2
        storesp 4
        impcrel (do_lio)
        callpcrel
        im 12
        storesp 16
        im .LC3
        storesp 12
        im .LC1
        storesp 8
        im .LC2
        storesp 4
        impcrel (do_lio)
        callpcrel
        impcrel (e_wsle)
        callpcrel
        im 0
        storesp 8
        im .LC4
        storesp 4
        impcrel (s_stop)
        callpcrel
        .size    MAIN__, .-MAIN__
        .ident    "GCC: (GNU) 3.4.2"
    
    


    It does not quite link into a complete executable program yet but we are nearly able to run FORTRAN on the Propeller!
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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 / @Mikronauts on Twitter
    RoboPi: The most advanced Robot controller for the Raspberry Pi (Propeller based)
  • heaterheater Posts: 3,370
    edited February 2010 Vote Up0Vote Down
    FORTRAN only comes into the picture here because the version of GCC (3.4.2) that has been targeted at the ZPU architecture is already able to compile it. Looks like it has java in there as well but I have not managed to get it to compile anything yet.

    As far as I can tell COBOL for GCC is not "done" yet. The version of GCC that the ZPU developers have used does not support COBOL and I doubt if they will ever bring there GCC version up to any newer version that may have COBOL.

    Oh well.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited February 2010 Vote Up0Vote Down
    Well, actually Bill, when I rebuilt the GCC for ZPU without configuring which languages it should support (Then it should default to "all") I was hoping to find Ada in there. Sadly not.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Bill HenningBill Henning Posts: 6,439
    edited February 2010 Vote Up0Vote Down
    C'est la vie
    heater said...
    Well, actually Bill, when I rebuilt the GCC for ZPU without configuring which languages it should support (Then it should default to "all") I was hoping to find Ada in there. Sadly not.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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 / @Mikronauts on Twitter
    RoboPi: The most advanced Robot controller for the Raspberry Pi (Propeller based)
  • Cluso99Cluso99 Posts: 12,580
    edited February 2010 Vote Up0Vote Down
    RPG, ALGOL ???

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
Sign In or Register to comment.