Re: [microblaze-uclinux] Re: multiprocessing

[Matthew Rubenstein <email@xxxxxxxxxxxx>]

	Greg, it looks like we've got a sanity problem, with unsync'd frames of
reference ;). I think we actually agree; I try to achieve consonance out
of the dissonance below:


On Mon, 2004-04-05 at 09:52, Greg Ungerer wrote:
> Hi Matthew,
> 
> Matthew Rubenstein wrote:
> > 	Children of fork()'ed processes inherit their parent's state, with page
> > tables managed by the MMU (unless I'm mistaken).
> 
> With a standard fork() the child gets a new virtual address space
> that looks identical to the parents (often optimized with COW, but
> that is not relevant here). It has its own set of page tables that
> hold this mapping. The "management" of page tables is done by the
> kernel, not so much the hardware. So any processes page tables are
> just a part of its "state". A child inherits a _copy_ of its
> parents page tables on a fork(). On a vfork() the child uses its
> parents page tables.

	Yes - The MMU manages the creation of the child's duplicate page
tables. Without one (or a replacement in SW/firmware), the child uses
its parent's. I might have been mistaken that the MMU is the missing
link to a viable fork()'s set of child page tables, but revisiting some
literature suggests that I'm not. Unless you know of a fork() that
results in child page tables without an MMU. But the point is that, yes,
the child has only its parent's actual state itself within which to
work.


> >  Regardless of the (lack
> > of?) the missing MMU as raison d'etre, vfork() offers only preservation
> > of parent's state, with a few volatile accesses offered from the child
> > to the parent, for write, and fewer for read, and even fewer for return
> > to the parent.
> 
> Huh?  This doesn't make any sense to me...
> What accesses are you talking about?

# man vfork [edited]
...[undefined on] any data other than a variable of type pid_t used to
store  the  return value from vfork()...

	I mean that even if the MMU isn't the reason for the availablity of
vfork(), instead of fork(), vfork() is all we've got, and that means we
don't get fork()'s full parent state, or fork()'s protection of the
parent's state from writes from a badly written or broken child, or any
facility to return data to the parent other than the PID of the vfork()
call itself (though the parent state could include a writable pointer to
allocated memory and registers which the child could use as buffers and
flags for return values). So vfork isn't as useful as fork().

	
> A child process that modifies the parent state in any way
> is broken. From the vfork() manpage:
> 
>      The vfork() function has the same effect as fork(), except that
>      the behaviour is undefined if the process created  by  vfork()
>      either modifies any data other than a variable of type pid_t used
>      to store the return value from vfork(), or returns from the
>      function  in which vfork() was called, or calls any other function
>      before successfully calling _exit() or one of the exec family of
>      functions.

	We're in violent agreement :). I just apparently distrust vfork() more
than you do, for the same reasons.


> > And there's no simulated (interleaved) multitasking; the
> > parent halts until the child terminates and is destroyed.

	On a uniprocessing CPU, like any Harvard arch, like MicroBlaze, all
multitasking is achieved through simulation of "simultaneity" of
multiple processes, using the weaker "concurrency" of execution.
Multiple "simultaneous" processes are juggled, usually round robin,
executing a few instructions from each in succession: interleaving short
sequences achieves the illusion of simultaneity, like a juggler's trick.
Parent starts, spawns child, parent halts, child executes, child halts,
parent executes, parent halts, child executes, repeat (usually
thousands/millions of cycles, and across dozens/hundreds of processes),
parent or child terminates and is destroyed (removed from memory),
remaining processes continue in their timeslices, etc.


> This is true. But it over looks the whole reason that vfork()
> was created. _Most_ programs fork() then immediadely exec()
> another. And when that exec() occurs the child builds a new
> process memory state. At this time the parent then continues -
> entering the run queue. So now we have the child and parent
> multitasking again (simulated or otherwise).

	vfork() lets you port code that fork()'s, if you revise the child not
to require its own state. I find the entire simulated multitasking I
describe above to be an inefficient hack, and like most HDL programmers,
prefer true multiprocessing. I dislike vfork(), because it's the fork();
exec() paradigm that I dislike, without even fork()'s fuller support for
the parent/child paradigm I'm still stuck with. In short, I don't like
multitasking through simulated multiprocessing: I prefer real
multiprocessing hardware, especially when I have to deal with the actual
details of the simulation.


> > All those
> > decreasing subsets of fork() offer progressively less support for
> > multitasking, which must be replaced with alternates.
> 
> There is no decreasing subset.

	I meant "decreasing" rhetorically: my order of examples in my sentence
referred to features of vfork() that have decreasing degrees of the
functionality of fork(). If you stick with the fork() paradigm, you've
got to replace the missing fork() features with your own versions. And
you're still doing it like fork(), unless you're very clever (which I
obviously am not :).


> > Building from
> > vfork(), they're usually incomplete, and set off towards the inadequate
> > starting point of fork() itself, a problematic simulation of true
> > multiprocessing.
> 
> Well, I can't say I agree with that. fork() seemes to have served
> as quite a strong fundamental primitive over the years. You can argue
> its ineffeciency with regard to spawning different programs.

	When all you have is a hammer, everything looks like a nail. I like
FPGA because of true multiprocessing (among other features). fork() has
served well enough - we're currently depending on it to correspond quite
pleasantly across an entire planet, mostly ocean (greetings from New
York City :). But programming FPGA has been much harder than programming
Harvard arch CPUs, with fewer tools, and no instances of the old
environment (OS/shell) executing in the FPGA itself. Until MicroBlaze.
Now that we've got one eye, everyone else starts to look blind. And
that's the way to become king ;).


> > 	So I am happy that with MicroBlaze/uCLinux, we've got the
> > hardware/flexware/OS platform for true multiprocessing in a familiar
> > (GNU/Linux) development/execution environment. And without the tempting
> > distraction of fork(), the effort to port down the same old wrong road
> > starting with vfork() competes with the true path of dynamically
> > retrieved (or generated) logic in parallel hardware.
> 
> I still don't see it. Having the ability to reconfigure the compute
> engine on the fly seems powerful, but I don't see how it will ever
> negate the need for something like a fork. Except maybe for the
> narrowest of compute tasks. But then that is nowhere near as 
> interresting as what we might be able to do with more general systems.

	Well, reconfiguring MicroBlaze on the fly is about as interesting as
"reflexive programming" pure software, like programmatically revising
code in a string passed to eval(). Or C++ templates. Quite powerful, but
esoteric enough to be rare, and hard to maintain among different
programmers. Although VLIW programmers will love it, and multiprotocol
Internet routers will be much more reliable and faster. I'm more excited
about a MicroBlaze program that can retrieve FPGA config files from disk
or memory, reconfig the remaining unallocated gates, and call those
functions during execution. Even if the program just starts up, gets the
latest version of the glue logic for its neighboring support chips, and
continues its execution only in its uniprocessing MicroBlaze CPU thread,
the savings and efficiency of downloadable, onchip glue logic will be
superior to hardcoded CPUs in many cutting edge applications. 
	Even more exciting is loading multiprocessing logic that can be called
from a single function call in the uniprocessing program offers to
balance the best of both worlds of uni/multiprocessing, in the same
application. Then the architectural opportunities for runtime feedback
to the gates configuration offers a new level of intelligence to these
programs, while leveraging all the applicable techniques and software
from the last generations of hardcoded hardware. For example, a program
running in MicroBlaze has to decode an audio stream. It reads the
header, detects the format, then loads the decoder for that format from
disk to the gates. Realtime DSP becomes possible, and the benefits that
Intel crowed about for "NSP" (Native Signal Processing) actually arrive
intact. Next track is in a different format? Just overwrite the decoder
gates with that format's decoder from a disk file. And the rest of the
program, which doesn't vary with IO conditions, is a direct port of a
free/open PowerPC app. (I shiver with excitement :).

	Going from that environment, to gates that dynamically reconfigure on
the fly, will be less of a leap than just going from Pentium programming
to reconfig utopia. Especially for newer programmers, who never learned
bad habits (like vfork() - sorry :) necessary to work in the old
uniprocessing environment. So much of the exciting mobile multimedia
telecommunications future will benefit from genetic algorithms, fuzzy
logic, neural networks, geometric evaluation, as well as the vast
experience in procedural programming of English language policies. I'm
very excited about MicroBlaze as the vehicle that gets to that future.
In fact, I believe that the future has now already arrived, we're just
catching up to it. If MicroBlaze offered only the same uCLinux features
as on an ARM or Geode, why use it, except to exercise the fetish ;)?
What apps are *you* targetting with this platform?

	
> Regards

	Thanks for the opportunity to articulate my point with a critical edge
keeping me honest :). Especially since we seem to agree, when I can
express my points in understandable terms.


> Greg
> 
> 
> ------------------------------------------------------------------------
> Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg@snapgear.com
> SnapGear -- a CyberGuard Company            PHONE:       +61 7 3435 2888
> 825 Stanley St,                             FAX:         +61 7 3891 3630
> Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com
> 
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@itee.uq.edu.au
> Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
-- 


(C) Matthew Rubenstein

___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/