Hi J.E.E.K.
IIRC sending a message does not block the caller. Just looking at the most recent code, it does not limit the number of messages that can be sent to the mailbox. Eventually the system will run out of message blocks and an error will be returned from SendMsg().

There are several versions of the FMTK code floating around on disk. The CC64 version allows a strategy to be set for queuing messages. The strategies being: a) que all messages b) que the newest N messages or c) queue the oldest N messages. When there is a limit on the number of messages queued some messages will be lost if there is not enough room. But the caller of SendMsg() is never blocked. SendMsg() might be called from an ISR. WaitMsg() is the call that blocks the caller if no message is available. It is also possible to check for a message without blocking using the PeekMsg() call.

Most recently, I have been working on a cpu core. So, I have not looked at the FMTK code recently. I hope to eventually get FMTK running on the cpu. IIRC its last state was not working yet, looping around inside the OS.

It is more the case of "Written in Assembler", that I disprove of. PDP 11 Unix all but the kernal written in C. They have had better languages out for writing OS's but they never made out in to the real world, like Simula 67. I grumble at C being revised every time IBM or INTEL comes up with a new CPU or Computer Hardware.
ADC , SBC and test Carry flag have allways been left out all High Level Languages I know of.
Enable and Disable Interupts tend to macros in C. Languages promote strange ideas like object
programming or some feature of the week. They don't make life easier for the programmer.
I can't say, Int unsigned foobar 13: bits int signed us.money.total.cents 72:bits
or List rock.groups beatles = {"john" "paul" "George" "Ringo"}.
or c = a/b if(NAN) call exit(-1)

With better hardware.

The main cpu sleeps, or runs after a timer tick or system Call.
I/O is handled in the background by little elves, not DEMONS from Hell.

The reason I don't agree with object programing you don't have objects in the first place.
You have similar data types often but you can't share them.
object car: Model A: Tank: RickShaw. they all carry people and move on roads
but very little shared data.
Ben.

Ben, and others: can I recommend starting a new thread when you have a new observation which doesn't relate to the topic in hand?

I can re-thread conversations here, as moderator, but it's not easy or clean to cut a conversation in two. Much better if the participants can recognise when they have something new to say, and start a new thread.

This thread is about FMTK, in the Kernels and Operating systems section. For a conversation about object orientation, or about I/O processors, or about what you can or can't do in assembly language, please put your thoughts into a new head post.

Might this programming model (last N or first N messages) not lead to some complications? What should a task (sender) to, if a message is not "consumed", busy-wait to get the message off? Wouldn't it better to block the sender? In terms of real-time programming the property of reliability is very important and an OS should support this without the necessity to let the programmer to decide every time how to handle an operation (say sending a message) and is possibly forced to use the same glue code around it, just to get a "safe" behavior. This just arises as an impression to me.
Yes, if the sender is in ISR context, the non-blocking paradigma is a necessary option.

In deeper cause for these questions is (and that what I originally wanted to know), if there are counting semaphores available or if this messaging mechanism could to be used to emulate the semaphore concept.

I had not planned on the OS being used in hard real-time systems. If it turns out that it can work in that environment that would be great, but it would be quite challenging to accomplish. Task switching is done in only two places, the time slice interrupt and calling sleep(). Interrupts do not switch tasks, so it is not really pre-emptive.

There is a set of hardware based counting semaphores which are part of the memory system. A single read operation can increment or decrement the semaphore by a small amount (the low order address bits are used to specify the amount) and return its current value. A write operation can be used to release or reset the semaphore. Since it is a single bus cycle, the operation is guaranteed to be atomic and there is no chance of interference from other processors. Because it is a dedicated small memory (256 semaphores IIRC) it is very fast compared to the dram.

Semaphores implemented in software rely on hardware means of atomic updates. Ultimately there is a compare and swap operation, or a set of locked loads and stores. Depending on the memory system it may not be possible to guarantee atomic operations (this is the case in most systems) even when the primitives are available in the ISA. So, I prefer a set of hardware-based semaphores.

It should be possible to emulate semaphores using messages. The SendMsg(), WaitMsg(), use a semaphore or disable / enable interrupts for access to the system lists. However, I have had trouble with the semaphores blocking operations and loop / race issues in the OS.

One difference in the messages from other systems is that three words are passed around rather than two. I am not sure this is a good design choice. I was thinking of two pointers being passed plus a command (for example to copy an I/O block). But many systems (Windows) get by with just two words. Another aspect was a desire to prevent packing fields into two words. Decoding packed fields consumes time. If all the information is available already without packed fields things can operate faster.

Hmm, that would be odd - surely every multiprocessor system has solved this, whether by snooping or by locked bus transactions?

I cannot find a recent version of the C source code for Femtiki anywhere. I managed to find some source from a few years ago.
I went to update its and its gone.
Its more of a PITA than anything else. The source code was not huge.

If I were paranoid I'd say maybe someone hacked my machine and stole it.

I do not know whether to bother working on it again or not. I'd use one of the many available OS's, if they were small enough.

Oh no, sorry to hear it. I'm a bit of an untidy person so in my case I'm as likely to have mislaid something as to have lost it outright. In the case of code, it could be on some old disk, old machine, or dusty USB stick.

You forgot about the retro computers hiding in the loft.
It is too bad version control software does not handle compilers, FPGA software or pcb layout programs like kicad.

I found a copy that's only a couple of years old. I am a bit of a pack rat. I keep multiple copies of everything. Been going by the year for the last few years, I copy projects from the previous year into the current year folder as I work on them.
I likely accidently deleted the latest folder. I am more than a little untidy.

Version control does handle files like those. I thought I had a copy in version control, but I could not find it there either.

Been working away on the OS today. Found several errors.

I had a chunk of it coded in assembler, then decided to switch to C.
Trying to modify the scheduler so that semaphore locks are not needed. This is to prevent deadlocks.

Played around with OS code mostly today (porting to Quspl3). Writing a chunk of the kernel in assembler for better performance. The task switch code is in assembler as it is otherwise tricky to do with C code using the current compiler. The code now make use of AMO operations which are planned to be in the CPU.

Changed the OS kernel from using handles to using pointers. It turns out that some of the handles were larger than 16-bits. Since they occupied a word anyways, I decided to use pointers instead. This makes the code a little bit shorter as there are fewer handle to pointer conversions. The only time handles are used now occurs when they are passed back to the user app from an OS call. It should also make debugging easier. The handles passed back to the user app are scrambled with an xor function.
Dove into writing message handling code in assembler. This is being ported over from ‘C’ code.

The kernel is 8kB of assembler code so far.
Been working on updating the assembler, and writing assembler code. Added the ability to specify register lists. Handy for the push and pop instructions.

Changed the OS so that OS functions exit with a jump back to the OSExit point instead of using the link register. It results in slightly shorter faster code as the link register does not need to be saved and restored. The OS Functions are only called by the OS system call dispatcher, so the return address is a known. This means one cannot easily jump to an OS function in the ROM. It is better to use a system call, which will save and restore registers.

Added a semaphore lock and unlock function. It check that the address of the semaphore is reasonable. Adding the semaphore unlock function caused a new instruction to be added to the CPU – the atomic clear function, which is in lieu of a compare-and-swap. Instead of a compare-and-swap it does a compare-and-clear. This is a little simpler to encode and requires less data on the bus.