Implementing schedulers in processor????

Gurus, I am working on a consumer electronics product and creating softwares for that.The product uses ST5516 processor from ST MICRO ELECTRONICS.I was going through the ST5516 Datasheet to understand about the processor architecture. I am quite puzzled at this statement given in the datasheet and not able to realize how this could be possible to be implemented in hardware because this more of an OS concept and in my experience have seen all these stuff stated below done by the OS.But the datasheet states that these things are implemented in hardware processor.Heres what the processor document states:

"Processes and concurrency This section describes the default behavior of the CPU. Note: This behavior can be altered, for example by disabling timeslicing or installing a user scheduler.

A process starts, performs a number of actions, and then either stops without completing or terminates complete. Typically, a process is a sequence of instructions. The CPU can run several processes in parallel (concurrently). Processes may be assigned either high or low priority, and there may be any number of each. The processor has a microcoded scheduler which enables any number of concurrent processes to be executed together, sharing the processor time. This removes the need for a software kernel, although kernels can still be written if desired. At any time, a process may be:  active:

- being executed,

- interrupted by a higher priority process,

- on a list waiting to be executed,  inactive:

- waiting to input,

- waiting to output,

- waiting until a specified time. The scheduler operates so that inactive processes do not consume any processor time. Each active high priority process executes until it becomes inactive. The scheduler allocates a portion of the processor's time to each active low priority process in turn (see Section 8.4: Priority on page 82). Active processes waiting to be executed are held in two linked lists of process work spaces, one of high priority processes and one of low priority processes. Each list is implemented using two registers, one of which points to the first process in the list, the other to the last.Each process runs until it has completed its action or is descheduled. In order for several processes to operate in parallel, a low priority process is only permitted to execute for a maximum of two timeslice periods."

Now here are few couple of questions which I would like to get clarified:

1)If whats stated above happens can I take I dont need an OS to make sophisticated complex applications like for eg., develop a set box application software or may be a DVD player applications which allows users to access its features?If thats the case,how can I access these process or scheduler inorder to program them according to my product requirements?

2)How can a scheduler be implemented in hardware level in the processor?Or in other way to put,how can I realise a scheduler in the processor?

3)The last statement in the description given above(In order for several processes to operate in parallel, a low priority process is only permitted to execute for a maximum of two timeslice periods),how can the scheduler control the process like this?Because at any point of time only one process is going to have high priority.When the high priority task exits,the next task having high priority will be promoted.Taking this fact into consideration,I dont see a way how the low priority process can be assigned two time slices?Does this mean actually we can have combination of priority and roundrobin sort of scheduling algorithm for applications?(I mean ,you have one high priority and a group of tasks having same priority level whose priority value is less then the highest priority tasks priority level).

4)Is this what we term as multithreaded processor?

Looking farward for all your replys and advanced thanks for the same, Regards, s=2Esubbarayan

Reply to
ssubbarayan
Loading thread data ...

[...]
[...]

[...]

Microcoded means they have an OS, likely an RTOS, in firmware, not hardware. You have the option of booting your own OS instead of the firmware OS if you want. So it's really software, not hardware.

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.
Reply to
Joe Seigh

I'll have to disagree with you there.

According to Wikipedia :

formatting link

"A microprogram is a program consisting of microcode that controls the different parts of a computer's central processing unit"

This means that the scheduler is implemented in microcode, like a "superinstruction", making it easier to implement a RTOS.

Tom

Reply to
Tom Twist

You mean like VM or LPAR on IBM mainframes? In that case the api to the processes is the virtual machines and virtual cpus. The documentation would be hardware architecture manual and some additional configuration and control commands. But it looks like hardware. The OP talks about what sound like unix processes, not hardware execution units.

--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.
Reply to
Joe Seigh

I don't know this part and google & ST search didn't help, provide a link to datasheet please.

I did find STi5514/5516.pdf though based on the ST20 core and the datasheets are just marketing blurbs. Looks like the missing i stands for inmos perhaps and you need to sign up for real datasheets. The ST20 sheets are available though.

Most people here couldn't care less for this sort of processor so you will find little help with it.

Remember ST bought out Inmos a decade ago along with the Transputer and many of the people. The old Transputer family had a lot of hype and seemed toooo difficult for many to understand. After some dissapointment with their purchase and the miserable T9000, ST basically rewrote all the Transputer docs and removed many good features and all the Transputer sense dissapeared. What was left was a horrible looking stack machine with OS support in hw with no rational explanation for how it came to be. It did become a big player in set top boxen though. Last I heard there was a 500MHz std cell version of the core done in 03 so development must have continued.

You should visit comp.sys.transputer esp Rams site and wiki to get background info.

formatting link

You could look at occam too to get a real sense of how to program it if you can find anything that is. History is really good at burying stuff, but treasure hunters like to dig it up. Of course yours truly is building a modern Transputer for more general use in FPGA.

And yes of course the OS can be in hw but multithreaded in the OS sense not hw sense even if it is actually in hw. By the way the correct name is process but ST rewrote the docs to make it as bland as a 8051 etc.

johnjakson at usa ... transputer2 at yahoo ..

Reply to
JJ

a microprogram is a program implemented in microcode and can be pretty much anything ... but typically is targeted at provided layer between some software and "real" hardware (frequently analogous to operating systems providing a layer between applications and the supposedly real hardware).

Recently I got some email from somebody that was asked to do presentation on the *new* virtualization technology ... and they vaguely remembered some presentation that I gave in the 70s or 80s mentioning that the virtualization control program being the

*microcode* of the virtual machine.

I had done a bunch of stuff as an undergraduate in the 60s. This week in Boston, SHARE is having its 50th anniv. meeting.

formatting link

Following is part of a virtualization presentation I gave at the aug68 share meeting in boston

formatting link

One of the things I had done was a hack to the I/O interface that allowed the virtual machine to specify a special I/O operations that significantly reduced the overhead of emulated disk I/O. After I graudated and joined the science center

formatting link

I got beat around the head for violating the hardware architecture specification. The hardware architecture specification didn't provide/cover the way I had done it. It was then drilled into me that the hardware *diagnose* instruction was defined as being model specific implementation (aka undefined in the hardware architecture specification). A fiction was created for a *virtual machine* model and then a whole slew of new virtual machine specific features were implemented in microcode programs invoked by the diagnose instruction.

For the ECPS project ... the "new" 370 138/148 (not yet announced) was going to have 6kbytes of available microcode store. A detailed hot-spot analysis of the kernel was done ... and the highest used 6k bytes of kernel instruction was selected for moving to microcode. Results of that initial study

formatting link

The 6k byte cut-off represented approx. 80 percent of overall kernel cpu utilization (see above posting)/

The low & mid-range 370s ... were vertical microcode machines ... and tended to avg. 10 microcode instructions for every 370 instruction. ECPS basically defined a new *hardware* instruction for each block of kernel code migrated to microcode. The kernel software then effectively replaced the sequence of software kernel code with the corresponding new hardware instruction. In the ECPS scenario, the overall scheduler wasn't actually implemented in microcode ... but some specific pieces of the dispatching code was dropped into the machine microcode (just about on a byte-for-byte basis and achieving

10-to-one speed up).

about the same time, I was also working on a 5-way SMP project ... also involving a microcoded machine.

formatting link

for this, I migrated the management of virtual address space dispatching into the microcode. A interface was defined between the kernel software and the machine micrcode that was basically the ordered list of dispatchable units. The kernel software put work units on the list ... the microcode of the different processors took work units off the list and executed them (using thread safe compare&swap). This was akin to some of the stuff that the intel 432 was doing later on.

all sorts of past posts related to microcode

formatting link

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Reply to
Anne & Lynn Wheeler

Even with the foul google usenet interface, you can provide sufficient context for your article to make some sense. What is "this part", what datasheet, etc.? There is no guarantee any other article is visible to your reader. The instructions are in my sig, below.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson
Reply to
CBFalconer

NO, I mean that it sounds like there is a microcoded scheduler in the processor. I have not been able to find the datasheet to the particular processor, ST5516, so I'll have to take the OP's word for how it is working.

The original poster writes: "The processor has a microcoded scheduler which enables any number of concurrent processes to be executed together, sharing the processor time. This removes the need for a software kernel, although kernels can still be written if desired."

I have been involved in microprogramming AMD AM2901/AM2910 based systems, so I'm in no way unfamiliar with writing microcode. I know my Mick and Brick!

Tom

Reply to
Tom Twist

snipping

like unix processes, not hardware execution units.

Again it is a TRANSPUTER derived from the ST20 derived from the much older T400 series I guess. One can search for STi5514.pdf or STi5516.pdf but its just marketing blurb. The i was missing, maybe it stands for inmos, (probably NOT).

The scheduler and support for communicating sequential processes is in there. Search instead for ST20 there is far more detail there but its been thouroughly cleansed of all inmos speak.

Visit comp.sys.transputer esp Rams site and wiki to get background info as well as occam.

formatting link

Funny to mention that, Mick & Brick were last seen about same time as the Tranputer was designed, after all VLSI killed of bit slices along with Vaxes.

johnjakson at usa ... transputer2 at yahoo ..

Reply to
JJ

Dear all, Thanks for all your replys.If I have understood from this discussion,it seems to me that the document was speaking of the actual operating system used in it,rather then the implementation of process at hardware level as I have (mis!)understood earlier. So again it would be helpful if any of you can confirm that generally process is not implemented in hardware and its jus an OS whose process is being discussed in that document?Also I was not able to arrive at an answer for my last query in my post and it would be helpful if some one can clarify on this query too???

Looking farward for all your replys and advanced thanks for the same, Regards, s.subbarayan

Reply to
ssubbarayan

No, the h/w, using microcode, provides a scheduler. It's not a complete OS. See

formatting link

Reply to
John Whorfin

Interesting.

I had almost forgotten about the Transputer. A friend of mine designed a Transputer coprocessor board for the IBM PC.

I didn't know that ST took over Inmos.

We used bit slices in CAD workstations in a small Norwegian company called Ican. It started off as a vector drawing device, monochrome. The color raster system came in 1982, I think. We ran Unix on them from 1983. I think the bit slice based designs shipped until 1987 or so, when it was replaced with the Hitachi HD68384.

But Vaxes I have used till well past 1995.

Tom

Reply to
Tom Twist

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.