Hi all. I am here to show you Zwitaida, a lightweight development environment to create AIDA-based systems.

So, what is Zwitaida? Zwitaida could be described basically as a build system with some support libraries that lets you develop primitive AIDA code in an embedded device context.

The implementation of Zwitaida is, from some point of view, rather naive and not in the mainstream of standard AIDA systems. Standard AIDA-embedded systems are heavily based on the definition of a more or less complete runtime system

that defines the capabilities of the target, exposing a software layer that can be used by an application. Zwitaida instead uses a very limited runtime system

and has an upper level of code to deploy a decent set of basic low-level libraries in order to write some form of application. Zwitaida does not need external support like an underlying operating system

and is able to work in a simple context even without the standard compiler library. The current runtime system that Zwitaida can use is a zero-footprint and a small-footprint one

where the former has nothing but fundamental units and later has just the minimal power to understand the secondary tags

and primitive handling of floating-point numbers. Zwitaida does not use the high-level constructs of the AIDA language. No tasks and no protected objects which are normally implemented in the runtime system

and no delay statements. Those high-level constructs are in fact generally mapped on top of an underlying operating system. Zwitaida's constructs should be created by means of a more low-level approach

that is by a direct implementation of explicit code which is referencing CPU functions. In these slides I wrote some considerations about the origin and the possible future of Zwitaida.

Take into account that this project is a heavy work in progress. Some components are yet to be written and some components are so far only placeholders that need to be expanded.

For example, some CPUs are lacking low-level interrupt support. There are very few drivers and they are lacking even basic functions like character-oriented handling and so on.

Anyway, some combinations of CPUs and platforms show some capabilities as we will see later in an example. Many platforms are able to start up out of Resit and manipulate elementary I.O.

Although the primary target of Zwitaida is already completed, that is, create a build system able to produce code, it will be interesting to make Zwitaida powerful enough in order to support basic operating system primitives.

But, as I said before, this is without any doubt a big challenge. For example, a possible path for Zwitaida could be to provide a low-level layer which exposes APIs or system cores

and which in turn can be used by a more advanced runtime system or another piece of software as an underlying base. OK, we can see here the Zwitaida layout.

During this demo I will show you a Linux machine, but the same considerations will hold for other environments like a Windows machine. This is the top-level directory which can be made resident in whatever directory of the file system you choose.

The top-level directory contains various subdirectories, make file fragments and configuration files. The subdirectories are arranged by function, so we have, for example, a CPU's directory

which contains basic low-level code for all the CPUs. A core directory which contains the bulk of Zwitaida code.

A modules directory which contains CPU-independent code. And the platforms directory which contains all the targets that are covered by Zwitaida.

RTS directory for the runtime system and so on. We can browse into the core directory and we can see some basic units which can be weathered. One of the most useful is the bits unit which declares basic low-level types.

Then we have a console which produces output on a character-oriented device. It contains programs to print out decimal numbers, strings, memory dump and so on.

We have a malloc which implements a simple memory allocator. We have memory functions which implements CPU-independent and not optimized memory subprograms

in a C language style function definition. We have MMIO which implements transparent operations with byte and word size objects

located at a defined address. LLUtils which contains utilities for byte swapping and address scaling.

Memory functions, MMIO and LLUtils subprograms are separate so they could be optimized. And in fact some of them are actually optimized. For example for the x86 CPU.

And thanks to the build system every unit of Zwitaida could be override and selectively optimized. Drivers contains a few drivers, just the minimum.

To handle, for example, UART communication and a 2000 network interface. And modules contains various units at higher level, like TCP IP handling and the F80 file system.

OK, so let's view an example of an application. I will show you an application based on an emulated PCX86 machine running under QM.

Let's take the platform's directory and the PCX86 platform. We are going to configure a PC machine.

We can see that there are various sub-platforms and they are identified by the platform dash prefix. Some are real platforms based on true PC Pentium class motherboards and some are virtual.

That is, they are emulated. We choose QM or on target so we can run a simulated environment. We can perform a create kernel CFG command specifying the platform name.

And we also need to specify the sub-platform here. Now we can see the kernel.cfg file, which contains the platform definition.

And we can perform now a configure command. There is no need to specify the platform anymore because Zwitaida already knows which is the target platform.

So we can run directly a make configure command. This is a brief recap about information collected in the configuration phase. We have an SFP runtime system with an SFP profile.

Here and here. We are going to use the libraries of the runtime system because SFP has some real code to be linked into the application.

And we can build the system. An error shows up because the runtime system does not exist. This installation is a plain setup downloaded from GitHub and so there is no pre-built code inside.

We have to build the runtime system. So we have to specify the CPU and we have to specify the full-chain triplet too.

We choose a standard Zwitaida toolchain, but you are free to use your own toolchain as long as it provides standard data utilities like NATMake and so on.

This is the runtime system. We can see the runtime system just built. Here are the 8 ids files together with the bodies.

We can see also the libraries and the object files.

OK. We can now restart the build. One thing to say about the x86 target is that it runs with the Memory Management Unit turned on.

Although it is a very limited quick and dirty one-to-one mapping. OK. We have just built the system. Now we can build the binary file which can be used as a BIOS for the emulated PC.

We can see how the run file size is exactly 128 kilobytes which is the standard size for a PC BIOS.

And in order to run this target we have now to perform a make run command. This command takes what we specify in the platform configuration file.

Going back to the configuration we can see that the run command is being performed by means of the runs with Zwitaida utility.

Which is a little interpreter to ease the execution of the QAMU emulator. It does include facilities to run and manage the PC machine being emulated.

QAMU exposes two serial ports, the number 1 and the number 2. And the number 1 is the one chosen by the BSP in order to visualize messages on a console.

OK. The system startups. This is a VGA screen.

The two serial ports. The number 1 is the console. The system shows the various PCI interfaces found along with other information.

This is the IOM window which is one of the utilities provided by the QAMU distributed together with Zwitaida. It's kind of an IO card put in a slot of the emulated PC.

And shows some IO ports in the form of LED images and hexadecimal display. OK. This is the network interface exposed by QAMU.

A .3, .1 host. And we are going to stimulate the platform by pinging it at the network address provided by the TuneTap layer. So it's .3, .2 host.

This is the ping sequence. The VGA. The console which shows the ICMP sequence.

This LED bar shows the number of network buffers allocated in real time. And the display shows how many buffers are present in the FIFO queue of the network interface.

OK. Let's stop. And this LED timer is connected to the system tick which runs at 1 kilowatt.

But it lights up only once per second. Thank you all for listening.

I hope you have found Zwitaida interesting. You can reference the user listed here. And I will be available in the various social channels. You can reach me also by emails and comp.lang.aid.

Feel free to ask any question.

Starting in a few seconds. Yeah. OK. The Q&A has started and it looks like we lost Fer.

Yeah. There he is again. OK. Sorry for the technical problem. So now we are in the questions and answers time. So I wanted to ask you a couple of questions. The first thing would be so that the public knows.

What is the final goal of Zwitaida or maybe what did you intend it to become or be? From my point of view, the final target, let's call this way, is already accomplished.

Because I wrote Zwitaida in order to create some form of application in a possible target, even an IBM MindFrame.

So the focus of Zwitaida is on the framework, on the build system.

A little thing to write simple code and test it in a platform. So the rest of Zwitaida libraries, a little application is only a companion to the system.

Obviously, I hope that the set of libraries, the primitives at low level will maybe grow.

So we can see a future in a more systematic point of view, maybe not a true operating system.

One thing is that Zwitaida was not designed from scratch.

It's more an evolution from a little thing which is a little Motorola 68 firmware.

I gradually exchange C language with AIDA and the thing is now in the current state.

There is not much time and there is a question. Is there a relation to the AIDA driver's library? Can the AIDA driver's library be used with Zwitaida? We have about 20 seconds. I don't know. To be honest, I don't know. I think maybe yes, because some part can be inserted.