>   + does the processor need be 32-bit?

No.  However, if it's smaller than 32-bit you will have trouble, and if
you don't have 8-bit, 16-bit, and 32-bit operations I expect other
trouble.

>     is this simply for the convenience of memory addressing?

I don't understand what you're asking here.

>     does the idea of using multiple 8-bit processors instead of their
>     more expensive counterparts make you laugh?  if so, why?

It depends on how you're using them.  If you're trying to run 8-bit
code directly, I think you're dreaming.  The only use I could see for
them is trying to use them to implement a 32-bit (or 64-bit) processor
in a bit-slice fashion - a little like a SIMD parallel machine, though
doing 32-bit ops is not quite as simple as calling it SIMD makes it
sound.

>   + is a mmu absolutely essential?  is virtual memory essential?

To a UNIX variant?  No.  But to NetBSD?  Yes.

>   + how do i get started with a port?  are there some general
>     guidelines?

I don't know of any document that talks about this.  I've been somewhat
involved in two ports, though I wouldn't say I've "done a new port".
Here's my stab at it.

First: Gather as much documentation as you can about the machine.  You
will need, at a minimum, doc on how the CPU speaks to devices, how the
CPU manages the MMU, and how the boot sequence works.  (If you're
building your own hardware, this is trivial; if you're using an
off-the-shelf CPU such as the 68040, it's almost as trivial.)

Second: Port gcc to your CPU.  (Of course, this may already be done if
you use a stock CPU, like the MIPS.)

Third: Set up a build environment for your target.  This can be a
cross-build environment on another machine, it can be the target
machine under is vendor OS, whatever allows you to build binaries.
Cross-building on another NetBSD host is probably "best" in some sense.

Fourth: Build tiny little test "kernels", testing your knowledge of the
hardware.  Once you have basic input and output working, you can build
test harnesses that let you poke at things on the target hardware and
verify that your understanding matches reality.

Once you have working code for (1) console input and output, (2) either
network communication or disk access, and (3) mmu access, then you can
take the NetBSD tree and fill in the MD pieces.  (Again, if you're
using a CPU that's already supported by existing ports, like MIPS or
68k, some of the work is already done for you.)

>   + roughly, how many hours/days/months/years does an average port
>     require?

I'm not sure there is such a thing. :-)  I've never done the "second"
step, above, so I can't speak to that.  If I were handed the task, and
if some port already supports the CPU and MMU, and I had complete
hardware doc, I would allow one full-time person-month for the port,
plus another for dealing with unexpected gotchas along the way.

But that assumes a lot of the work is already done (the gcc port, and
the CPU/MMU support).  While I'm relatively familiar with the kernel,
I've never done a full port, so I could well be way off, either way -
but I've not seen anyone with more authoritative knowledge respond to
this part....

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B