Zed

Release 1.2 (November 2, 2024) of the Zed Compiler and Tools.

Current Status

December 8, 2024: I've finished everything I want to do with .o files. The "zedc" standalone compiler (in the "zedcStuff" archive) takes the following flags (plus source file names of course):

New update coming in a while. I wanted to add the bytecode engine to the zedc binary so it could handle the full language, etc. I was just going to link in the C version of the code generator, disassembler and engine. That was going to be a kludge, so I thought it wouldn't take long to translate them to Zed, so that nearly all of zedc could be Zed code. Hah. I've done the code generator and tested it on everything, and also the byteswapper and disassembler. That leaves the engine itself. 6130 lines. Gonna take a while. Sorry. I also got sidetracked doing Zed versions of the unaligned accesss macros, and adding and testing optimizations to my X86-64 code generator for those.

Some notes on translating from C to Zed and Zed to C. I've done a fair amount of both ways. The original compiler was all in C (originally in Draco for my MUD system). As I progressed, I did Zed versions of much of it (didn't bother with the parser until fairly recently). I then started writing new stuff in Zed first, to get used to doing that and to have the code be "Zed-ish" code. When it was done, I translated to C. Eventually I stopped doing that, so lots of the Zed compiler is *only* in Zed. I've done a lot of writing in Zed in the last few years, and I find it quite a bit easier than C now.

Zed to C is likely something only I would ever do. It's not that bad since the syntax can mostly be done with a bunch of global-search-and-replace. I had done that with a bunch of Draco-to-C as well. C to Zed is syntactically harder because C uses the same syntactic chunks for multiple things (if/for/while/switch). Have to handle those manually. Painful. And yes, when switching back and forth, I do slip up!

Another annoying process is that of *adding* 'nonNil' stuff everywhere. If you just do it, and don't investigate anything except errors, its not bad. But, I wanted to get rid of all of the "implicit nil check inserted" info messages as well. Those can be a pain. I also wanted everything to compile with all warnings enabled. May as well *start* clean!

The Zed language and tools are fully usable at this point. However, that full usability only allows execution via the Zed bytecode engine. This is done via the "zed" binary, which is compiled from C code but includes a lot of Zed code which it runs in the bytecode engine as needed. This runs your programs considerably slower than native code execution. That binary is not yet available here - most runs require thousands of lines of internal Zed code, which needs reorganization.

Native code execution is now available, but is immature. The "zedc" binary is a compiler for Zed code which emits X86-64 .o files for use on X86-64 Linux systems. It also runs under WSL (Windows Subsystem for Linux) under Windows-11 (and probably Windows-10) on X86-64 CPUs. Created .o files must be linked using external tools and libraries. I use "gcc", and have not tried using other toolchains. "zedc" does NOT yet include the bytecode engine, and so is limited in what Zed code it can compile. In particular, it cannot compile programs using the "Fmt" or "Debug" code, and cannot create code using persistence. Similarly, programmer-defined constructs cannot yet be used under "zedc".

Full documentation on the Zed language, and the "zed" binary are included here as a VERY LARGE HTML file. Note that the original form of the documentation is a POD (Plain Old Document) file, so edits to the HTML version of it are not useful. If someone wants the POD version, let me know. My server bandwidth has been upgraded, but is still low, so please save the HTML file locally, rather than reading it incrementally from this website, and do not link to it from other websites (link to this page instead).

Let me know here if you download the docs and/or archive.

I am not currently releasing the full sources to the Zed system. There is considerable cleanup and re-organization that I wish to do first. However, the provided example sources include several major concepts. This of course means that you can't build your own version of Zed from scratch - you will have to directly run the "zed" and "zedc" binaries as retrieved from here.

You might choose to do that inside a virtual machine. I haven't directly run a virtual machine myself, but I've verified that X86-64 binaries produced by "zed"/"zedc" run under Windows-11 WSL ("Windows Subsystem for Linux"). My plan is to verify this webpage by referencing it from there and seeing if I can run everything under WSL. October 2024: Done.

Running Using "zedc"

Getting it out of the way: here is the archive (650K) of what you need to run using "zedc". It contains the "zedc" binary, the "zed.a" library, some "header" files, some goofy example programs (one is 2000+ lines), and bash scripts to compile the examples, using gcc to link them. You should be able to use any of the procs declared in "SysHdr.zed", but don't count on those staying available forever. For example, "MMap" cannot possibly be available in a secure way. See "files.txt" in the archive for more info.

The examples include 3 programs that, for fun, I translated from Draco into Zed, along with creating a "Terminal" library that creates a 24 line by 80 column green-on-black X window, and provides "termcap"-like calls to work within it. I think I first saw "Robots" as a BASIC program, in a magazine. To get "zedc" working under WSL, I used:

    sudo apt-get update
    sudo apt-get upgrade
  
to get uptodate, and then
    sudo apt-get install gcc
  
to get gcc (which includes the linker, "ld", and basic libraries). You'll also need X11-dev stuff to compile the graphical stuff.

After that, you should be able to run the "build" scripts.

Also, the games which use the numeric keypad only work for me in the initial WSL window, and not when started from an xterm after I have merged my normal setup. (Something else to chase!) If your display resolution is higher than about 2K, the windows will be too small - I don't know of an easy fix for that unless you can reduce your display resolution.