another bizarre architecture

[Didi]

But the PCI bus doesn't run at GHz and has lots of overhead for a single

cycle I/O access. On the same system the minimum width of a software
generated pulse on an I/O line was about 4us.

Sounds like the delay has been down to bridging to/from
the PCI bus, PCI is much faster than that. Maximum latencies
can get large because of bus (req/grant etc.) delay, but
minimum (when the bus is free or owned) are much below
1uS.
However, for a monstrous mess like the x86 your figures
are about the best one could expect, sound quite reasonable.

Dimiter

 

[Ken Smith]

Sounds like all the treads waiting for various events are running at
the same priority level.

Not all of them have to be at the same priority for the effect to be seen.
The event just needs to pass through a thread to end up being timed at
that threads priority even if the thread waiting for that thread to finish
dealing with it is at some other priority.

On older Windows NT versions, only the tread priority levels 16, 22-26
and 31 were available in the realtime priority class, so assigning
priorities to various threads was quite tricky.

In spades.


Starting from Windows

 

[joseph2k]

As everything else, this approach has its limits.

1. Once the number of states in the state machine gets over a hundred,
the code is very difficult to manage. The dependencies are growing all
the way. Changing anything can be a pain in the butt. It is almost
impossible to verify all kinds of transitions between the states. For
that reason it is very easy to overlook something.

2. There are kinds of tasks which call for multithreading. Caching,
hashing, calculations, vector graphics and such. Those tasks can be
organized as the state machines however it is going to be messy.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

Before the time i have a 100 states in a state machine is look to "refactor"
it into multiple interacting state machines of less than 12 states each.

 

[joseph2k]

wow, I'm not the only person to have ever heard of them.

Werent they used in the microVax?

Cheers
Terry

Not at all. The 32000 was pretty much a RISC design and VAX/microVAX is a
thoroghgoing CISC architecture.

 

[joseph2k]

One of the better examples where inefficient software tools killed a
perfectly good processor.

w..

Yes and no. The software tools for embedded designs matured, but the
Micro$oft stranglehold on the desktop blocked it out.

 

[Vladimir Vassilevsky]

Before the time i have a 100 states in a state machine is look to "refactor"
it into multiple interacting state machines of less than 12 states each.

This is going to be of limited help. The small machines will have the
dependencies spreading from one to another. The preemptive multitasking
approach provides for shorter, clearer and more manageable code.


Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

 

[Vladimir Vassilevsky]

joseph2k wrote:
Before the time i have a 100 states in a state machine is look to "refactor"
it into multiple interacting state machines of less than 12 states each.

This is going to be of limited help. The small machines will have the
dependencies spreading from one to another. The preemptive multitasking
approach provides for shorter, clearer and more manageable code.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

 

[John Larkin]

This is going to be of limited help. The small machines will have the
dependencies spreading from one to another. The preemptive multitasking
approach provides for shorter, clearer and more manageable code.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

I've never done a state machine with more than maybe eight states.
There are cases where multitasking makes sense, like when you have a
report generator or serial command parser or some other slow-running
eternal task that is easier to write as classic procedural code. But
for fast bare-metal stuff, task switching overhead can be a killer,
and realtime preemption can tangle logic lots worse than state
machines.

One compromise is to have a single, main procedural task that is
periodically interrupted by a state machine dispatcher.

I've written several preemptive multitasking RTOS's, but lately,
working mostly on instrument controllers, I find I don't need them.

The real tests of an RTOS are: what's the maximum time that it ever
runs non-interruptable? And what's the context switch time?

John

 

[Terry Given]

Terry Given wrote:




Not at all. The 32000 was pretty much a RISC design and VAX/microVAX is a
thoroghgoing CISC architecture.

but IIRC it had a string compare instruction, block moves etc.

Cheers
Terry