The Zuse Elektra is a system family from Zuse Gerätebau implementing the ESER/OSER architecture (a fictionalized version of the real-life ESER; see below). Released in 1964, it has diversified into a line of mainframes, superminis, workstations and servers. The English Electric Electra is a licensed clone.
This emulator emulates a 32-bit Zuse Elektra.
- Memory is verified; all specified features work, but some implementation features need to be frozen (such as cache sizing and replacement algorithms).
- Channel units are in progress; tests and devices still need to be written.
- The Datei device needs a decent ESER test program.
- Processing units are in progress; tests need to be written and some aspects need to be frozen, such as cache sizes.
- The console needs to be expanded with commands for device control.
Run it as:
${PATH}/zuse ${Config_File_Path} ${Device_Plugin_Directory}
The config file specifies the following:
- the amount of RAM in 4K pages;
- the units, in the format k t [ p ], where
- k is the type of unit (r for processing, d for channel);
- t is the interrupt port address, in hex;
- p are the parameters for each unit.
Channel units in turn take the basename of a device plugin (either a .so on POSIX or a .dll on Windows) as the first parameter of p.
If loading proceeds without errors, you will reach the operator's console:
>> _
?
: prints the available commands along with their inputs.g
: prints the highest physical address.l $n $a
: prints n bytes located at address a.s $a $w
: writes w to address a.e
: lists active interrupt port physical addresses.an $a
: powers on the unit whose interrupt port address is a.ab $a
: powers off the unit whose interrupt port address is a.
::
: Notice.!!
: Error.??
: Bad command.
CMake is used to simplify cross-platform building; nevertheless, some platform-specific adaptations are employed to simplify the process itself. There are three main supported build types: Release, RelWithDebInfo or Debug.
In particular, don't forget to add appropriate flags for your CPU in the CXXFLAGS
environment variable, mainly for alignment. For example, one might use the following on the Intel i7-8565U:
$ CXXFLAGS="-march=native -falign-functions=64 -falign-jumps=32:4 -fno-align-loops -Wa,-mbranches-within-32B-boundaries --param=l1-cache-size=64 --param=tree-reassoc-width=4"
while the following might give the best results on the i5-1340P:
$ CXXFLAGS="-march=raptorlake -falign-functions=64 -falign-jumps=32:15 -fno-align-loops --param=l2-cache-size=12288"
Create the directory $type
corresponding to the build type.
$ mkdir $type
$ cd $type
$ CXXFLAGS="$specific_flags" cmake .. -DCMAKE_BUILD_TYPE=$type
$ cmake --build . -j$n
$ mkdir out
$ cd out
$ cmake ..
$ cmake --build . --config $type
Visual Studio debugging is experimental. In particular, passing the required arguments to programs properly under debugging is to still be figured out, as they must be launched from the IDE.
For Visual Studio with MSBuild:
- Run the CMake generation (3rd) step;
- Open
out\ESER-32.sln
in Visual Studio; - Locate the relevant project in the Solution Explorer and right-click on it;
- Select Properties (bottom) in the drop-down menu;
- Select Configuration Properties > Debugging in the left pane;
- Fill in the Command Arguments field.
For Visual Studio with Ninja, a CMakePresets.json is being considered. In the mean time:
- Open the local repository folder in Visual Studio;
- Wait for Visual Studio to generate the Ninja build files;
- Select the relevant target as startup item in the Select Startup Item dropdown;
- Go to Main Menu > Debug > Debug and Launch Configuration for <target>;
- Add the following line to each relevant target of
launch.vs.json
orlaunch.json
:"args": args
Whereargs
is as follows:- for
durchgangeinheit.exe
:["..\\lib\\prufung.dll"]
; - for
zuse.exe
:["..\\..\\..\\..\\src\\beispiel.conf", "..\\lib\\"]
- for
The emulator is written in C++11, but a C++20-compatible compiler is recommended for increased performance.
- zuse: the emulator binary;
- gerate: the device binaries;
- prf/*: the individual tests.
- speicher: tests memory, physical and virtual;
- durchgangeinheit: tests channels and some essential devices (in progress);
- recheneinheit: tests CPUs (in progress).
Install targets are being considered.
The test order is:
prf/speicher
;prf/durchgangeinheit ${Test_Device_Plugin}
;prf/recheneinheit
;- all device tests.
The test is successful if it returns normally, i.e. doesn't call terminate after throwing an exception or doesn't segfault. The tests can be run under gdb for debugging.
The principal documentation are the PDFs in doc/:
- 32.pdf: The ESER-32 specification, in English;
- de_32.pdf / ae_32.pdf: The original texts of the ESER-32 specification, in German and Ard English;
- 64.pdf: The ESER-64 specification, in English;
- de_64.pdf / ae_64.pdf: The original texts of the ESER-64 specification, in German and Ard English.
If you wish to provide a new device, just create a folder named ${Device_Name}
in src/gerat/
with a CMakeLists.txt file containing at least the following:
cmake_minimum_required(VERSION 3.18)
project(${Device_Name} CXX)
add_library(${Device_Name} MODULE
${Sources}
)
target_link_libraries(${Device_Name} PRIVATE
kern
)
compile_options(${Device_Name})
add_dependencies(zuse ${Device_Name})
Visit #ESER on Libera for any questions (9:00-23:00 UTC+1); you will need to be registered to join.
This emulator is the union of two projects:
- An example of a paged architecture with capability-based addressing, which I discovered in 2020 and wanted to do as the subject for my PhD, but never found the tutor for; and
- A Prussian computer system in an alternate history of Earth centered around the formation of Russia in the Bronze Age, the survival of the Roman Empire, an alternate technological ecosystem and a lack of consumerism and liberalism.
I do not have any shorter summary.