View unanswered posts | View active topics It is currently Thu Mar 28, 2024 5:55 pm



Reply to topic  [ 25 posts ]  Go to page Previous  1, 2
 FMTK 
Author Message

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
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.

_________________
Robert Finch http://www.finitron.ca


Sun Nov 08, 2020 4:27 am
Profile WWW

Joined: Mon Oct 07, 2019 2:41 am
Posts: 585
Quote:
Did I missed anything? I'm not sure what this answer is really saying ... Is FMTK for such a beast?

Who said that I/O should be handled by the CPU? I mentioned it just as an example for a producer-consumer situation.

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.


Sun Nov 08, 2020 4:34 am
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
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.


Sun Nov 08, 2020 8:49 am
Profile

Joined: Mon Apr 01, 2019 1:17 am
Posts: 3
robfinch wrote:
Hi J.E.E.K.

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.

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.


Sun Nov 08, 2020 5:25 pm
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
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.

_________________
Robert Finch http://www.finitron.ca


Wed Nov 11, 2020 3:18 am
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
robfinch wrote:
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.

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


Wed Nov 11, 2020 8:37 am
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
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.

_________________
Robert Finch http://www.finitron.ca


Sat Feb 17, 2024 9:46 am
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
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.


Sun Feb 18, 2024 8:47 am
Profile

Joined: Mon Oct 07, 2019 2:41 am
Posts: 585
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.


Sun Feb 18, 2024 4:18 pm
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
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.

_________________
Robert Finch http://www.finitron.ca


Sun Feb 18, 2024 4:54 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 25 posts ]  Go to page Previous  1, 2

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software