From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: *
X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_20,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-spam!ames!ucbcad!ucbvax!NOSC-TECR.ARPA!CONTR47
From: CONTR47@NOSC-TECR.ARPA.UUCP
Newsgroups: comp.lang.ada
Subject: Tasks and Simulation (ref: Dennis Cottel's query)
Message-ID: <8702020214.AA20115@ucbvax.Berkeley.EDU>
Date: Fri, 23-Jan-87 09:02:19 EST
Article-I.D.: ucbvax.8702020214.AA20115
Posted: Fri Jan 23 09:02:19 1987
Date-Received: Tue, 3-Feb-87 01:35:52 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
List-Id: <comp.lang.ada>


   In the past I did extensive simulation of real-time computer systems
using IBM's GPSS simulation system. It was necessary for me to
know intimately the way that the GPSS kept track of simulated time. I believe
that the problem is generic to simulation rather than being an Ada problem
so I believe that the following is applicable.
   There was a master timekeeper which stepped the simulated time clock
and looked around for things to do at each time step. The programmer (me)
had to know the scan order in order to make sure that simulated events
would take place in the same order as in the system being simulated. There
was a command to force the timekeeper to scan if you needed it to at
a certain place in the program.
   The timekeeper scan took a significant amount of cpu time and motivated
even more intimate inquiry into its workings. GPSS moves transactions
from operation block to operation block which might simulate the
movement of ships in a harbor. When you program a delay block the
system computes the delay time and posts the end of delay as an
event on a future events chain. Thus the timekeeper doesn't have to
scan that delay block at each time step. The programming challenge then
is to write your program in such a way that every event can be pulled
from the future events chain and no time stepping/scanning is necessary.
Simulated time then proceeds steady-by-jerks from event to event. This
minimizes cpu time. The GPSS advanced programming manual told you how to
do this.
   My suggestion is that you get an "introduction to GPSS" manual if
they are still around or the internal documentation on any such
simulation system, then build it in Ada if you must. It will probably
be cheaper to just buy a simulation system for your PC if thats
enough compute power. Pritzker and Associates has a product line 
called SLAM in Fortran where you get the timekeeper source code. Your
bookstore or library may have a SLAM textbook.
   It sounds like you are on the road toward an object-oriented simulation
system which sounds very worthwhile to me. You can then add numerical
integration of differential equations etc...
regards, sam harbaugh
---------------------