View unanswered posts | View active topics It is currently Tue Mar 19, 2024 3:52 am



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

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
FMTK - Is the Finitron Multi-Tasking Kernel

A project in the works. Currently the only thing that works is time-slicing between different tasks. It is possible to manage tasks dynamically with StartTask, ExitTask, and KillTask system calls.
The kernel fits into about 4kB of code, code includes a simple scheduler and messaging system.
Written in assembler for the RTF65002.

It supports
2048 Mailboxes
8192 Outstanding messages
and 256 Tasks

The first test of the messaging system failed :(
Sleep() doesn't work properly.

I'm unlikely to ever get it finished, but it's started.

I've been studying code from other operating systems like MINIX and Linux.

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


Sun Apr 20, 2014 7:08 am
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
Sounds interesting! Is it time-slicing under interrupt control, or by cooperative yielding?
Cheers
Ed


Sun Apr 20, 2014 9:06 am
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
BigEd wrote:
Is it time-slicing under interrupt control, or by cooperative yielding?


It's both sort of. It's pre-emptive interrupt driven. There's a 100Hz timer interrupt that is used at half rate (50Hz) to preempt tasks and reschedule them. However, in theory one can also call Sleep() from a task to cooperatively yeild. Scheduling is priority based, so if a high priority task is running, the timer interrupt could end up returning to the same task (if there aren't any other tasks running at the same priority). It should be possible to run without a timer interrupt if Sleep() is called, but I haven't tried it that way yet. Thre is also an entry point into the scheduler via interrupt #2. So that could be used in a cooperative fashion as well.

The first messaging test is working now. It repetitively displays a message "Hi from sender" :)

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


Sun Apr 20, 2014 10:23 am
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
Thanks - will follow this with interest.


Sun Apr 20, 2014 10:58 am
Profile

Joined: Tue Dec 31, 2013 2:01 am
Posts: 116
Location: Sacramento, CA, United States
robfinch wrote:
... It supports
2048 Mailboxes
8192 Outstanding messages
and 256 Tasks

Right on ... how big are your mailboxes?

Quote:
I'm unlikely to ever get it finished, but it's started.

It lessens my own self-loathing to hear that I'm not the only one with this problem.

Quote:
I've been studying code from other operating systems like MINIX and Linux.

I don't know a lot about Minix, but I was very impressed with the few details that I learned through casual browsing. It is a subject on my "gotta know more" list.

Mike


Sun Apr 20, 2014 3:34 pm
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
barrym95838 wrote:
how big are your mailboxes?


The mailbox is 12 words (48 bytes in size - quite small), so I blew 98304 bytes on mailboxes. The mailboxes can queue any number of message or tasks as they just store the head/tail of a linked list of those items. The default is to queue only eight messages though, so that if there's a message overrun the messages are returned back to the message pool. Otherwise a task that isn't responding to messages could chew up all the messages in the system. Some of the system alloments need to be tuned yet.

barrym95838 wrote:
I don't know a lot about Minix, but I was very impressed with the few details that I learned through casual browsing. It is a subject on my "gotta know more" list.


There's a thread on MINIX vs Linux in comp.arch that was interesting reading. Another OS I've had a look at is MMURTL. I bought the book on it. It's 386/486 based.

barrym95838 wrote:
robfinch wrote:
... It supports
2048 Mailboxes
8192 Outstanding messages
and 256 Tasks

Right on ... how big are your mailboxes?

Quote:
I'm unlikely to ever get it finished, but it's started.

It lessens my own self-loathing to hear that I'm not the only one with this problem.

It isn't the destination so much as the journey we undertake. I find many things never get finished, just perhaps presentable.

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


Sun Apr 20, 2014 5:10 pm
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
The FMT kernel has been updated to use hardware semaphores to protect kernel data structures.
AND now interrupts are enabled 100% of the time (excepting for about a dozen instructions in the timer ISR).
The interrupt response time should be pretty good. Previously, the kernel disabled / enabled interrupts all over the place, with possibly hundreds of instructions running with int's off in some cases. This would make the interrupt response time poor.
The hardware semaphores also allow for multi-processor operation.

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


Mon Apr 21, 2014 7:06 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Work has been started on another version of FMTK for the FISA64 processor. I hope to be able to reuse some of the code from the RTF65003 project. FISA64 organizes memory into 64kB lots. An entire lot is assigned to each task for holding FMTK information. It's called the base lot for the task. Included in the lot is the initial stack (2k), the virtual screen buffer (12k), register save area (1k), and a program startup area. Also included will be an area for environment vars. 256 base lots are supported and another 1792 lots are available in the system.

The FMTK scheduler will need to be modified to support multiple (2) processors. The trick will be how to handle I/O requests from one processor to the other, since only CPU0 supports I/O. Hopefully calls to API functions will look the same from both processor's point of view.

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


Tue Mar 24, 2015 7:05 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Porting FMTK over to a RISCV similar platform called Petajon.
Just modified the OS so that the one and only place a task switch occurs is during the time slice interrupt. It used to be that the sleep() function could also cause a task switch. Instead the sleep() function now waits for a task switching interrupt, using the wfi instruction. One complication is that any interrupt could cause a wakeup from the wfi instruction. So, the task status must be checked to make sure it’s actually ready, otherwise there’s a loop back to the wfi to wait some more. What’s really desired is a wait for a particular interrupt cause. I’m tempted to add a custom instruction that waits for the correct cause code in addition to an interrupt.
Code in the sleep() function looks like:
Code:
 .wait:
   wfi
   ldbu   $t2,TCBStatus[$s1] ; get the status
   and   $t2,$t2,#TS_READY ; make sure it’s ready
   beqz   $t2,.wait

I have the wait for interrupt (wfi) instruction tied to a clock gate for the core. So, when a wfi is executed the core goes into low power mode (clock stopped) until an interrupt occurs.
The OS is also now multi-tasking for only user level code. It’ll only switch between user tasks. Interrupts and exceptions are handled in the current user task, but they have their own register set available. There is a separate stack for interrupts and exceptions.
I also modified the OS so that nested exceptions can occur up to depth of three. This allows the OS code to be interrupted. Or it allows the OS code to call a BIOS function, or other OS function. There’s a separate integer register set available to each level of exception.

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


Thu Feb 13, 2020 4:37 am
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
> Just modified the OS so that the one and only place a task switch occurs is during the time slice interrupt.

Interesting - that seems like a step backwards, as much of a timeslice might be wasted. Is this for simplicity, or because something wasn't working well?


Thu Feb 13, 2020 6:34 pm
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Quote:
Interesting - that seems like a step backwards, as much of a timeslice might be wasted. Is this for simplicity, or because something wasn't working well?

I forget the reason there’s no swap in sleep. It may have been for debugging. It seems like a bad idea to have changed it; it must have been late a night. Anyway, I changed it back so I’ll find out why :) The wfi instruction should be used when there’s no task ready to run, meaning everything is waiting for externals events. The wfi’s been placed in the SelectTaskToRun() function now.
The system runs now to the start message which is coming out garbled in the wrong color on-screen. Also the cursor position isn't updating. It looks like an I/O interface issue.

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


Fri Feb 14, 2020 4:01 am
Profile WWW

Joined: Mon Apr 01, 2019 1:17 am
Posts: 3
Quote:
The mailbox is 12 words (48 bytes in size - quite small), so I blew 98304 bytes on mailboxes. The mailboxes can queue any number of message or tasks as they just store the head/tail of a linked list of those items. The default is to queue only eight messages though, so that if there's a message overrun the messages are returned back to the message pool. Otherwise a task that isn't responding to messages could chew up all the messages in the system. Some of the system alloments need to be tuned yet.

Does a write to a "full" mailbox block the calling task? Can the caller decide to use a blocking/non-blocking call to a mailbox write operation?

In some operating systems message queues are used to implement the semaphore functionality (because they don't have it directly), but it would be interesting if there is a semaphore concept either. This would be easier to implement consumer-producer task, like I/O drivers an so on.
I'm not talking about the hardware semaphores, you mentioned already, but counting semaphores at task level.


Fri Nov 06, 2020 8:53 am
Profile WWW

Joined: Mon Oct 07, 2019 2:41 am
Posts: 581
Why use the main CPU for I/O?
All the big machines like IBM 360 had some sort of smart data channels to do all the grunt work.
Unix/Minix all developed on small machines, so the I/O model is designed that way.
Ben.


Fri Nov 06, 2020 6:48 pm
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
(Hi J.E.E.K! I'd say welcome but I see you've been lurking for a while...)


Fri Nov 06, 2020 7:01 pm
Profile

Joined: Mon Apr 01, 2019 1:17 am
Posts: 3
oldben wrote:
Why use the main CPU for I/O?
All the big machines like IBM 360 had some sort of smart data channels to do all the grunt work.
Unix/Minix all developed on small machines, so the I/O model is designed that way.
Ben.

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.

BigEd wrote:
(Hi J.E.E.K! I'd say welcome but I see you've been lurking for a while...)

Hi BigEd, I think I know you from 6502.org, right?!
Yes, I did lurking so far. ;)


Sat Nov 07, 2020 11:13 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 25 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: No registered users and 1 guest


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