Programmer's Calculator - sample app for the new SymbOS C compiler by PREVTENET

[Prodatron]

@prevtenet is currently working on a new C compiler for SymbOS. It is originally based on Alan Cox's C compiler for Fuzix. It's open source, so Prevtenet can fix bugs and can implement SymbOS-specific language features more cleanly. The compiler and libc are now stable enough that it can compile most of its own build chain to run natively on SymbOS (YES!).

The first sample application "Programmer's Calculator", which is 100% based on the new compiler, has been published by prevtenet some days ago:

You cannot view this attachment.

https://www.symbos.org/appinfo.htm?00059

The C source code (included) is clean and compact, and the result is just 11K, which is not much larger than the SymbOS Pocket Calculator written 100% in Z80.

The compiler is size optimized. Most of the compiler stages use direct POSIX calls (UNIX api), which are easier to map onto SymbOS system calls.

The compiler architecture (inherited from the Fuzix original) is interesting, it basically works by progressively simplifying the code in stages until it reaches assembly, then assembling and linking it.

[Singaja]

@Prodatron the source code makes me appreciate how SymbOS apps' API was inspired by Windows API especially the message pump. I spend a good deal of time on my uni with the latter so it itches me in the right way. I'm especially curious about this

Code Select Expand

Msg_Sleep(_sympid, -1, _symmsg); // wait for a message
Can you elaborate how SymbOS resumes the app execution flow? It's mind blowing to me, you pulled off teams of people work equivalent.

[Prodatron]

@Prodatron the source code makes me appreciate how SymbOS apps' API was inspired by Windows API especially the message pump. I spend a good deal of time on my uni with the latter so it itches me in the right way.

That's very interesting, even though I don't know much about the Windows API, but I suspect you'll always get the same results if you try to achieve the same goal.

I'm especially curious about this

Code Select Expand

Msg_Sleep(_sympid, -1, _symmsg); // wait for a message
Can you elaborate how SymbOS resumes the app execution flow? It's mind blowing to me, you pulled off teams of people work equivalent.

Thanks!

In SymbOS, a process can enter sleep mode when it is waiting for a message. In this case, it is removed from the multitasking scheduler list. As soon as another process sends a message to the sleeping process, it is reinserted and thus can check the newly incoming message. The process itself doesn't actually notice anything. It executes the "Wait for message and sleep" call once and then looks at the result.

In practice, apps usually use two different paths for their "main loop":

- those that simply have nothing else to do and are just waiting for a new event (message) enter sleep mode

- those that want to periodically control or update something while waiting for a new event enter idle mode within the main loop, which means that they give CPU time back once per loop and get it back after one scheduler cycle.

You can see this exactly in the Task Manager:

You cannot view this attachment.

Some processes are "idle" (meaning they are doing/checking something inside their main loop), some are "sleeping" (they are doing nothing, just waiting for a message and not using any CPU time at all), some are even "working" (they are currently doing so much that the scheduler has to interrupt them once per cycle).

[Prodatron]

News from prevtenet:

"Meanwhile, a milestone: the C compiler can now build complete executables start-to-finish on SymbOS!

You cannot view this attachment.

...if you can wait about 5 minutes for the compilation to finish, anyway. But from my initial profiling it looks like a large amount of time is wasted jumping through compatibility hoops in the stdio implementation, so I am guessing that with some rewrites/optimizations I can get this down to 2-3 minutes on 4 MHz"