Welcome to the Parallax Discussion Forums, sign-up to participate.
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.
Bill, how fast is your VLMM kernel on hits and misses?
Bill: What about GLMM (gigantically large memory model). I thing that's the pc model LOL
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.
Zog v0.4 out now. See first post.
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.
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
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.
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?
#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)
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.