[MUD-Dev] Re: DevMUD Event Language

[Jon Leonard]

On Thu, Oct 22, 1998 at 08:14:21PM -0400, Hal Black wrote:
> Okay, this is a totally off the wall and demented idea I'd like to throw out:

It's off the wall and demented, but I think we can't throw it away completely.
(And yes, I'm going to throw up some web pages soon.)

>   To provide an event model (i.e. state changing through time on a schedule with
> contention resolution), how about mutating VHDL to be mudlike and then using
> that as the mud language?

I know Verilog lots better than VHDL, (I'm paid to design chips in Verilog)
so I may get the semantics a bit wrong.  Shouldn't matter much:  from the
remote perspective of a MUD developer, they're pretty similar.

Some aspects of programming in HDLs (Hardware Description Languages) are
usefully transferable to MUD design, and some are experiences while not
transferrable.

The model of a large system as a collection of pieces all working in parallel
(with explicit handshakes) can be useful.

Scheduling things via things like "do this 5 time units into the future"
is a useful model for doing long-running processes.

I also like debugging with waveforms.  It's really nice to be able to see
relevant variables vs. their values over time.  I can literally see where
and when the simulation went wrong.

There are other things about working in HDLs don't map nearly so usefully.

Explicit bit widths:  In a software world, I just want all my variables
to be wide enough.  The savings of narrower variables just aren't worth
having to declare every variable and constant with a width.  "Here's
a 17-bit integer." and "This should be less that 20, compared as a 12 bit
number." hurt readability, and there's no speed gain for doing it.

Extra bit states:  Support for strong and weak drive strengths, along with
high-impedance and unknown values is wasteful in non-hardware environments.
Just give me 0 and 1.

The time model is really wierd, too.  The concept of simulation time isn't
very useful in a MUD where everything should work according to real time.
Similarly, there isn't a need for clock signals.

[pseudo-VHDL pseudocode trimmed]

Jon Leonard