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 5 — Parallax Forums

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

1235738

Comments

  • heaterheater Posts: 3,370
    edited 2010-02-19 20:01
    Chris Micro: "Since a certain time I have a dream that I can migrate all my software to any new microcontroller plattform"

    You are not alone in that dream. That's why C was invented. That's why GCC exists. That's why I'm busy on this crazy project to get GCC for the Propeller.

    Chris Micro: "The structure of ZOG seems much easier to implement than the propeller core. So this seems to be the architecture I have to use for my project."

    For sure the ZPU is about as simple as it gets. But wait, the GNU C Compiler has already been targeted at the 8 bit AVRs
    electrons.psychogenic.com/modules/arms/art/3/AVRGCCProgrammingGuide.php#installgcc
    I have used it. Works fine. No need for a ZPU virtual machine on Atmeg8.

    As we are talking about portable C code here we should not really care about the location if the I/O ports. Everything should go through inb(port) and outb(port, data) or some higher level functions.

    The ZPU architecture does not define any peripheral port addresses although the instruction set does dictate that I/O ports are in memory space notin a dedicated I/O space like on an Intel x86.

    As it happens there is a sort of standard or two among ZPU implementations about the location of peripheral ports. For example in the instructions for compiling code for Zog I use the option "-phi" for GCC. This is one of about three different ZPU platforms that the GCC supports out of the box. The "phi" platform puts IO ports in the "negative" address space. So for example UART input is at address 0x80000024.

    Thing is that your code, data and memory heap are growing up from zero in memory. The ZPU stack is growing down from 0xFFFFFFFF. So putting the I/O ports at 0x8000xxxx keeps them well out of the way in the middle.

    Anyway these ports are easily moved in any particular implementation of the ZPU and the C run time code is easily changed to accommodate it.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited 2010-02-19 20:15
    Bill: "there should be a way to tell gcc and the linker to have separate cseg/dseg/sseg"

    It's all done with linker scripts. I'm sure it must be possible for ZOG as that is how it is done for GCC for the AVRs.
    Problem is GCC has the most complicated incomprehensible linker scripts I have ever seen. I have yet to even find the ZPU linker scripts yet!

    Bill: "....crawl on it! (note I did not say "run" on purpose)"

    Now you are ragging on Zog. He won't be happy.

    You are of course welcome to tweak Zog. I'd like to have a go at optimizing it myself first though. As it happens Zog was tested and got running during the worst bout of flue I have had for ten years. With that fever I was not able to start thinking about anything slightly complicated.

    I have a handle on the getchar/putchar. Pretty straight forward. I even have dhrystone compiled for Zog.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited 2010-02-19 20:18
    Cluso: "What about GLMM (gigantically large memory model)"

    Great I see you are thinking about that 64bit Propeller I mentioned the other day. Let's face it we are soon going to be complaining about the 4Gbyte memory limit[noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Chris MicroChris Micro Posts: 160
    edited 2010-02-19 20:25
    >>You are not alone in that dream. That's why C was invented. That's why GCC exists.
    >>That's why I'm busy on this crazy project to get GCC for the Propeller.

    Oh, really C? is that a new programming language?

    Well, let's take this as a joke. I'm a C-Programmer since 15 years and I use the GCC with AVR-Studio for the AVR-series since 5 years.

    So, let's ask: what is the difference between programming a AVR in C or running a ZOG emulation on it?
    First let us focus on the disadvantages of such a project:
    - extreme speed loss due to the emulation
    - no direct access to the peripherals

    And now, is there any possible gain in using a ZOG?
    Yes it is: code compatibility without recompilation! ( I hate to compile source code for some programs I want to install on my linux systems and I want to have the times back when the people simply put a floppy disk into the computer an run the program without installation )
    If you create a ZOG emulator with defined interface addresses ( like I mentioned above ) and the binary code runs on every microcontroller which implemented the ZOG.

    Now you could ask: what's about java? Behind java there stands the same philosophy: creating a virtual processor so that code can run on every machine.
    My answer: The java virtual machine takes to much code to be implemented, the ZOG seems to be a simplier solution.
  • HumanoidoHumanoido Posts: 5,770
    edited 2010-02-19 20:26
    Where are the FORTRAN and C++ downloads?
  • heaterheater Posts: 3,370
    edited 2010-02-19 20:46
    OK Chris, I see where you are going with the "universal executable binary" idea.

    I could continue my last reply and start "You are not alone in that dream. That's why Java was invented...."

    But I see you have already rejected that idea for the same reasons I have.

    The ZPU architecture is much smaller/simpler hence Zog. It fits in a COG after all. Try that with Java[noparse]:)[/noparse]

    As it stands the ZPU has only ports defined for standard in, standard out and a timer. That could indeed be supported on about any implementation.

    How we extend that to cover all the interesting things micro-controllers can do is not clear to me. They are all so different. Especially as many things we use micro-controllers for require the performance that Zog does not have.

    P.S.
    In line with your thinking, in a way, I am creating a Zog in C that will run on the XMOS devices. Those devices have a similar problem with limited memory space and external RAM attachment as the Prop.

    P.P.S.
    Those of a nervous disposition should not read the previous paragraph.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • heaterheater Posts: 3,370
    edited 2010-02-19 20:55
    Humanoido: "Where are the FORTRAN and C++ downloads?".

    The ready to run binaries for GCC that are supplied by ZyLin do not support compiling C++ or FORTRAN. It is necessary to download the source release of GCC from their Git repository. Tweak the build script a bit and then rebuild the compilers from the source.

    I have done this on Linux. It can be done on Windows with CygWin.

    If you are up to tackling this I can make some instructions.

    I have only just tested Zog with C so no guarantees for C++ and FORTRAN running yet.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • lonesocklonesock Posts: 917
    edited 2010-02-19 21:01
    heater said...
    Humanoido: "Where are the FORTRAN and C++ downloads?".

    The ready to run binaries for GCC that are supplied by ZyLin do not support compiling C++ or FORTRAN. It is necessary to download the source release of GCC from their Git repository. Tweak the build script a bit and then rebuild the compilers from the source.

    I have done this on Linux. It can be done on Windows with CygWin.
    ...
    IMO MinGW would be ideal, however I'm guessing that would be a bit more difficult, even with MSYS.

    Jonathan

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    lonesock
    Piranha are people too.
  • Chris MicroChris Micro Posts: 160
    edited 2010-02-19 21:19
    >In line with your thinking, in a way, I am creating a Zog in C that will run on the XMOS devices

    That is what I planed to do with the PropEmulator ( I have a XMOS development kit which I didn't use yet). But the Zog seems to be the better way.

    >How we extend that to cover all the interesting things micro-controllers can do is not clear to me. They are all so different.
    Forget about "to cover all". It is sufficient to "cover" the most essential.
    Probably there is a common basis which the most microcontroller have:

    - serial port
    - digital I/O
    - analog out
    - analog in
    - system time in usec

    when this elements are covered the Zog would be very useful.
  • heaterheater Posts: 3,370
    edited 2010-02-19 21:46
    I'd kind of forgotten about the PropEmulator. Seems like an excellent thing to run on the XMOS.
    Consider that an XMOS core has 8 threads handled in hardware. Those threads are totally deterministic (***) and they have access to shared RAM. An excellent place to run a Prop simulation with 8 COGs. Might want make use of the XMOS timer features to ensure the shared RAM is accessed in "round robin" HUB fashion.

    (***) Sadly the XMOS execution of it's threads is NOT totally deterministic. I would like to think that with say 8 threads running the execution speed of a particular thread is in no way affected by what the other threads are doing and that each thread gets an equal share of cycles in "lock-step". XMOS fails here because:

    a) Divide instructions take more clocks. If a thread does a divide the other threads stutter.
    b) If the other 7 threads in our example terminate. Then the remaining thread is suddenly running at full core speed.

    Bottom line is that if you want timing determinism on XMOS you cannot rely on instruction cycle counting like on the Prop you have to make use of the XMOS timers an such.

    Oh wow, way off topic....

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Bill HenningBill Henning Posts: 6,445
    edited 2010-02-19 22:43
    If my special secret sauce plan works, on hits it will be on average 8 cycles per instruction slower regular LMM, ie 26 cycles per single long instruction vs. 18.

    Misses will involve a delay while a 256 byte page is loaded, which depends on what it is loaded from (SPI RAM, I2C eeprom, SD etc)

    My best WAG is that VLMM will have over 98% hits, and run (overall) at >1/2 speed of LMM with a 16KB working set. Your mileage, and WAGs, may vary. It will be possible to measure number of hits and misses empirically.

    Note: VLMM is a paper design at the moment, but I will start on it after VMCOG is running.
    jazzed said...
    Bill, how fast is your VLMM kernel on hits and misses?
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • Bill HenningBill Henning Posts: 6,445
    edited 2010-02-19 22:47
    Don't laugh too hard...

    Later I may do a 4GB virtual -> 2Mb physical VLMM, using a 4GB SDHC card and 2MB working set on Morpheus. I'd reserve 512KB for the frame buffer, and use all the memory on a Mem+ for the working set.

    I can do it, it is just a matter of can I afford to spend the time on it?

    It may be worth doing for something like Zog instead of regular VLMM.
    Cluso99 said...
    Bill: What about GLMM (gigantically large memory model). I thing that's the pc model LOL
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • Bill HenningBill Henning Posts: 6,445
    edited 2010-02-19 22:52
    I was hoping you'd do the first run at optimization, with me giving sage advice (ie ribbing) from the sidelines.

    I am overloaded with projects right now anyway!

    I was not ragging on Zog. I was actually ragging on GCC. See various threads about how much faster LCC and other compilers compile.

    With all optimizations, I think Zog can hit 1MIPS - 32 bit MIPS. That was the goal for the 3M project that led to the Xerox Star...

    Sorry to hear about the flu!

    Excellent re/ Dhrystone, will be a great way of seeing the effect of optimization (and different memory strategies). Later, look at the old Byte benchmark suite. It could even be used to compare Zog/ZiCog/MotoCog/Catalina/ICC etc...

    Now that you have a start on stdin/stdout, it might be worthwhile to think about stderr and ioctl()

    ioctl could be used as a generic escape mechanism for interfacing to other drivers and hardware...
    heater said...
    Bill: "there should be a way to tell gcc and the linker to have separate cseg/dseg/sseg"

    It's all done with linker scripts. I'm sure it must be possible for ZOG as that is how it is done for GCC for the AVRs.
    Problem is GCC has the most complicated incomprehensible linker scripts I have ever seen. I have yet to even find the ZPU linker scripts yet!

    Bill: "....crawl on it! (note I did not say "run" on purpose)"

    Now you are ragging on Zog. He won't be happy.

    You are of course welcome to tweak Zog. I'd like to have a go at optimizing it myself first though. As it happens Zog was tested and got running during the worst bout of flue I have had for ten years. With that fever I was not able to start thinking about anything slightly complicated.

    I have a handle on the getchar/putchar. Pretty straight forward. I even have dhrystone compiled for Zog.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • Cluso99Cluso99 Posts: 18,066
    edited 2010-02-20 02:50
    heater: Try and use the SphinxOS mechanism for the StdIn, StdOut etc as it decouples the I/O so that we can substitute where it goes.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • heaterheater Posts: 3,370
    edited 2010-02-20 07:08
    Optimizations or other progress on Zog will take a back seat again for a week or so as I get back to real work.

    GCC may compile more slowly than others but who cares? For the small Prop sized programs we are dealing with they all compile in an instant on a modern PC. I must admit rebuilding my C++/Qt projects is becoming a drag though and they are not so huge.

    What we need is execution speed, on the Prop, in the compiled result. Zog may hit 1MIP if we try hard enough but we still have to face the fact that it is a stack based machine which looks like it needs more instructions to the same work as other architectures. Plus the lack of registers leading to more memory accesses. ZIPS == MIPS ? true : false;

    I have the whole BYTE Unix Benchmark suite here since a couple of days ago. Only Dhrystone compiled so far.

    Not sure about the stderr and ioclt stuff. The C run time IO supplied with ZPU GCC does end up in read_byte/write_byte functions for the UART console I/O. It has some file open/close etc stuff which are basically stubs that don't do anything. Needs a little looking into.

    Cluso: I have yet to look at SphinxOS but that sounds like an excellent idea.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Cluso99Cluso99 Posts: 18,066
    edited 2010-02-20 07:52
    re Sphinx: You just treat it like an FDX/TV/KBD object...
    stdo.out(ch)
    stdo.hex(ch,8)
    stdo.dec(ch)
    stdo.str(string("xyz",13))
    and
    ch:=stdi.rx
    etc. The drivers are resident, so you just use a simple stub driver that knows where the buffer is in hub. It's really simple.

    I have attached the StdIn & StdOut calling objects for you to look at (not many lines)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · 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
  • heaterheater Posts: 3,370
    edited 2010-02-20 13:55
    Zog v0.4 out now. See first post.

    V0.4 just adds a primitive UART output such that the C run time library function outbyte() works.
    The C test program has been changed so that Zog prints a hello message to the console.
    Single stepping is not switched on as delivered. Look for #define SINGLE_STEP.
    I added a Makefile to build the test program binary load image from test.c

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
    677 x 492 - 51K
  • Cluso99Cluso99 Posts: 18,066
    edited 2010-02-20 14:29
    Nice work heater smile.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • jazzedjazzed Posts: 11,803
    edited 2010-02-20 16:15
    heater said...
    Zog v0.4 out now. See first post.
    ....
    Works great [noparse]:)[/noparse] Thanks for the Makefile.
  • Bill HenningBill Henning Posts: 6,445
    edited 2010-02-20 17:40
    I know what you mean... VMCOG has to slow down for approx. two weeks for the same reason.

    I think at 1 MIP it will be usable for a LOT of applications, and when more speed is needed, pasm in a cog should do [noparse]:)[/noparse]

    Let's not forget that there will be an instant 8x increase in speed on the Prop2 (whenever it arrives), and with the new indexed hub addressing modes and cog indexing the ZOG interpreter can probably get another 1.5x to 2x speedup ... this means we will be looking at ZOG running at somewhere between 8 to 16 MIPS!

    Even if it will be a bit slow, it will be setting up an infrastructure for running much faster later.

    More of the Unix benchmarks will run as the infrastructure gets built up (stdio, file i/o etc).

    One interesting thought... gcc will be able to compile the C fat libraries, so potentially file system handling can be done in ZOG code, with only the lowest level readsector/writesector being in pasm.

    Why would this be good?

    Because all the FS code would be in the VM, automatically swapped in/out as needed!
    heater said...
    Optimizations or other progress on Zog will take a back seat again for a week or so as I get back to real work.

    GCC may compile more slowly than others but who cares? For the small Prop sized programs we are dealing with they all compile in an instant on a modern PC. I must admit rebuilding my C++/Qt projects is becoming a drag though and they are not so huge.

    What we need is execution speed, on the Prop, in the compiled result. Zog may hit 1MIP if we try hard enough but we still have to face the fact that it is a stack based machine which looks like it needs more instructions to the same work as other architectures. Plus the lack of registers leading to more memory accesses. ZIPS == MIPS ? true : false;

    I have the whole BYTE Unix Benchmark suite here since a couple of days ago. Only Dhrystone compiled so far.

    Not sure about the stderr and ioclt stuff. The C run time IO supplied with ZPU GCC does end up in read_byte/write_byte functions for the UART console I/O. It has some file open/close etc stuff which are basically stubs that don't do anything. Needs a little looking into.

    Cluso: I have yet to look at SphinxOS but that sounds like an excellent idea.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • Bill HenningBill Henning Posts: 6,445
    edited 2010-02-20 17:41
    NICE!
    heater said...
    Zog v0.4 out now. See first post.

    V0.4 just adds a primitive UART output such that the C run time library function outbyte() works.
    The C test program has been changed so that Zog prints a hello message to the console.
    Single stepping is not switched on as delivered. Look for #define SINGLE_STEP.
    I added a Makefile to build the test program binary load image from test.c
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • heaterheater Posts: 3,370
    edited 2010-02-20 18:49
    Bill, you just reminded me of the "magic 3Ms" (1 MIP, 1MB RAM, 1 MegaPixel monochrome display) as was talked about for workstations years ago. www.cs.bris.ac.uk/history/

    We have a little work to do!

    I'm not hanging on for the Prop II. All that extra speed and memory spoils the challenge[noparse]:)[/noparse]

    I've already tried compiling this FAT code elm-chan.org/fsw/ff/00index_e.html no problem.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Bill HenningBill Henning Posts: 6,445
    edited 2010-02-20 21:06
    Yep, the old 3M proposed standard...

    Well, Morpheus can have much more than 1MB, and I could easily make a 1.2Mpixel mono driver (1280x1024) for it... and with two Props, it has far more than 1MIP [noparse]:)[/noparse]

    I know what you mean about waiting for Prop2 :-(

    Personally, I have a bunch of Prop1 designs in the pipeline smile.gif including one specifically designed for VMCOG emulations.

    VERY cool re/ FAT code compiling...
    heater said...
    Bill, you just reminded me of the "magic 3Ms" (1 MIP, 1MB RAM, 1 MegaPixel monochrome display) as was talked about for workstations years ago. www.cs.bris.ac.uk/history/

    We have a little work to do!

    I'm not hanging on for the Prop II. All that extra speed and memory spoils the challenge[noparse]:)[/noparse]

    I've already tried compiling this FAT code elm-chan.org/fsw/ff/00index_e.html no problem.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    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
  • heaterheater Posts: 3,370
    edited 2010-02-20 21:34
    Just playing around here but I can't get printf to work with Zog.
    But there is a "print" function in the supplied libs that goes straight out to the UART port so that works.
    Moving on from there, "sprintf" works into a string which can then be output with "print".
    BUT trying to use sprintf with a %d immediately blows the binary up to something that will not fit in HUB.

    Conclusion:
    1) printf is probably looking for a stdout handle or such which is not set up.
    2) Time to move into external memory with VMCOG. (On my TriBlade)

    Just now playing with FIBO. Any idea where the Catalina FIBO results are posted.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • jazzedjazzed Posts: 11,803
    edited 2010-02-20 21:40
    I see the UART works with an address which is a good start. Any chance you can provide a cognew/cogstop interface with a similar method? There are several drivers in the OBEX that could benefit. I have the VGA driver compiling (GNU doesn't like 0b.... notation) but can't test without an interface.
  • heaterheater Posts: 3,370
    edited 2010-02-20 21:54
    Well I could create a cognew/cogstop interface in a similar way but what am I starting and stopping?
    I guess I don't get what you are aiming at, are these C objects you are talking about?

    Actually I'm wondering about what to do about the whole I/O business. The ZPU uses memory mapped I/O which means you have to check every memory access to see if it into I/O space. This is a serious time waster. Just now I only check accesses when reading/writing LONGS. Not during any PUSHEs or POPs. But still it pains me to have to do that.

    Ideally I'd like to add I/O instructions to the instruction set. The ZPU developers don't like that idea for there baby but we might have to go it alone a little bit here in the name of efficiency.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • jazzedjazzed Posts: 11,803
    edited 2010-02-20 22:03
    heater said...
    Well I could create a cognew/cogstop interface in a similar way but what am I starting and stopping?
    I guess I don't get what you are aiming at, are these C objects you are talking about?
    Yes, they are C "objects" ... have a look. All we need is a cognew/cogstop interface. The memory access is managable from C.
  • heaterheater Posts: 3,370
    edited 2010-02-20 22:10
    Point me at an example for consideration.

    Presumably if those objects do anything useful on the Prop they already have interfaces to Prop features, like pins, timers, video, cognew, cogstop, some means of passing data to other COGs through HUB RAM etc.

    Zog has none of that at the moment.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Bill HenningBill Henning Posts: 6,445
    edited 2010-02-20 22:28
    sprintf probably pulls in libc, thus the bloated binary.

    I agree with jazzed re/ cognew and cogstop... and I agree with you about I/O instructions, as memory mapped I/O in this context causes a performance hit.

    How about adding just one special instruction: SYSTEM

    C prototype:

    int system(int vector, arg1, .. argN)

    Example:

    #define _halt  0x00
    
    #define _readb 0x01
    #define _readw 0x02
    #define _readl 0x03
    #define _writeb 0x04
    #define _writew 0x05
    #define _writel 0x06
    
    #define _putch 0x11
    #define _getch 0x22
    
    ...
    #define _cogid   0x40
    #define _cognew  0x41
    #define _cogstop 0x42
    ...
    #define _SD_init  0x50
    #define _SD_stat  0x51
    #define _SD_read  0x52
    #define _SD_write 0x53
    
    #define halt() system(_halt)
    
    #define rdbyte(hubaddr) system(_rdbyte,hubaddr)
    #define rdword(hubaddr) system(_rdword,hubaddr)
    #define rdlong(hubaddr) system(_rdlong,hubaddr)
    
    #define wrbyte(hubaddr,val) system(_wrbyte,hubaddr,val)
    #define wrword(hubaddr,val) system(_wrword,hubaddr,val)
    #define wrlong(hubaddr,val) system(_wrlong,hubaddr,val)
    
    #define putch(ch) system(_putch,ch)
    #define getch() system(_getch)
    
    #define cogid() system(_cogid)
    #define cognew(driveraddr,par) system(_cognew,driveraddr,par)
    #define cogstop(id) system(_cogstop,id)
    
    



    and so on... giving a complete escape mechanism for any type of messaging, driver loading etc needed.

    Note the (rd|wr)(byte|word|long) for giving raw hub access!

    Also note this gives easy access to Spin objects via hub transfers, adding cnt, locks etc becomes easy.

    Heck, it allows adding extra operations written in spin!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
    Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
    Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
    Las - Large model assembler Largos - upcoming nano operating system
  • jazzedjazzed Posts: 11,803
    edited 2010-02-21 04:30
    heater said...
    Point me at an example for consideration.

    Presumably if those objects do anything useful on the Prop they already have interfaces to Prop features, like pins, timers, video, cognew, cogstop, some means of passing data to other COGs through HUB RAM etc.

    Zog has none of that at the moment.
    In the "ICC model" device drivers are written by users rather than have the kernel add the devices. There are gives/takes between that and Ross' Catalina model. In some ways I like the Catalina model best since some things can be done with smaller spin code. Somewhere a happy median can be achieved.

    I'll post an example for you in the morning; it will be essentially the C VGA example form OBEX with 0b... replaced with 0x... numbers, and have stubs for things like wordfill, wordmove, and cognew/cogstop. The code is mostly generic and works with ICC although it is a little "fat" for one library file. The propeller.h file used in ICC provides wait***, locks, and other interfaces via propeller asm (pins are mapped to the cog addresses in the LMM kernel).

    I like Bill's system HAL model since that would be more friendly to simulations, etc.... Of course the smallest possible impact on ZOG's kernel is very important. I prefer a performance method to do system stuff like a special opcode or something from your imagination. The UART device model you added is I guess in retrospect inefficient, but i thought you were at least a little happy with it since you used it.

    You remember the soft interrupt idea from BIOS and DOS (or something older ... I'm too young at 50 and too focused in other areas to know better). I don't know how that's done, but an opcode would provide a less intrusive method on code performance than memory address decoding.

    Whatever you decide is fine by me of course. I was just thinking about how easy it has been for others to add something new to ICC in that model. Code quality/control may be harder, but at least one person doesn't have to do everything.
Sign In or Register to comment.