From biocca@bevsun.bev.lbl.gov  Wed Apr  1 07:43:57 1992
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Date: Wed Apr  1 07:44:04 PST 1992
Subject: news to exploder feed problems

There has been a drop in the newsgroup to exploder feeds.  This resulted from
loss of files during 'disk full' conditions that were resolved awhile back,
but the file loss was not noticed until now.  The repair will likely result
in some duplication of older netnews articles in the feed to the exploder
tomorrow morning.

Alan K Biocca
Exploder Maintainer

From bernard@aar.alcatel-alsthom.fr  Wed Apr  1 11:48:52 1992
From: bernard@aar.alcatel-alsthom.fr ( Olivier Bernard )
Date: Wed Apr  1 11:48:59 PST 1992
Subject: Slip & flow control
1- First question: SLIP and flow control
----------------------------------------

We are using SLIP over a serial radio modem link and
it seems that SLIP does not handle RTS / CTS protocol.
This increases the number of retransmissions when our
modem is overloaded and sometimes leads to connection breaks. 

I tried to modify the hardware  initialization in "tyCoInitChannel":

*cr = SCC_WR0_SEL_WR3;		/* write reg 3 - receiv
*cr = SCC_WR3_RX_8_BITS | SCC_WR3_RX_EN | SCC_WR3_AUTO_EN;
                                        ------------------ <- my modification

in order to prevent the transmitter from sending bytes when CTS
is low on our modem but since SLIP is interfaced with the ty driver
this seems to have no effect ..

Has anybody got a solution ?

2- Strange things ...
---------------------

We use SLIP as a second link beetwen a mobile robot and our
stations: 

      UNIX gateway
 ---  
|   |---| radio modem |
 ---
  |
-----------------------------------
                   | ethernet
                   |
                   |
               --------------------------
              |  CPU1  | CPU2 | ... CPU4 |   CPUi: MV147
               --------------------------
                |            VME bus
| radio modem |-

We first boot via ethernet and then switch to SLIP
to remove the ethernet cable. We notice the following things:

1- rlogin <unix machine> works on CPU2 ... CPU4 but not on CPU1
   (the vxWorks gateway)

2- idem for NFS. We can load or list files on CPU2 ... CPU4 but
   not on CPU1.

Has anybody and explanation or solution ?

Thanks for any advice

-- Olivier

 -----------------------------------------------------------
!                                                           !
! Olivier BERNARD                                           !
! Alcatel Alsthom Recherche                                 !
! Route de Nozay                                            !
! 91460 Marcoussis                                          !
! France                                                    !
!                                                           !
! mail: bernard@aar.alcatel-alsthom.fr                      !
!                                                           !
 -----------------------------------------------------------

From purtell@csd.nad.northrop.com  Wed Apr  1 12:17:46 1992
From: Russ Purtell <purtell@csd.nad.northrop.com>
Date: Wed Apr  1 12:17:54 PST 1992
Subject: VxWorks Job Opportunities
Northrop Aircraft Division is looking to hire an Engineer (preferably
Senior) to support the activities of a research laboratory conducting
real-time aircraft simulations.  Responsibilities include the
production of real-time Ada code, embedded systems integration, and
the development of hardware specific device drivers.  Knowledge of the
VxWorks real-time operating system is necessary.  Familiarity with Sun
workstations, local area networks, the Ada programming language, Motorola
680x0 processors, digital circuitry, and control theory are desirable.
Prefer 4 years of experience plus BS in Electrical
Engineering/Computer Science or equivalent.

Please respond to Russ Purtell
                  Northrop Corporation
                  Orgn. 3832/62
                  One Northrop Ave.
                  Hawthorne, CA  90250-3296
                  (310) 332-6909
                  purtell@csd.nad.northrop.com

From stevem@assip.csasyd.oz.au  Wed Apr  1 22:19:45 1992
From: stevem@assip.csasyd.oz.au
Date: Wed Apr  1 22:19:54 PST 1992
From stevem@assip.csasyd.oz.au  Thu Apr  2 14:57:07 1992
Received: from condor.anzac by assip.csasyd.oz.au (4.1/ASSIP-V1)
	id AA18350; Thu, 2 Apr 92 14:57:07 EST
Received: by condor.anzac (4.1/SMI-4.1)
	id AA16839; Thu, 2 Apr 92 14:57:08 EST
Date: Thu, 2 Apr 92 14:57:08 EST
From: stevem@assip.csasyd.oz.au (Steven McCoy)
Message-Id: <9204020457.AA16839@condor.anzac>
To: vxwexplo%lbl.gov@metro.ucc.su.oz
Subject: BOOTP
Cc: stevem@condor

I've heard BOOTP mentioned a number of times on the exploder.  As indicated
in the modification dates of our current version, it seems to have come and gone
before our time.  Can anyone tell me exactly what it was used for and if it's
still in current use.

/* usrConfig.c - user defined system configuration module */
12x,02oct90,jcc  removed code associated with INCLUDE_BOOTP.
12f,07may90,hjb  added support for BOOTP forwarding.

Thanks in anticipation,

Steven McCoy
Computer Sciences of Australia P/L
stevem@assip.csasyd.oz.au

From daemon@vxw.ee.lbl.gov  Thu Apr  2 04:00:59 1992
From: daemon@vxw.ee.lbl.gov
Date: Thu Apr  2 04:01:20 PST 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Apr  2 04:00:49 PST 1992

        Subject: Task stacks & vxgdb
        Subject: Re: GCC-2.0
        Subject: Taking down a network...
        Subject: Re: Bus Error on Valid Address
        Subject: Re: Bus Error on Valid Address --- same experience - Xylogics 7800
        Subject: Re: taking down a network...
        Subject: Re: Taking down a network...
        Subject: Re: Taking down a network...
        Subject: Why -msoft-float in MV133 Makefile?
        Subject: RE: Why -msoft-float in MV133 Makefile?
        Subject: Re: GCC-2.0
        Subject: Re: GCC-2.0
        Subject: Query: SONIC driver
        Subject: Re: Sockets and clocks.
        Subject: Re: Taking down a network...
        Subject: Re: Why -msoft-float in MV133 Makefile?
        Subject: Re: Sockets and clocks.
        Subject: X.25 on vxWorks
        Subject: SCSI tape
        Subject: CFT: West Coast VxWorks Users Group Meeting
        Subject: gnu run time library
        Subject: Porting to vxworks
        Subject: Re: Receiving Broadcast messages via UDP sockets
        Subject: Remote program execution
        Subject: Re: Remote program execution
        Subject: VADSWorks time-slicing question
        Subject: Re: WRS Tech Notes
        Subject: re:  booting
        Subject: rlogin to a target clobbers remote user name
        Subject: Low power VME termination
        Subject: RPCs and sockets
        Subject: Re: rlogin to a target clobbers remote user name
        Subject: Re: Low power VME termination
        Subject: Re: rlogin to a target clobbers remote user name
        Subject: Share a room at user group meeting?
        Subject: Re: Low power VME termination
        Subject: Re: RPCs and sockets
        Subject: Re: gcc -ansi with 5.0
        Subject: Re: gcc -ansi with 5.0
        Subject: Re: RPCs and sockets
        Subject: Re: gcc -ansi with 5.0
        Subject: Re: exabyte.h file
        Subject: TCP Bandwith on VxWorks
        Subject: WANTED: Bay Area VxWorks person - contract work

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Task stacks & vxgdb
Date: 9 Mar 92 18:48:02 GMT
From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
Organization: Field Robotics Center, CMU
Message-ID: <HMP.92Mar9134801@potato.frc.ri.cmu.edu>
Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)

I've run into a strange interaction between vxgdb and an attached
task's stack: It looks as though vxgdb can use the area of the stack
that is also used by dynamic variables declared in the task's main routine.
I'm circumventing the problem by avoiding dynamic variables in the
main routine, but it still looks like an unwanted feature (not to use
the B-word...) to me. I don't recall seeing any warnings in the
manuals about declaring dynamic variables - did I miss something?

One other thing: Sometimes, after attaching to a pending task (say,
in a msgQReceive()), the attaching doesn't seem to take place; I give
a `next' command to gdb to complete the system call, cause whatever is
necessary to send that message, and the supposedly attached task just
comes alive as it would without gdb at this point. The `next' command
never returns. Anyone else see this behavior? It only happens occasionally.

Other than that, I think vxgdb is just great.

- -Henning
- --
Henning Pangels    |hmp@frc2.frc.ri.cmu.edu        |     Field Robotics Center
Research Programmer|(412) 268-7088                 |Carnegie-Mellon University
- ------------------------------------------------------------------------------
        I am a .signature virus.  Copy me into your .signature today!

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: GCC-2.0
Date: 9 Mar 92 20:51:56 GMT
From: marcu@leland.Stanford.EDU (Marc Albert Ullman)
Organization: DSG, Stanford University
Message-ID: <1992Mar9.205156.27189@leland.Stanford.EDU>
References: <9202242233.AA12941@cutter.ssd.loral.com>

In article <9202242233.AA12941@cutter.ssd.loral.com> bard@cutter.ssd.loral.com (James Woodyatt) writes:
>So, now that gcc-2.0 has been released, has anybody tried it with
>VxWorks yet?

I have built and installed it (as a Sun4 to 68k cross-compiler).  I haven't
tried rebuilding anything with it myself, but none of our other users have
complained of any problems with it.

- --Marc Ullman
  Stanford University

P.S.  Getting it to build the target version of libgcc.a is a little tricky.
      The cross-compiler needs to be able to find VxWork's version of stdio.h
      in order for this to complete successfully.

---------------------------

Newsgroups: comp.os.vxworks
Subject: Taking down a network...
Date: Tue, 10 Mar 1992 13:45:40 GMT
From: heyes@dadev.cebaf.gov (Graham Heyes)
Organization: CEBAF (Continuous Electron Beam Accelerator Facility)
Message-ID: <1992Mar10.134540.23961@murdoch.acc.Virginia.EDU>
Reply-To: heyes@dadev.cebaf.gov (Graham Heyes)
Sender: usenet@murdoch.acc.Virginia.EDU

I have been re-writing a driver for an 82586 ethernet controller for a VxWorks
port to a custom embedded controller. Ialready have a working driver hacked
from an existing 82596 driver so I do have network capabilities on the board.
What I would like to do is load the  new driver over the network, take down
the existing driver and start up the new one. Otherwise I have to burn EPROMS
all the time which is a pain, (also VxWorks doesn't seem to let me put 
breakpoints in EPROM resident routines).

	The question I have is resonably simple. How do I stop the old driver
in a tidy way and replace it by the new one? I don't  want to waste a lot of 
time trying to search out a bug which was really only due to not taking down 
the net properly.

	For your information.  The VxWorks kernel is version 5.0.2 running on
a 68020 with 256K ram and 512k EPROM. The limited RAM space means that all of 
the kernel runs from EPROM with only the data and bss segments in RAM. This 
means that I can't patch usrNetInit() or any of the other kernel routines.
All of the RAM is cleared as part of the VxWorks boot sequence so I can't
load the driver, disable the network, then reboot which is a trick I have used
with other EPROM resident operating systems.

	Any good ideas would be welcome otherwise I'll have to start burning
chips (yeuch)..

thanks in advance,

		Graham Heyes

- -------------------------------------------------------------------------------
	Graham Heyes					CEBAF
							Physics Division MS 12H
Internet: heyes@dadev.cebaf.gov			        12000 Jefferson Ave
DECnet  : dadev::heyes, cebaf::heyes			Newport News VA 23606
BITNET  : heyes@cebaf					Tel: (804) 249-7030
						

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Bus Error on Valid Address
Date: 10 Mar 1992 16:16:06 GMT
From: wbrown@beva.bev.lbl.gov (Bill Brown)
Organization: Lawrence Berkeley Laboratory, Berkeley
Message-ID: <21874@dog.ee.lbl.gov>
References: <9203091525.AA00313@spock.sparta.com>
Reply-To: wbrown@beva.bev.lbl.gov (Bill Brown)

>Dave Gawley Writes:
>
>
>
>Has anyone else seen bus errors from VxWorks when accessing valid addresses?
>
>...
a
We have had similar problems, altho they may not be not identical.

In one case, we found the mv147 would crash if it tried to access the
mailbox of an other processor on the bus while a DMA device was running.
The '147 was acting as system controller, the secondary processor was a
'143.  It seems like the system-controller on the '147 gets bent if there
is any bus contention.  We found that the problem goes away if we use
the '143 as the system controller, or if we use a seperate controller
such as an '050.

I talked to Motorola about problem, as well as a problem that the '147
has when dealing with multiple backplane interrupts.  There answer was
esentially that the '147 has no such problems; however I notice that
the newer processor boards ('167?) do not use the same VME interface
chip.  The '143 does not use the same chip either.

In short - IMHO the '147 sucks as a bus controller and should not be used
as such in a multi-processor system; nor should it be used in any system that
will have intense backplane interrupt traffic which the '147 will need to
respond to.  Other than that, it's a great board.

Disclaimer:  These opinions are my own and have	    |
    nothing to do with the official policy or the   |  -bill
    management of L.B.L, who probably couldn't      |   wlbrown@lbl.gov
    care less about employees who play with trains. |

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Bus Error on Valid Address --- same experience - Xylogics 7800
Date: Tue, 10 Mar 1992 20:07:05 GMT
From: adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams)
Organization: TH-Darmstadt
Message-ID: <ADAMS.92Mar10200705@PDV2.pdv2.fmr.maschinenbau.th-darmstadt.de>
References: <9203091525.AA00313@spock.sparta.com> <21874@dog.ee.lbl.gov>
Sender: news@infoserver.th-darmstadt.de (The Usenet-News System)

1) We tried to  use various versions of MVME147 in multiprocessor setups.

2) Given that MVME147 was busmaster, we saw real _strange_  behaviour.

3) Writing with a DMA-device (Xylogics-7800 IPI controller) into the
DRAM of a MVME147 triggered DMA-errors on the Xylogics. We had to
lower dma chunk size to 16, resulting in only 4 consecutive accesses
to the DRAM and releasing thereafter. As much as we could prove, this
was not a fault caused by the Xylogics equipment.

4) VMExec running on a MVME147 host under Unix and a MVME147 as target running
(in fact) pSOS, would hang from time to time --- bus error. Plain fun
to reboot the Unix host and fsck the disks  three times a day....

5) Or even more strange, having transferred several MBytes over the
VMEBus between host and target, one of the SCSI-controllers would hang
resulting in same procedure as in (4). Might point again to problems
around arbitration.

6) I doubt very  that this behaviour results from bus time out, our fastest
timer was set to more than 150 usecs....

7) I suspect much more problems around ROR /  ROD and bus arbitratration.
More or less I am convinced, their VMEBus chip does not work as
advertised...( Or to say it frank... It is not even B...S..T, later would 
fertilize the soil).

#flame starts
8) It would have been very nice, if Motorola  had confessed these problems,
but the denied any known problem. Last November we solved it on our own,
but a workaround would have saved us about half a year.

9) Beyond the arbitration problem the MVME147 lacks real DMA support
for their SCSI controller (WD39C93), which dates itself from acient
times.  Their ethernet controller and supporting software in sysV68
does not show up to date performance, it barely reaches 1/10 of the
performace of a nearby SUN 3/160 (70kB/s against 700kB/s running ftp
to the same ftp server).

10) How many waitstates does the CPU need to access DRAM? How about ten?

10) Beside already mentioned problems and design flaws, the MVME147
is a great board to spend  one's time with it ....
# flame off

best regards, adams

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: taking down a network...
Date: 10 Mar 92 19:52:59 GMT
From: hwajin@iphasew.com (Hwa-Jin Bae)
Organization: Interphase West, Santa Clara, CA
Message-ID: <6602@mondo.iphasew.com>

>>>>> On 10 Mar 92 13:45:40 GMT, heyes@dadev.cebaf.gov (Graham Heyes) said:

Graham> I have been re-writing a driver for an 82586 ethernet
Graham> controller for a VxWorks port to a custom embedded controller.
Graham> Ialready have a working driver hacked from an existing 82596
Graham> driver so I do have network capabilities on the board.  What I
Graham> would like to do is load the new driver over the network, take
Graham> down the existing driver and start up the new one. Otherwise I
Graham> have to burn EPROMS all the time which is a pain, (also
Graham> VxWorks doesn't seem to let me put breakpoints in EPROM
Graham> resident routines).

inserting breakpoints == modifying the code (replace the instruction
at the given address with trap instruction).  obviously it's not possible to
do this for the code in eprom.

Graham> 	The question I have is resonably simple. How do I stop
Graham> the old driver in a tidy way and replace it by the new one? I
Graham> don't want to waste a lot of time trying to search out a bug
Graham> which was really only due to not taking down the net properly.
Graham> For your information.  The VxWorks kernel is version 5.0.2
Graham> running on a 68020 with 256K ram and 512k EPROM. The limited
Graham> RAM space means that all of the kernel runs from EPROM with
Graham> only the data and bss segments in RAM. This means that I can't
Graham> patch usrNetInit() or any of the other kernel routines.  All
Graham> of the RAM is cleared as part of the VxWorks boot sequence so
Graham> I can't load the driver, disable the network, then reboot
Graham> which is a trick I have used with other EPROM resident
Graham> operating systems.

do the following from VxWork shell:

- -> myifp = ifunit("xx0")
- -> if_dettach(myifp)

*hwajin
- --
Interphase West
Santa Clara, CA

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Taking down a network...
Date: 10 Mar 92 19:46:40 GMT
From: hwajin@mondo.iphasew.com (Hwa-Jin Bae)
Organization: /u/koosh/hwajin/.organization
Message-ID: <HWAJIN.92Mar10114640@mondo.iphasew.com>
References: <1992Mar10.134540.23961@murdoch.acc.Virginia.EDU>
Sender: hwajin@iphasew.com

>>>>> On 10 Mar 92 13:45:40 GMT, heyes@dadev.cebaf.gov (Graham Heyes) said:

Graham> I have been re-writing a driver for an 82586 ethernet
Graham> controller for a VxWorks port to a custom embedded controller.
Graham> Ialready have a working driver hacked from an existing 82596
Graham> driver so I do have network capabilities on the board.  What I
Graham> would like to do is load the new driver over the network, take
Graham> down the existing driver and start up the new one. Otherwise I
Graham> have to burn EPROMS all the time which is a pain, (also
Graham> VxWorks doesn't seem to let me put breakpoints in EPROM
Graham> resident routines).

inserting breakpoints == modifying the code (replace the instruction
at the given address with trap instruction).  obviously it's not possible to
do this for the code in eprom.

Graham> 	The question I have is resonably simple. How do I stop
Graham> the old driver in a tidy way and replace it by the new one? I
Graham> don't want to waste a lot of time trying to search out a bug
Graham> which was really only due to not taking down the net properly.
Graham> For your information.  The VxWorks kernel is version 5.0.2
Graham> running on a 68020 with 256K ram and 512k EPROM. The limited
Graham> RAM space means that all of the kernel runs from EPROM with
Graham> only the data and bss segments in RAM. This means that I can't
Graham> patch usrNetInit() or any of the other kernel routines.  All
Graham> of the RAM is cleared as part of the VxWorks boot sequence so
Graham> I can't load the driver, disable the network, then reboot
Graham> which is a trick I have used with other EPROM resident
Graham> operating systems.

do the following from VxWork shell:

- -> myifp = ifunit("xx0")
- -> if_dettach(myifp)

*hwajin
- --
Interphase West
Santa Clara, CA

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Taking down a network...
Date: Tue, 10 Mar 1992 21:56:32 GMT
From: heyes@dadev.cebaf.gov (Graham Heyes)
Organization: CEBAF (Continuous Electron Beam Accelerator Facility)
Message-ID: <1992Mar10.215632.485@murdoch.acc.Virginia.EDU>
References: <1992Mar10.134540.23961@murdoch.acc.Virginia.EDU> <HWAJIN.92Mar10114640@mondo.iphasew.com>
Reply-To: heyes@dadev.cebaf.gov (Graham Heyes)
Sender: usenet@murdoch.acc.Virginia.EDU

In article <HWAJIN.92Mar10114640@mondo.iphasew.com>,
hwajin@mondo.iphasew.com (Hwa-Jin Bae) writes:
|>In-reply-to: heyes@dadev.cebaf.gov's message of 10 Mar 92 13:45:40
|>GMT
|>
|>>>>>> On 10 Mar 92 13:45:40 GMT, heyes@dadev.cebaf.gov (Graham Heyes)
|>said:
|>
|>Graham> I have been re-writing a driver for an 82586 ethernet
|>Graham> controller for a VxWorks port to a custom embedded
|>controller.
|>Graham> Ialready have a working driver hacked from an existing 82596
|>Graham> driver so I do have network capabilities on the board.  What
|>I
|>Graham> would like to do is load the new driver over the network,
|>take
|>Graham> down the existing driver and start up the new one. Otherwise
|>I
|>Graham> have to burn EPROMS all the time which is a pain, (also
|>Graham> VxWorks doesn't seem to let me put breakpoints in EPROM
|>Graham> resident routines).
|>
|>inserting breakpoints == modifying the code (replace the instruction
|>at the given address with trap instruction).  obviously it's not
|>possible to
|>do this for the code in eprom.
|>

Sorry but I have used several debuggers which allow this they work by making 
a copy of the code in RAM, correcting any absolute references correspondingly
and  executing that, essentially using the cpu as a cpu - emulator. I don't
remember the specifics because I never took on apart completely but I do
know that there are "tricks" which allow you to do it. This is probably
heavy for VxWorks since most systems are RAM resident. I was just pointing
out that it would be nice to put my driver in RAM so that I can use all of
the debugging tools VxWorks provides since they are not aimed at development
of rom  esident code.

	Graham 

---------------------------

Newsgroups: comp.os.vxworks
Subject: Why -msoft-float in MV133 Makefile?
Date: 11 Mar 92 20:09:15 GMT
From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
Organization: Field Robotics Center, CMU
Message-ID: <HMP.92Mar11150915@squash.frc.ri.cmu.edu>
Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)

Subject line kinda summarizes it: The MV133XT has an 68882, yet the
Makefile in config/mv133 (under 5.0.2(b)) defines -msoft-float.

Oversight or intentional?

- -Henning
- --
Henning Pangels    |hmp@frc2.frc.ri.cmu.edu        |     Field Robotics Center
Research Programmer|(412) 268-7088                 |Carnegie-Mellon University
- ------------------------------------------------------------------------------
                     Fast, Cheap, Good: Choose Any Two

---------------------------

Newsgroups: comp.os.vxworks
Subject: RE: Why -msoft-float in MV133 Makefile?
Date: Wed, 11 Mar 92 20:23:40 GMT
From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
Organization: Field Robotics Center, CMU
Message-ID: <HMP.92Mar11152340@squash.frc.ri.cmu.edu>
Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)

OK, so further inspection shows that somehow the floating point calls
are vectored to _mathHard* calls, which show an abundance of
instructions beginning with "F", i.e. it uses the FPC after all.
Pretty strange...but I'm sure there is a good reason, right?

- -hp

- --
Henning Pangels    |hmp@frc2.frc.ri.cmu.edu        |     Field Robotics Center
Research Programmer|(412) 268-7088                 |Carnegie-Mellon University
- ------------------------------------------------------------------------------
                     Fast, Cheap, Good: Choose Any Two

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: GCC-2.0
Date: 11 Mar 92 20:59:07 GMT
From: bob@jupiter.UUCP (Bob Schulman)
Organization: Jupiter Systems, Alameda, CA
Message-ID: <1260@jupiter.UUCP>
References: <1992Mar9.205156.27189@leland.Stanford.EDU>

From article <1992Mar9.205156.27189@leland.Stanford.EDU>, by marcu@leland.Stanford.EDU (Marc Albert Ullman):
> In article <9202242233.AA12941@cutter.ssd.loral.com> bard@cutter.ssd.loral.com (James Woodyatt) writes:
>>So, now that gcc-2.0 has been released, has anybody tried it with
>>VxWorks yet?
> 
> I have built and installed it (as a Sun4 to 68k cross-compiler).  I haven't
> tried rebuilding anything with it myself, but none of our other users have
> complained of any problems with it.
I have built and tested the X server using gcc 2.0 on top of a gcc 1.3 vxWorks.
I am not impressed. Some things are faster under 2.0 (only a few).
Some things are slower (more than a few). Overall, I'd say slower.

Also, gcc 2.0 takes *alot* more time to compile than 1.3. This would be OK
if the results were significantly better than 1.3. In my case this was not
the case.

bob

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: GCC-2.0
Date: 12 Mar 92 00:54:17 GMT
From: bard@cutter.ssd.loral.com (James Woodyatt)
Organization: Space Systems/Loral
Message-ID: <1992Mar12.005417.5567@wdl.loral.com>
References: <1992Mar9.205156.27189@leland.Stanford.EDU> <1260@jupiter.UUCP>
Sender: bard@cutter (James Woodyatt)

In article <1260@jupiter.UUCP>, bob@jupiter.UUCP (Bob Schulman) writes:
|> From article <1992Mar9.205156.27189@leland.Stanford.EDU>, by marcu@leland.Stanford.EDU (Marc Albert Ullman):
|> > In article <9202242233.AA12941@cutter.ssd.loral.com> bard@cutter.ssd.loral.com (James Woodyatt) writes:
|> > >So, now that gcc-2.0 has been released, has anybody tried it with
|> > >VxWorks yet?
|> > 
|> > I have built and installed it (as a Sun4 to 68k cross-compiler).  I haven't
|> > tried rebuilding anything with it myself, but none of our other users have
|> > complained of any problems with it.
|>
|> I have built and tested the X server using gcc 2.0 on top of a gcc 1.3 vxWorks.
|> I am not impressed. Some things are faster under 2.0 (only a few).
|> Some things are slower (more than a few). Overall, I'd say slower.

Is this with the -O flag or with -O2 or -O3? I've seen postings on the gnu
newsgroups showing the benchmark comparisons between gcc-1.40 and gcc-2.0.
They indicated that the -O flag in gcc-2.0 produces slower code than it did
for gcc-1.40, but using the -O2 and -O3 gave progressively better results --
to the point where it surpassed gcc-1.40.

However, this was all on a sun4 configured as a native compiler.

- -- 
James Woodyatt  Space Systems/Loral   Palo Alto, CA   bard@cutter.ssd.loral.com

``I like your proposed schedule,
but I think it's unnecessarily
realistic.''
                  --Anonymous

---------------------------

Newsgroups: comp.os.vxworks
Subject: Query: SONIC driver
Date: 12 Mar 92 20:16:10 GMT
From: hwajin@mondo.iphasew.com (Hwa-Jin Bae)
Organization: /u/koosh/hwajin/.organization
Message-ID: <HWAJIN.92Mar12121610@mondo.iphasew.com>
Sender: hwajin@iphasew.com

does anyone have a driver for sonic (national semi. dp83932b)?
thanks.

*hwajin

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Sockets and clocks.
Date: Fri, 13 Mar 1992 16:59:42 GMT
From: bgeer@javelin.sim.es.com (Bob Geer)
Organization: Evans & Sutherland Computer Corporation
Message-ID: <1992Mar13.165942.862@javelin.sim.es.com>
References: <9203121924.AA00658@spock.sparta.com>
Reply-To: bgeer@javelin.sim.es.com

>>1. What is the best means of communication over the ethernet, where data
>>   rates are important?

We're using the MVME-147 in a flight simulation task where Ethernet
i/o will be running 50Hz or 60Hz.  We decided to drop below the socket
i/o level for increased efficiency, so we wrote a simple pair of
functions, enetserverRead() & enetserver() that can efficiently
process our time-critical incoming Ethernet packets.

First, a task is spawned consisting of the function enetserver() which
creates a semaphore, calls the etherInputHookAdd(enetserverRead)
library routine, & starts a "while (TRUE)" loop that begins with
semTake().  Packet processing functions are called once the semaphore
is given by enetserverRead(), & then the "while" loop continues.

The function enetserverRead() is inserted into the Ethernet packet
processing stream by "etherInputHookAdd(enetserverRead)".  It checks
the source address, destination address, & data content of a received
packet, returns FALSE if further processing of the packet is required
(say, by NFS or socket routines), & returns TRUE if the packet
requires no further processing.  If the data is to be processed, the
packet's data is transfered into a local buffer for the enetserver()
routine mentioned below, & the semaphore is given to initiate the
processing.

An Ethernet packet may be sent using the etherOutput() library
routine.  The format of the packet header is:

/*
 * ethernet packet layout
 *
 * data length doesn't include 1st 14 bytes -- s & d addrs & length
 *
 *    ethernet destination addr msw = (packet_buffer +  0);
 *    ethernet destination addr  mw = (packet_buffer +  2);
 *    ethernet destination addr lsw = (packet_buffer +  4);
 *    ethernet source addr msw      = (packet_buffer +  6);
 *    ethernet source addr  mw      = (packet_buffer +  8);
 *    ethernet source addr lsw      = (packet_buffer + 10);
 *    data length (bytes)           = (packet_buffer + 12);
 *    [1st data byte]               = (packet_buffer + 14);
 *    [46 bytes mininum length]
 */

The downside, of course, is these addr's are the Ethernet chip
addresses instead of something more easily determined such as internet
addresses & aliases.  But it's fast & efficient enough for our
requirements.

- -- 
<> Bob `Bear' Geer <>  bgeer@beorn.sim.es.com                           /  <>
<>                 <>   (this *often* works)       __o      o   ,______/o  <>
<> Salt Lake City, <>  speaking only for myself,  -\<,     <\   ,__/   >   <>
<>          Ootah  <>  one of my many tricks      O/ O  __ /__,       /    <>

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Taking down a network...
Date: 11 Mar 92 14:21:59 GMT
From: rypma@hppad.waterloo.hp.com (Ted Rypma)
Organization: HP Panacom Div Waterloo ON Canada
Message-ID: <27550004@hppad.waterloo.hp.com>
References: <1992Mar10.134540.23961@murdoch.acc.Virginia.EDU>

heyes@dadev.cebaf.gov (Graham Heyes) wrote:

> 	The question I have is resonably simple. How do I stop the old driver
> in a tidy way and replace it by the new one? I don't  want to waste a lot of 
> time trying to search out a bug which was really only due to not taking down 
> the net properly.

I would think that an "if_down(ifp)" [at splnet] followed by "ifreset()" if
all net interfaces are being cleared [otherwise "eiReset(unit)" or equivalent
driver routine], then turn off interrupts and last, an "if_dettach(ifp)".

You ought to be able to start up cleanly after this by calling the new driver's
attach routine and doing an ifAddrSet(). The 82596 seems to restart OK under
these conditions (and network code ought to be happy).

Ted Rypma
HP Panacom Division
Waterloo, Ontario

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Why -msoft-float in MV133 Makefile?
Date: Wed, 11 Mar 1992 22:15:14 GMT
From: geoff@wrs.com (Geoff Espin)
Organization: Wind River Systems, Inc.
Message-ID: <geoff.700352114@wrs.com>
References: <HMP.92Mar11150915@squash.frc.ri.cmu.edu>
Sender: usenet@wrs.com (News Manager)

hmp@frc2.frc.ri.cmu.edu (Henning Pangels) writes:
>Subject line kinda summarizes it: The MV133XT has an 68882, yet the
>Makefile in config/mv133 (under 5.0.2(b)) defines -msoft-float.
>Oversight or intentional?

The mv133 BSP supports the MVME-133, MVME-133A, MVME-133XT and MVME-134.

Only the MVME-133XT has an FPU, if I recollect correctly.
The MVME-134 has an MMU.

Geoff
- --
Thanks,
Geoff

- ---

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Sockets and clocks.
Date: 17 Mar 92 04:35:08 GMT
From: smb@afterlife.ncsc.mil (Steve M. Burinsky)
Organization: The Great Beyond
Message-ID: <1992Mar17.043508.9899@afterlife.ncsc.mil>
References: <9203121657.AA01433@nettlerash.berkeley.edu>

In article <9203121657.AA01433@nettlerash.berkeley.edu> hebo@mbari.org (Bob Herlien) writes:
>I ported NTP (version 1) to VxWorks several months ago.  It's on the
>archives at thor.atd.ucar.edu, in files ntpvx*.  I haven't gotten around
>to trying to port version 3, and may never do so (it will require a large
>rework to get rid of dependencies on async I/O, which VxWorks doesn't support).

APLabs sells a VxWorks asynchronous I/O library.  Can I assume that this would
make the NTP 3.0 port easier?
- -- 

Steve M. Burinsky
smb@afterlife.ncsc.mil

---------------------------

Newsgroups: comp.os.vxworks
Subject: X.25 on vxWorks
Date: 17 Mar 92 21:20:31 GMT
From: smeg@bnr.ca (Maarten Koning)
Organization: Bell-Northern Research Ltd.
Keywords: X.25
Message-ID: <1992Mar17.212031.14443@bnr.ca>
Reply-To: smeg@bnr.ca
Sender: news@bnr.ca (usenet)

Hi,

Does anyone offer an X.25 protocol stack for vxWorks?  Any references
or sharing of experiences would be appreciated.

Thanks,
	Maarten Koning

- -- 
//include1 pgm=disclaimer,parm='my opinions only'
Maarten Koning | Internet:  smeg@bnr.ca        | Phone: (613) 763-8796
BNR Ltd.       |    This space for rent        | FAX:   (613) 763-2626

---------------------------

Newsgroups: comp.os.vxworks
Subject: SCSI tape
Date: Wed, 18 Mar 92 19:50:05 GMT
From: singer@ll.mit.edu (Matthew R. Singer)
Organization: MIT Lincoln Laboratory
Message-ID: <1992Mar18.195005.28392@ll.mit.edu>
Reply-To: singer@ll.mit.edu (Matthew R. Singer)
Sender: singer@ll.mit.edu (Matthew R. Singer)

- --
Anyone know of a PD or commercial set of routines for driving SCSI tape devices?
Exebyte 8500 in particular..

Thanks
 
 -----------------------------------------------------------------------------
Matthew R. Singer                                    MIT Lincoln Laboratory
(617) 981-3771                                       244 Wood Street
singer@ll.mit.edu                                    Lexington, MA 02173
- -----------------------------------------------------------------------------

---------------------------

Newsgroups: comp.os.vxworks
Subject: CFT: West Coast VxWorks Users Group Meeting
Date: 18 Mar 92 21:57:21 GMT
From: sjk@crl.labs.tek.com (Steven King)
Organization: Software Technology Research Lab, Tektronix, Inc.
Message-ID: <3825@crl.LABS.TEK.COM>
Followup-To: comp.os.vxworks
Reply-To: sjk@crl.labs.tek.com (Steven King)
Sender: news@crl.LABS.TEK.COM

                            Call for Talks

                West Coast VxWorks Users Group Meeting

                            April 10, 1992
                          Newport Beach, CA

A significant body of experience in the design and implementation 
of VxWorks applications has been developed over the last few years,
both through research prototypes and industrial products.  Given the 
growth of the off-the-shelf real-time development systems market, and 
the growth of VxWorks in particular, the time seems right to share our 
knowledge base so that we can impact the future of real-time systems 
development using VxWorks.

Examples of interesting applications include state-of-the-art networking
(e.g. SNMP, bootp, tftp, TLI), object-oriented languages, multi-processor
applications, unique device interfaces, extensions of the VxWorks 
development environment, etc.  Examples of useful paradigms for structuring
VxWorks-based systems are object-oriented design, client-server models, 
minimal-kernel based applications, enforced deadline-scheduling algorithms,
etc.

This meeting should be the occasion for the VxWorks community to share 
the experiences on which their practice is based.  In addition, we should 
use this opportunity to communicate to Wind River Systems our view of 
where the discipline of real-time applications development is heading.

There will be two disctinct forums for users to share their experiences:
1) the applications presentation, where users will discuss their work with
VxWorks and 2) the issues forum, which will allow users to present current
limitations of VxWorks, along with potential solutions to these challenges.

Each talk will run between ten and fifteen minutes in length.  The
atmosphere will be informal.  We would all appreciate hearing about your
VxWorks experiences.  If you wish to participate, please submit a brief
outline of your talk (two or three paragraphs) to:

Steven King
Software Technology Research Labs
Tektronix, Inc.
Telephone: 503-627-2736
Fax: 503-627-5502
Voice Mail: 503-727-6651
e-mail: sjk@crl.labs.tek.com

Please include an electronic mailing address (if you have one) in your 
outline.  We will need a paper copy of all handout and overhead materials.
The meeting minutes including materials from all talks will be published by
Wind River Systems.

---------------------------

Newsgroups: comp.os.vxworks
Subject: gnu run time library
Date: 18 Mar 92 22:15:06 GMT
From: votava@fndaud.fnal.gov (Margaret Votava)
Organization: Fermi National Accelerator Laboratory, Batavia IL
Message-ID: <1710@fnnews.fnal.gov>
Sender: news@fnnews.fnal.gov

Hi,

	Has anybody ported the gnu run time library (I believe it's called
GLIB) to vxworks? We are trying to port some code to a vxworks target, but
it makes several references to normal c run time library functions that are not
supported in the WRS distribution.

		Thanks,
		Margaret Votava
		Fermilab
		(708)-840-2625

---------------------------

Newsgroups: comp.os.vxworks
Subject: Porting to vxworks
Date: 20 Mar 92 19:16:51 GMT
From: mitchs@netcom.com (Mitch Stermer)
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Message-ID: <1a#jtrnmitchs@netcom.com>
References: <9203201801.AA05511@lodestar.gb.nrao.edu>

	I am looking a port a application that runs unders Unix SysV,
	ULTRIX, OS/2 and AIX 3.2 to vxworks. Most the the code was 
	written following  the POSIX 1003.1 base os standard for 
	things as file system access, host name and the like. I am
	new to vxworks and haven't seen anything that shows that it
	has those interfaces. I know I will have to rewrite the message
	and semaphore code, but I was hoping the majority of the other
	code would come right over.

	Has anyone done a port of this nature to vxworks?  Could any
	of you share the experience that you have had porting to this?

Thanks

mitchs

- -- 

Mitch Stermer (System Slave)
mitchs@netcom.COM

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Receiving Broadcast messages via UDP sockets
Date: 21 Mar 92 01:53:34 GMT
From: hwajin@pogo.omni.com (Hwa-Jin Bae)
Organization: Interphase West, Santa Clara, CA
Message-ID: <HWAJIN.92Mar20175334@pogo.omni.com>
References: <9203192129.AA27642@hns.com>
Sender: hwajin@iphasew.com

contrary to what's been already said, broadcasting using udp works fine
with vxworks.  i'd like to see the program that doesn't work.

*hwajin

---------------------------

Newsgroups: comp.os.vxworks
Subject: Remote program execution
Date: Mon, 23 Mar 92 22:41:01 GMT
From: mkb+@cs.cmu.edu (Mike Blackwell)
Organization: School of Computer Science, Carnegie Mellon
Message-ID: <1992Mar23.224101.197222@cs.cmu.edu>

Let's say I have a VxWorks box booting off a Unix box. In it's init file,
VxWorks loads all of its code. At some later point, I'd like the Unix box to
tell the VW box to execute a program. Is there any way to do this? Something
simple like rsh would be ideal. Rsh doesn't work, but maybe something
similar that would rlogin and shove some input to the VW console? Any ideas
or solutions?

		Mike Blackwell		mkb@cs.cmu.edu

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Remote program execution
Date: 24 Mar 92 15:29:03 GMT
From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
Organization: Field Robotics Center, CMU
Message-ID: <HMP.92Mar24102903@squash.frc.ri.cmu.edu>
References: <1992Mar23.224101.197222@cs.cmu.edu>
Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)

Well, simply redirecting input at the unix side works, i.e. 

rlogin target < command-script

Then, there is th vxrsh package, available from the vxWorks archives,
via ftp thor.ucar.edu. I haven't tried it myself.

If you have multiple CPUs, you can also have a script on the "main"
CPU rlogin to secondaries, with input redirected from startup scripts
for the individual board. It's somewhat of a kludge, but it has worked
for me for quite a while, and I only have to manually invoke one main
script that starts up everything in the system.

- -Henning

- --
Henning Pangels    |hmp@frc2.frc.ri.cmu.edu        |     Field Robotics Center
Research Programmer|(412) 268-7088                 |Carnegie-Mellon University
- ------------------------------------------------------------------------------
        I am a .signature virus.  Copy me into your .signature today!

---------------------------

Newsgroups: comp.lang.ada,comp.os.vxworks
Subject: VADSWorks time-slicing question
Date: 24 Mar 92 03:44:56 GMT
From: jeffm@assip.csasyd.oz.au (Jeff Melvaine)
Organization: Computer Sciences of Australia
Keywords: Ada VADS
Message-ID: <jeffm.701408696@condor>
Reply-To: jeffm@assip.csasyd.oz.au

Thank you to all who responded to my question.  We appreciate the variety of
insights and perspectives gained from the answers,  and our quandary has been
resolved.

> This question is addressed to those familiar with the Sun VADSWorks system for
> Sun-4 and/or 680x0 targets.  Our system designers wish the code to run with
> time slicing disabled for reasons of efficiency.  (We are aware of the
> consequences of blocking a lightweight task in this mode of operation).  The
> discussion point is that there are two ways of disabling time slicing: 
> statically (by modifying the VADS kernel configuration table entry),  and
> dynamically (by calling a subprogram in package vx_tasking).  The latter appears
> to require less work to set up.  Is there any reason to prefer the static
> method?
> 
From: "David L. Levine" <levine%segur.ICS.UCI.EDU@metro.ucc.su.OZ.AU>
It doesn't require the addition to the code that would impair portability.
I use the static approach to avoid implementation dependencies
in my code.  On the other hand, if you know that the code will always be
used in a VADS environment, turning time slicing off in the code is much
more visible than the modified ada.lib.

David L. Levine
Internet: levine@ics.uci.edu
UUCP: uunet!ucivax!levine
BITNET: levine@uci

> I would expect that the effect of calling vx_tasking.set_time_slicing_enabled
> was to enable/disable delivery of a periodic SIGALRM to trigger rescheduling, 
> and that choice between the two methods is largely a matter of style.  I would
> appreciate input from anyone who can shed more light on this.
> 
From: esther%verdix.com@metro.ucc.su.OZ.AU (Esther Lumsdon)
Several of the vx_tasking calls "queue" actions that will take effect the next
time the kernel code is run. This is not intuitive. Sorry about that.  
set_time_slicing_enabled is one of those. (I think that all of the time slice 
manipulation calls are.)  To make the set_time_slicing_enabled take effect, 
follow it by a  delay (0.0) statement.  This will enter the kernel, and your 
change will take effect.

Generally, customers find that they need to alter the default task stack size,
or change the memory allocation method, so they statically set time slicing
since they have to build a usr_conf library anyway. And they avoid that
delay (0.0) statement.

- ------ Esther Lumsdon  Product Support Engineer, Verdix Corporation
  205 Van Buren St  Herndon, Virginia, USA
  esther@verdix.com  or  esther%verdix.com@uunet.uu.net

From: bobf%verdix.com@metro.ucc.su.OZ.AU
Jeff, after reading your post, I uncovered a slight deficiency in our usr_conf
implementation.

There are actually *three* ways to enable time-slicing in a VADSworks
application.  One of these ways unfortunately does not work.

(1) In file v_usr_conf_b.a in library usr_conf, configuration section #c2d
provided the time-slicing defaults:

           --  #c2d: TIME SLICE CONFIGURATION PARAMETERS:
       TIME_SLICING_ENABLED     =>   TRUE,
       TIME_SLICE_INTERVAL      =>   1.0,

As you can see, time-slicing should be enabled by default, yet it is not.
There is a slight problem in that at program startup, TIME_SLICING_ENABLED is
incorrectly evaluated.  As a result, modifying v_usr_conf to enable
time-slicing will not work.   However, there are two other methods:

(2) The VADSexec call V_XTASKING.set_time_slicing_enabled can be used to
turn time-slicing on and off.  The slice interval is the one in v_usr_conf
(this *does* work).  This call turns time slicing on for Ada tasks.

(3) The VxWorks kernelLib call kernelTimeSlice() turns time-slicing on for all
tasks, not just Ada tasks.  This call may be invoked from the VxWorks shell, or
called from an Ada or C routine.

The choice between these three methods is more than stylistic.  Modifying
v_usr_conf implements changes applied to *all* Ada applications linked with
the user configuration. The latter two methods are used on an individual
application basis.

To summarize, modifying v_usr_conf implements GLOBAL changes, while calling
VADSexec/VxWorks routines implement LOCAL changes.

Bob Foery
Verdix Product Support Engineer
bobf@verdix.com

From: vestal%src.honeywell.com@metro.ucc.su.OZ.AU (Steve Vestal)
Well, I used a beta release of VADSWorks for a Mizar board a couple of years
ago.  I used the dynamic call to disable time slicing, but in the course of
some very detailed benchmarking studies discovered that the runtime system
still received and processed a signal at 1 second intervals.  My speculation
is that the disabling was done inside the runtime SIGALRM handler, rather than
by just disabling SIGALRMs.  These may possibly be needed for something else
(e.g. resuming suspended tasks from the delay queue), and it may not depend on
whether disabling is done statically or dynamically.  So, no matter what you
do, you may get periodic SIGALRMS, but time slicing will be disabled and
"unnecessary" context swaps will be eliminated.

> 	Jeff
> 

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: WRS Tech Notes
Date: 25 Mar 92 04:11:54 GMT
From: smb@afterlife.ncsc.mil (Steve M. Burinsky)
Organization: The Great Beyond
Message-ID: <1992Mar25.041154.4223@afterlife.ncsc.mil>
References: <9203202051.AA27423@yuba.WRS.COM>

In article <9203202051.AA27423@yuba.WRS.COM> francis@yuba.wrs.com (Francis St. Amant) writes:
>                                They are available in nicely formatted
>(FrameMaker) hardcopy, which makes diagrams and tables come out better.
>
>They are also available in ascii format by dialling the WRS BBS at 
>510-814-2165.  And Tech Support can email notes to you if you call
>them at 800-872-4977 and submit a request, along with your email address.

Why doesn't WRS simply POST THEM HERE!  Post all existing ones now, and new
ones as they become available.  They could be part of the archive, and
readily available.  Put the FrameMaker documents out in MIF format,
so those of us with FrameMaker can get the pretty pictures.  This will
save you on postage and phone bills, too :).
- -- 

Steve M. Burinsky
smb@afterlife.ncsc.mil

---------------------------

Newsgroups: comp.os.vxworks
Subject: re:  booting
Date: 26 Mar 92 17:29:45 GMT
From: brunner@kazoo.ssd.loral.com (Brian Brunner)
Organization: Space Systems/Loral
Message-ID: <1992Mar26.092945@kazoo.ssd.loral.com>
References: <9203260059.AA10280@dtc163.VisiCom.COM>
Reply-To: brunner@kazoo.ssd.loral.com (Brian Brunner)
Sender: news@wdl.loral.com

Our solution to this problem (60-something machines booting
at once) was simplified by using a large-enough PROM to
hold ALL of vxWorks... plus adding code to copy anything on the
floppy disk (if present) to the hard disk, then to search the hard
disk for the application to execute. Result: turn-key vxWorks
applications. Which IP address the various boards claim is
still set in NVRAM, but is profoundly less important and does
not effect booting at all.

Have a day.

- --
HELP!! Somebody slapped a "stop payment" on my sanity check!!
brunner@kazoo.ssd.loral.com; Space Systems/Loral; Palo Alto, Calif.
Black Holes... the /dev/null of the Universe; the opinion of 65534.

---------------------------

Newsgroups: comp.os.vxworks
Subject: rlogin to a target clobbers remote user name
Date: Thu, 26 Mar 92 19:02:03 GMT
From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
Organization: Field Robotics Center, CMU
Message-ID: <HMP.92Mar26140203@deimos.frc.ri.cmu.edu>
Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)

Has anyone else observed this? 

After a completed rlogin session to a vxWorks target, whoami on that
target's console returns a null string. This happens even if I did
nothing but rlogin and logout.

- -Henning

- --
Henning Pangels    |hmp@frc2.frc.ri.cmu.edu        |     Field Robotics Center
Research Programmer|(412) 268-7088                 |Carnegie-Mellon University
- ------------------------------------------------------------------------------
                     Fast, Cheap, Good: Choose Any Two

---------------------------

Newsgroups: comp.os.vxworks
Subject: Low power VME termination
Date: Thu, 26 Mar 92 19:40:44 GMT
From: mkb+@cs.cmu.edu (Mike Blackwell)
Organization: School of Computer Science, Carnegie Mellon
Message-ID: <1992Mar26.194044.23352@cs.cmu.edu>

I know this isn't really the right group, but I'm not sure what is, and
someone here might know...

I have a low power VxWorks real time system (Dynatem boards), and it turns
out that almost half of the power going in to the cage is eaten up by the
VME bus terminators. Since this is a battery powered system, this is an
important issue. Does anyone know of lower power terminators than the usual
bank of resistors? I was thinking maybe some sort of active termination. Any
advice or pointers would be much appreciated.

		Mike Blackwell		mkb@cs.cmu.edu

---------------------------

Newsgroups: comp.os.vxworks
Subject: RPCs and sockets
Date: 26 Mar 1992 22:02:25 GMT
From: lewis@bevsun.bev.lbl.gov (Steve Lewis)
Organization: Lawrence Berkeley Laboratory, California
Message-ID: <22298@dog.ee.lbl.gov>
Sender: Steve Lewis

Several articles have raised questions concerning VxWorks speed both
at the socket level and at the RPC level.  I have made some performance
tests, although my notes are lost for the moment.  The best results were
obtained with a Sparcstation-2 against an MVME-147.  I tried many
combinations, including Sparc-Sparc, VME-VME across both Ethernet and
backplane.  Results were:
    (1) Maximum transactions rates of 550 very short (one long to RPC)
	round-trips/sec.
    (2) Maximum throughput rates of 600KB/sec using very long (8000 bytes to
	RPC) copying the data both ways.

I concluded that:
    (1) All all cases were cpu-limited, not medium limited.
    (2) From previous tests, the 4.3BSD "fix" to the VxWorks TCP/IP
	stack indeed gave better than 2x improvement.
    (3) The cost of XDR was well worth the convenience; one could always
	minimize this with xdr_opaque() in the spirit of ARTSE.
    (4) One-way network latencies were about 1 msec--tcpdump confirms
	you can get an RPC on the wire and see the response back on the
	wire in 1-3 msec.

So, the VxWorks implementation of RPC 4.0 works; I have patched a few things
(like clnt_sperror()) but have only a dozen lines of #ifdef'd code in
order to keep common source in a few *low-level* routines that I hide all
my RPC behind.

We have an MVME-167 (68040) on hand; I will repeat all my tests and post
some accurate numbers for Sparc 1+, Sparc 2, '147, and '167 one of these
days.

	Steve Lewis, Group Leader		SALewis@LBL.gov
	Computer Controls			Mail Stop 64-121
	Lawrence Berkeley Laboratory		Tel: 510/486-7702
	Berkeley, CA 94720			Fax: 510/486-5788
- -- 
	Steve Lewis, Group Leader		SALewis@LBL.gov
	Computer Controls			Mail Stop 64-121
	Lawrence Berkeley Laboratory		Tel: 510/486-7702
	Berkeley, CA 94720			Fax: 510/486-5788

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: rlogin to a target clobbers remote user name
Date: Thu, 26 Mar 1992 23:57:53 GMT
From: litwin@litwin.jpl.nasa.gov (Todd Litwin)
Organization: Jet Propulsion Laboratory
Message-ID: <1992Mar26.235753.12827@elroy.jpl.nasa.gov>
References: <HMP.92Mar26140203@deimos.frc.ri.cmu.edu>
Sender: news@elroy.jpl.nasa.gov (Usenet)

In article <HMP.92Mar26140203@deimos.frc.ri.cmu.edu> hmp@frc2.frc.ri.cmu.edu (Henning Pangels) writes:
>
>Has anyone else observed this? 
>
>After a completed rlogin session to a vxWorks target, whoami on that
>target's console returns a null string. This happens even if I did
>nothing but rlogin and logout.

This has existed in VxWorks since version 5.0 (I believe). I spoke to customer
support about this last year, and they said it was a known problem. What I
don't understand is why it is still present in 5.0.2. You'd think that this
would be important enough and simple enough to be history already!

- --
		Todd Litwin
		Jet Propulsion Laboratory
		(818) 354-5028
		litwin@robotics.jpl.nasa.gov

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Low power VME termination
Date: 27 Mar 92 13:23:36 GMT
From: rg@msel.unh.edu (Roger Gonzalez)
Organization: UNH Marine Systems Engineering Lab
Message-ID: <RG.92Mar27082336@nymph.msel.unh.edu>
References: <1992Mar26.194044.23352@cs.cmu.edu>
Sender: news@nic.unh.edu (USENET News System)

>>>>> "Mike" == Mike Blackwell <mkb> writes:

Mike> I have a low power VxWorks real time system (Dynatem boards), and it turns
Mike> out that almost half of the power going in to the cage is eaten up by the
Mike> VME bus terminators. Since this is a battery powered system, this is an
Mike> important issue. Does anyone know of lower power terminators than the usual
Mike> bank of resistors? I was thinking maybe some sort of active termination. Any
Mike> advice or pointers would be much appreciated.

Mike> 		Mike Blackwell		mkb@cs.cmu.edu

This is typically the case with passive terminators.  Dynatem now sells a new
actively terminated backplane from Oettle+Reichler that sucks much less juice.
Just out of curiosity, are you using the Dynatem boards or the O+R boards that
Dynatem distributes?  We are using the 3U O+R boards.

- -Roger
- --
"The question of whether a computer can think is no more interesting
 than the question of whether a submarine can swim" - Edsger W. Dijkstra 

Roger Gonzalez   -  rg@msel.unh.edu
Division of Bit Banging and Reluctant Robotics
UNH Marine Systems Engineering Laboratory, Durham, NH  03824-3525
(603) 862-4600 -4399 (fax)

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: rlogin to a target clobbers remote user name
Date: 27 Mar 92 21:50:20 GMT
From: hwajin@mondo.iphasew.com (Hwa-Jin Bae)
Organization: /u/koosh/hwajin/.organization
Message-ID: <HWAJIN.92Mar27135020@mondo.iphasew.com>
References: <HMP.92Mar26140203@deimos.frc.ri.cmu.edu>
	<1992Mar26.235753.12827@elroy.jpl.nasa.gov>
Sender: hwajin@iphasew.com

the bugs is due to the new login security code which was added for 5.0
release.  workaround is to either enable INCLUDE_SECURITY in
usrConfig.c or make a call to loginUserAdd().  see loginLib manual.

*hwajin

---------------------------

Newsgroups: comp.os.vxworks
Subject: Share a room at user group meeting?
Date: 29 Mar 92 18:42:12 GMT
From: mkb+@cs.cmu.edu (Mike Blackwell)
Organization: School of Computer Science, Carnegie Mellon
Message-ID: <1992Mar29.184212.131752@cs.cmu.edu>

If you'd be interested in splitting a room at the user's group meeting at
Newport Beach, please send me mail.

		Mike Blackwell		mkb@cs.cmu.edu

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Low power VME termination
Date: Mon, 30 Mar 1992 17:17:37 GMT
From: rec@coquina.ucsd.edu (Richard Currier)
Organization: MPL of SIO at UCSD
Message-ID: <1992Mar30.171737.11397@chiton.ucsd.edu>
References: <1992Mar26.194044.23352@cs.cmu.edu>
Sender: news@chiton.ucsd.edu

In article <1992Mar26.194044.23352@cs.cmu.edu> mkb+@cs.cmu.edu (Mike Blackwell) writes:
>Does anyone know of lower power terminators than the usual
>bank of resistors? I was thinking maybe some sort of active termination. Any
>advice or pointers would be much appreciated.
>
Schroff Inc. makes backplanes with on-board active termination. They also
make plug-in, off-board active termination modules that may be used
with some non Shroff products. Many distributors will stare blankly at
you when you talk about "active termination" but it will save you
around an Amp of current draw.

	richard currier		marine physical lab	u.c. san diego
	rec@mpl.ucsd.edu
	619-534-1730

- -- 

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: RPCs and sockets
Date: Mon, 30 Mar 1992 21:04:36 GMT
From: sns@deimos.caltech.edu (Sam Southard Jr.)
Organization: Caltech Astronomy Department
Message-ID: <1992Mar30.210436.22129@cco.caltech.edu>
References:  <22298@dog.ee.lbl.gov>
Sender: news@cco.caltech.edu

In article <22298@dog.ee.lbl.gov>, lewis@bevsun.bev.lbl.gov (Steve Lewis) writes:
|> Several articles have raised questions concerning VxWorks speed both
|> at the socket level and at the RPC level.  I have made some performance
|> tests, although my notes are lost for the moment.  The best results were
|> obtained with a Sparcstation-2 against an MVME-147.  I tried many
|> combinations, including Sparc-Sparc, VME-VME across both Ethernet and
|> backplane.  Results were:
|>     (1) Maximum transactions rates of 550 very short (one long to RPC)
|> 	round-trips/sec.
|>     (2) Maximum throughput rates of 600KB/sec using very long (8000 bytes to
|> 	RPC) copying the data both ways.
|> 
|> I concluded that:
|>     (1) All all cases were cpu-limited, not medium limited.

You must not have tried very hard with the socket level performance (or I'm
reading your article incorrectly).  I've seen sustained (several hours)
throughputs of over 800KB/sec from a SPARCengine 1E to a SPARCserver 470 or
Sun 4/110.  What protocol were you using on the socket level?  I was using UDP.

- -- 

Sam Southard, Jr.
{sns@deimos.caltech.edu|{backbone}!cit-vax!deimos!sns}

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: gcc -ansi with 5.0
Date: 31 Mar 92 13:25:29 GMT
From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
Organization: Field Robotics Center, CMU
Message-ID: <HMP.92Mar31082529@squash.frc.ri.cmu.edu>
References: <9203302030.AA10443@cutter.ssd.loral.com>
Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)

I found that in moving to gcc (in the course of upgrading to vx5.0)
there were a few minor nuisances:

- - gcc (unlike cc) complains about missing parameters to functions, so
I had to go and stick in a lot of NULL parameters to satifsy the
compiler. OK, so they should have been there in the first place, but
they weren't.

- - Some of the vxWorks header files (and particularly the function prototypes
declared in them) are incorrect or incompatible. For instance, if you
include both fioLib.h and iosLib.h (I think those were the ones..),
you get duplicate and conflicting declarations of some function
prototypes. No big deal, although I hate having to modify files
supplied with the OS. It feels like voiding a warranty on a new stereo
by taking a soldering iron to it.

- - Some files wre shuffled around, like iv68k.h became 68k/iv.h. 

Everything I've described was very obvious and just required some
repetitious editing tasks to get things compiled, so I wasn't too
upset.

- -Henning

- --
Henning Pangels    |hmp@frc2.frc.ri.cmu.edu        |     Field Robotics Center
Research Programmer|(412) 268-7088                 |Carnegie-Mellon University
- ------------------------------------------------------------------------------
                     Fast, Cheap, Good: Choose Any Two

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: gcc -ansi with 5.0
Date: 31 Mar 92 17:14:33 GMT
From: sjk@strl.labs.tek.com (Steven King)
Organization: Software Technology Research Lab, Tektronix, Inc.
Message-ID: <3973@crl.LABS.TEK.COM>
References: <9203302030.AA10443@cutter.ssd.loral.com>
Followup-To: comp.os.vxworks
Reply-To: sjk@crl.labs.tek.com (Steven King)
Sender: news@crl.LABS.TEK.COM

In article <9203302030.AA10443@cutter.ssd.loral.com>, bard@cutter.ssd.loral.com (James Woodyatt) writes:

|> Okay, so I *finally* got some time to upgrade to version 5.0.2 and now
|> I've got some questions that are probably easily answered by somebody
|> on the exploder:
|> 
|> * What problems are there, if any, with using gcc-2.x with the object
|>   shipped from WRS?
|> 
|> * Can I really use the -ansi mode in gcc even though the PROM I'm
|>   burning is all compiled with -traditional?

You must use -traditional with any WRS supplied code.  They haven't 
ansi-fied their code yet.  My understanding is that they will use -ansi 
in the next release.

We mix objects compiled with -ansi and objects compiled with -tradtional
with no problems.

If you use bit-fields in structs, beware!  When we were using the compiler
supplied with 5.0, with the -ansi and -volatile switches, the compiler would
emit incorrect bit-field instructions for the 68k.  We ended up combing through
the code and declaring things as volatile.  Using -ansi worked for this case.
This problem may be fixed in gcc 2.0.

I recommend that you use -traditional until you correct for the WRS
changes in 5.0.2, and then use -ansi.  This will reduce the number of
factors that could cause headaches.

Steven

- ----------------------------------------------------------------------
e-mail: sjk@strl.labs.tek.com      |  Steven King
phone: 503-627-2736                |  Software Technology Research Lab
voice mail: 503-727-6651           |  Tektronix, Inc.
fax: 503-627-5502                  |  P.O. Box 500   MS 50-662
			           |  Beaverton, OR  97077
- ----------------------------------------------------------------------

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: RPCs and sockets
Date: 1 Apr 1992 16:11:16 GMT
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Organization: Lawrence Berkeley Laboratory, California
Message-ID: <22420@dog.ee.lbl.gov>
References: <22298@dog.ee.lbl.gov> <1992Mar30.210436.22129@cco.caltech.edu>

In article <1992Mar30.210436.22129@cco.caltech.edu> sns@deimos.caltech.edu (Sam Southard Jr.) writes:
>In article <22298@dog.ee.lbl.gov>, lewis@bevsun.bev.lbl.gov (Steve Lewis) writes:
>> Several articles have raised questions concerning VxWorks speed both
>> at the socket level and at the RPC level.  I have made some performance
>> tests, although my notes are lost for the moment.  The best results were
>> obtained with a Sparcstation-2 against an MVME-147.  I tried many
>> combinations, including Sparc-Sparc, VME-VME across both Ethernet and
>> backplane.  Results were:
>>     (1) Maximum transactions rates of 550 very short (one long to RPC)
>> 	round-trips/sec.
>>     (2) Maximum throughput rates of 600KB/sec using very long (8000 bytes to
>> 	RPC) copying the data both ways.

>> I concluded that:
>>     (1) All all cases were cpu-limited, not medium limited.

>You must not have tried very hard with the socket level performance (or I'm
>reading your article incorrectly).  I've seen sustained (several hours)
>throughputs of over 800KB/sec from a SPARCengine 1E to a SPARCserver 470 or
>Sun 4/110.  What protocol were you using on the socket level?  I was using UDP.

The above tests were using UDP based Sun-RPC with XDR.  No particular
performance tuning was done, and the code used the RPC library, not dealing
with the sockets (if I remember correctly).  The object was to measure the
capability of the RPC system, not to tweak throughput.  The MVME-147 is 
likely not as quick as a SPARC 1E, and 600/800 KB/sec is a small difference.
I think this clearly illustrates that XDR gets a worse rap than it deserves.

    Alan K Biocca			WB6ZQZ

    Computer Controls Group		AKBiocca@lbl.gov
    Computer Systems Engineering Dept	MS 64-121
    Lawrence Berkeley Laboratory	510/485-7700
    Berkeley, CA 94720			501/486-5788 fax

- --------

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: gcc -ansi with 5.0
Date: Wed, 1 Apr 1992 17:57:49 GMT
From: geoff@wrs.com (Geoff Espin)
Organization: Wind River Systems, Inc.
Message-ID: <geoff.702151069@wrs.com>
References: <9203302143.AA04795@hns.com>
Sender: usenet@wrs.com (News Manager)

Carl and VxUsers,  :-)

symborski@hns.com (Carl Symborski) writes:
>>* Has anybody had to modify their code to get it work under 5.0 because
>>  a programmer's interface changed? What trouble could I conceivably
>>  encounter in porting my code from 4.0.2 to 5.0.2 as a result of some
>>  goofy programmer in my shop using some weird feature of VxWorks that
>>  isn't supported in 5.0 anymore? (I've got a crawling horror on my
>>  hands that was originally developed under 3.0, I think.)

>As I recall the renaming of certain "sys" functions to "vx" functions
>were particularly irksome.  Especially if you are maintaining a bunch of
>device drivers.  It has been a while but we did get bit by the following:

>16jul91,gae  changed sysIMR->vxIMR and sysIPNDBitClear->vxIPNDClear

Gosh am I, Geoffrey A. Espin (gae) the "goofy programmer" over here?

The intent of the these changes was to push the architecture level
functions (in this case i960) out of the Board Support Package.
My personal apology for the incompatibility, "Sorry".

The rationale was:

1. Documentation of architecture specific functions should appear
in one consistent place.  Of course, WRS still has separate 5.0.[2,3,4]
releases for different arch's so presently it is not ideal shifting
from the 68K -centric Programmer&Reference Manual to the RISC supplements.

2. The code was reproduced and was completely redundant in the
the original 3 BSPs, the tp960, hkv960, and cvme960.  Perhaps
to a customer this isn't significant as you are probably only
using 1 brand name board.  For WRS it is a maintenance nightmare.
VxWorks is still very "close to the bare metal" -- BSPs and arch's
do offer special features that you do want to customize around.
The application engineer should try to isolate such h/w dependencies
in a separate module when possible.  We did weigh in the impact on
a few dozen 4.0.2 users versus the future thousands of 5.x.x users.  :-)

3. Why didn't we do it right the first time?  Evolution.
WRS's original motto was "VxWorks: a Revolution in Realtime",
in between times, you better evolve or you'll fossilize.  :-)
I mean to say, that, unfortunately, there are a wealth of design
deficiencies in certain areas, particularly BSPs.  I say this
having been the BSP Group Leader for a few years (not presently),
and being, for good or for bad, the final arbiter on many of
these crufty implementations.  Hate mail to me alone.
Our number one priority for many years had been simply to get
a new BSP out the door; re-thinking the BSP paradigm always gave
way to new ports and then the worry about backward compatibility.

So, Carl, I hope I came back to your point of "compatability between
versions".  WRS does make this as an important goal.  Like many
S/W companies, it is often reactive "how do we get our butts out
of this one", instead of proactive, "let's design this right for
the next 20 years" but at the expense of much delayed product shipment.
Hopefully, we at least document the "corrections".  Hopefully,
you are getting a better product.  If not, let us know!

Geoff

- --

- ---
Geoff Espin		geoff@wrs.com	(510)748-4100
Wind			River		Systems

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: exabyte.h file
Date: 1 Apr 92 20:11:06 GMT
From: brunner@kazoo.ssd.loral.com (Brian Brunner)
Organization: Space Systems/Loral
Message-ID: <1992Apr1.121106@kazoo.ssd.loral.com>
References: <9203310201.AA09593@bach.jhuapl.edu>
Reply-To: brunner@kazoo.ssd.loral.com (Brian Brunner)
Sender: news@wdl.loral.com

Could some kind soul please e-mail me the exabyte.c file this goes to?
I lost mine.

- --
HELP!! Somebody slapped a "stop payment" on my sanity check!!
brunner@kazoo.ssd.loral.com; Space Systems/Loral; Palo Alto, Calif.
Black Holes... the /dev/null of the Universe; the opinion of 65534.

---------------------------

Newsgroups: comp.os.vxworks
Subject: TCP Bandwith on VxWorks
Date: 1 Apr 92 23:40:01 GMT
From: mwm40@tony.ccc.amdahl.com (Marcelo W Mourier)
Organization: Amdahl Corporation, Sunnyvale CA
Message-ID: <0dfW028U0fSC01@JUTS.ccc.amdahl.com>
Sender: netnews@ccc.amdahl.com

Does anybody know what's the maximum data throughput achivable at the socket
(TCP) interface in VxWorks.  As this figure depends highly on the particular
hardware used, please specify the type and speed of CPU and network.

Thanks!

- ----
Marcelo Mourier

---------------------------

Newsgroups: comp.os.vxworks
Subject: WANTED: Bay Area VxWorks person - contract work
Date: 1 Apr 92 18:56:36 GMT
From: ksh@vine.COM (Kent S. Harris)
Organization: Vine Technology, Cupertino, CA
Message-ID: <3622@vine.COM>

I have a tentative contract for a VxWorks device driver.
Please give me a call.  Must be in SF Bay area (South Bay
preferred).

Kent S. Harris
Vine Technology
408-996-1294

- -- 
Kent S. Harris    ...!ames!vine!ksh    CONSULTING: Real-time system h/w & s/w,
Vine Technology   (ksh@vine.com)          software development tools, project
(408)996-1294     22 yr EE/CS exp.        analysis, information modeling.

---------------------------

End of New-News digest
**********************

From rayssd!ss4u02.ssd.ray.com!fjr@uunet.uu.net  Thu Apr  2 06:12:08 1992
From: "Roeber" <fjr@ss4u02.ssd.ray.com>
Date: Thu Apr  2 06:12:20 PST 1992
Subject: Re:  Slip & flow control
>  1- First question: SLIP and flow control
>  ----------------------------------------
>  
>  We are using SLIP over a serial radio modem link and
>  it seems that SLIP does not handle RTS / CTS protocol.
>  This increases the number of retransmissions when our
>  modem is overloaded and sometimes leads to connection breaks. 
>  
>  I tried to modify the hardware  initialization in "tyCoInitChannel":
>  
>  *cr = SCC_WR0_SEL_WR3;		/* write reg 3 - receiv
>  *cr = SCC_WR3_RX_8_BITS | SCC_WR3_RX_EN | SCC_WR3_AUTO_EN;
>                                          ------------------ <- my modification

I assume you are using some Zilog serial interface?  The Z84C40?  Have you
checked out the ZILOG application note on async communication?  On page
545 of the ZILOG Intelligent Peripheral Controllers book is the picture
of how to handle auto enables in HW.  You need DCD and DTR connected in
addition to RTS CTS.  Good Luck.   Fred

    ______________________________________________________________
   |  Fred J Roeber,  Raytheon Submarine Signal Division          |
   |  1847 West Main Road,  Mail Stop 188                         |
   |  Portsmouth, RI  02871-1087  (401) 847-8000 (X4205)          |
   |                                                              |
   |      {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr             |
   |______________________________________________________________|

From sharpster@hns.com  Thu Apr  2 06:25:40 1992
From: sharpster@hns.com (Stephen Harpster)
Date: Thu Apr  2 06:25:47 PST 1992
Subject: Re: porting to VxWorks
I'm currently working on a POSIX layer that sits between VxWorks and our
applications.  The idea is to do just what you are attempting: to use
POSIX-conforming applications with VxWorks.  (Yes, I've heard that
VxWorks is moving towards POSIX, but the timeframe seems shaky.)

All in all it isn't too bad.  A lot of functions, are just inline routines that 
rearrange the parameters or rename the function.  Here's a freebie:

	extern inline pid_t
	getpid(void)
	{
		return (pid_t) taskIdSelf();
	}

The only time things get tough is when you try to map the not-standard-yet POSIX
things to VxWorks (like 1003.4 - realtime extensions and 1003.4a - threads).
So the above could also be (more correctly)

	extern inline pthread_t
	pthread_self(void)
	{
		return (pthread_t) taskIdSelf();
	}

The problem isn't VxWorks, it's the drafts changing.  The only two things to
do are

	1. Wait until the drafts become standard.

	2. Pick one draft and design against it.

We've decided on #2.  Later releases of our "product" will bring it up to either
the standard (when it becomes one), or at least a later draft.  
-- 
Stephen Harpster
Hughes Network Systems
sharpster@hns.com

From iphasew!hwajin@apple.com  Thu Apr  2 12:44:49 1992
From: hwajin@iphasew.com (Hwa-Jin Bae)
Date: Thu Apr  2 12:44:57 PST 1992
Subject: Re: Sockets and clocks.
>The downside, of course, is these addr's are the Ethernet chip
>addresses instead of something more easily determined such as internet
>addresses & aliases. 

A new routine etherAddrResolve() has been added to VxWorks 5.0 to
help ease this problem.

--
Hwa-Jin Bae
Interphase West

From iphasew!hwajin@apple.com  Thu Apr  2 12:45:42 1992
From: hwajin@iphasew.com (Hwa-Jin Bae)
Date: Thu Apr  2 12:45:51 PST 1992
Subject: BOOTP

>12f,07may90,hjb  added support for BOOTP forwarding.

The BOOTP forwarding code started up a forwarder on gateway target
for BOOTP traffic between backplane targets and the server.  As you
already know, the relevant code was subsequently deleted before 5.0
made out to door.  Hang in there, I think WRS probably has something
planned for the next release.

--
Hwa-Jin Bae
Interphase West

From iphasew!hwajin@apple.com  Thu Apr  2 12:50:01 1992
From: hwajin@iphasew.com (Hwa-Jin Bae)
Date: Thu Apr  2 12:50:11 PST 1992
Subject: Re: SLIP & flow control
VxWorks SLIP implementation uses read() and write() routines for character 
I/O.  The lowest tty-related level SLIP driver touches is the "protocol
hook" related part in tyLib code which sits on top off various board-
specific tyCoDrv.c.  SLIP driver doesn't care what tyCoDrv does, and 
contrary to messages posted a while back, SLIP can work over a number of
different point-to-point links -- asynchronous, synchronous, customized
link hardware, and I know at least one user who wrote a parallel port
driver and adapted it for SLIP under VxWorks.

Regarding :

>      UNIX gateway
> ---  
>|   |---| radio modem |
> ---
>  |
>-----------------------------------
>                   | ethernet
>                   |
>                   |
>               --------------------------
>              |  CPU1  | CPU2 | ... CPU4 |   CPUi: MV147
>               --------------------------
>                |            VME bus
>      UNIX gateway
 ---  

Does the CPU1 still think that ethernet interface is UP and RUNNING?
Just removing ethernet cable is not enough.  Do ifShow() to find out.
You will need to at least mark the network interface down by doing
ifFlagChange().  You will also need to delete any routing table entry
that refers to the ethernet interface.  Do routeShow() and delete
such entries with routeDelete().

--
Hwa-Jin Bae
Interphase West

From daemon@vxw.ee.lbl.gov  Fri Apr  3 04:00:34 1992
From: daemon@vxw.ee.lbl.gov
Date: Fri Apr  3 04:00:42 PST 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Apr  3 04:00:27 PST 1992

        Subject: Re: TCP Bandwith on VxWorks
        Subject: Motorola MVME 167
        Subject: Intermittent Failure

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: TCP Bandwith on VxWorks
Date: 2 Apr 92 15:11:32 GMT
From: davew@dslsn1.lampf.lanl.gov (David Whitehouse)
Organization: Digital Equipment Corporation
Message-ID: <1992Apr2.151132.7407@newshost.lanl.gov>
References: <0dfW028U0fSC01@JUTS.ccc.amdahl.com>
Reply-To: davew@dslsn1.lampf.lanl.gov (David Whitehouse)
Sender: news@newshost.lanl.gov

In article <0dfW028U0fSC01@JUTS.ccc.amdahl.com>, mwm40@tony.ccc.amdahl.com (Marcelo W Mourier) writes:
|> Path: lanl!hellgate.utah.edu!dog.ee.lbl.gov!network.ucsd.edu!usc!zaphod.mps.ohio-state.edu!qt.cs.utexas.edu!yale.edu!jvnc.net!darwin.sura.net!europa.asd.contel.com!uunet!charon.amdahl.com!amdahl!JUTS!tony.ccc.amdahl.com
|> From: mwm40@tony.ccc.amdahl.com (Marcelo W Mourier)
|> Newsgroups: comp.os.vxworks
|> Subject: TCP Bandwith on VxWorks
|> Message-ID: <0dfW028U0fSC01@JUTS.ccc.amdahl.com>
|> Date: Wed, 1 Apr 92 16:40:01 GMT-0:03
|> Sender: netnews@ccc.amdahl.com
|> Distribution: usa
|> Organization: Amdahl Corporation, Sunnyvale CA
|> Lines: 8
|> 
|> Does anybody know what's the maximum data throughput achivable at the socket
|> (TCP) interface in VxWorks.  As this figure depends highly on the particular
|> hardware used, please specify the type and speed of CPU and network.
|> 
|> Thanks!
|> 
|> ----
|> Marcelo Mourier
|> 

I am also interested in these results, it would also be useful to have the 
CPU usage for both the sending and receiving computers.

Thanks,

David Whitehouse

---------------------------

Newsgroups: comp.os.vxworks
Subject: Motorola MVME 167
Date: 2 Apr 92 23:24:50 GMT
From: davew@dslsn1.lampf.lanl.gov (David Whitehouse)
Organization: Los Alamos National Laboratory
Message-ID: <1992Apr2.232450.4305@newshost.lanl.gov>
Reply-To: davew@dslsn1.lampf.lanl.gov (David Whitehouse)
Sender: news@newshost.lanl.gov

Hello,

My group is considering purchasing VxWorks for use with a VME based data 
acquisition system using MVME 167 monoboards. Since the support for the MVME 167 
is rather new I would be interested in hearing from anyone who has used VxWorks
with the MVME 167. Please reply by email.

Thanks,

David Whitehouse

---------------------------

Newsgroups: comp.os.vxworks
Subject: Intermittent Failure
Date: Thu, 2 Apr 1992 23:29:57 GMT
From: blue@forsight.jpl.nasa.gov (Randel Blue)
Organization: Jet Propulsion Laboratory
Message-ID: <1992Apr2.232957.2995@elroy.jpl.nasa.gov>
Sender: news@elroy.jpl.nasa.gov (Usenet)

I sometimes get a cryptic message from vxWorks, both 4.0.2
and 5.0.2, that I have not been able to figure out. The target 
is a Heurikon HKV3F (68030). This message appears sometimes at
boot time and less frequently while running my application, and
at times even when the machine is just siting idle. The text of the message
is:

RUStart: RU unexpectedly not idle - aborting.

scb 0x1f4534 (Magic OK): fr rnr
cuc=nop ruc=nop cus=idle rus=out of resources (RBD)
cbl=0x1e730e rfa=0x1f3e44 tfdhd:0x1e7368, rfdhd:0x1f3e44
Counters: crc=0x0 aln=0x0 rsc=0xb ovrn=0x0 cdt=0x0 shrt=0x0

If anyone can explain the cause and prevention of this condition
I would be very grateful.

Randy Blue JPL

---------------------------

End of New-News digest
**********************

From rayssd!ss4u02.ssd.ray.com!fjr@uunet.uu.net  Fri Apr  3 08:14:01 1992
From: "Roeber" <fjr@ss4u02.ssd.ray.com>
Date: Fri Apr  3 08:14:10 PST 1992
Subject: Compiler option problems
Greetings,

  We are trying to figure out how to handle a subtle compiler problem with the
GCC compiler used with VxWorks and are wondering if
anyone else has run into it.  The problem has to do with how driver and
configuration files are compiled.  As delivered, configuration files are
compiled with the the optimization switches:
  -O -fvolatile
This says optimize things (-O) but don't remove accesses to anything that is
referenced through a pointer (-fvolatile).  The volatile part is important
since you don't want the compiler removing code that, for instance, reads 
the same hardware register multiple times to retrieve different values.
Without the -fvolatile the optimizer could eliminate such code.
   The problem comes in because the compiler generates stupid code for certain
types of statements when these options are used.  For this whole discussion,
the same sample code below will be used:

   #define REG1 (char *)0x5000
   #define REG2 (long *)0x6000

   test()
   {
        *REG1 |= 10;
        *REG2 |= 1000;
   }

This code code be code for updating control bits in various hardware control
registers.  When controlling hardware, this sort of code can be quite common.
Note that one register is a single byte and one is a long word (32 bits).  When
this code is compiled with the -O -fvolatile switches, the following code is
generated:

_test:
        .stabd 68,0,5
        link a6,#0
        .stabd 68,0,7
        movew #20480,a0		/* FIRST REGISTER */
        moveb a0@,d0
        orb #10,d0		/* POINT 1 */
        moveb d0,a0@
        .stabd 68,0,8
        movew #24576,a0		/* SECOND REGISTER */
        movel a0@,d0
        orw #1000,d0
        movel d0,a0@
        .stabd 68,0,9
        unlk a6
        rts

While this code works, it could introduce serious problems in certain cases
since the hardware register is read, updated, and written back.  If an
interrupt occured at POINT 1, for instance, and the interrupt code updated a
different bit of the same register, that update would be lost when the
interrupt completed and the code wrote the register back out to the hardware.
We originally noticed this problem resulting in spurious serial communication
problems with one of our boards since control bit changes were (infrequently)
getting lost.  To get around it we compiled the code with no optimization
yielding the following code:

_test:
        .stabd 68,0,5
        link a6,#0
        .stabd 68,0,7
        orb #10,20480:w		/* FIRST REGISTER */
        .stabd 68,0,8
        orw #1000,24578:w	/* SECOND REGISTER */
        .stabd 68,0,9
L1:
        unlk a6
        rts

Note that for the first register, this code solves the problem since the
hardware register is updated in one atomic instruction.  Since our terminal
device had all byte wide registers this was a perfect solution.  The
problem came in when we went to a different board that had some devices that
could only be accessed as long word values.  This is like the second register.
Looking at the code generated in this case, we saw that it was wrong.  In its
infinite wisdom, the compiler was only updating the 2nd 16 bit half of our
long word register. This didn't work and caused a bus error.
  From this, it seems that we must use the -fvolatile switch to get code that
works at all.  The code, however, can cause unreliable operation.  We are
caught between a rock and a hard place.  The big question is whether anyone
else has run into this and what they have done about it?
  For completeness, compiling the code with just the -O option yields:

_test:
        .stabd 68,0,5
        link a6,#0
        .stabd 68,0,7
        orb #10,20480:w
        .stabd 68,0,8
        orw #1000,24578:w
        .stabd 68,0,9
        unlk a6
        rts

Same problem as without optimization.
  Any ideas????     Fred

    ______________________________________________________________
   |  Fred J Roeber,  Raytheon Submarine Signal Division          |
   |  1847 West Main Road,  Mail Stop 188                         |
   |  Portsmouth, RI  02871-1087  (401) 847-8000 (X4205)          |
   |                                                              |
   |      {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr             |
   |______________________________________________________________|

The statement was adding a new bit value to a specific hardware control
register.  If the same code is compiled with no optimization what the compiler
produces is:

        .stabd 68,0,1221
        orw #1024,67108926

From stan@rti.com  Fri Apr  3 15:59:29 1992
From: stan@rti.com (Stan Schneider)
Date: Fri Apr  3 15:59:36 PST 1992
Subject: Re:  Compiler option problems

>>    #define REG1 (char *)0x5000
>>    #define REG2 (long *)0x6000
>> 
>>    test()
>>    {
>>         *REG1 |= 10;
>>         *REG2 |= 1000;
>>    }
>> 
>> ...with the -O -fvolatile switches... While this code works, it could
>> introduce serious problems in certain cases since the hardware register
>> is read, updated, and written back.  
>>
>> ...without -fvolatile...
>> Note that for the first register, this code solves the problem since the
>> hardware register is updated in one atomic instruction. 

The "volatile" declaration is intended precisely for this type of application.  I don't think you should be trying to get around it.

Code that depends on atomic instruction execution to avoid interrupt
interactions seems risky and non-portable at best.  How about just using
intLock?  Are your latency requirements that critical?  This will also prevent the possible problem of register sets that may be dependent (i.e. if REG1 and REG2 have to have consistent values.

        -- Stan

===============================================================================
=                                           =                                 =
=   Stan Schneider                          =   email: stan@rti.com           =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312         =
=   954 Aster, Sunnyvale, CA 94086          =   Fax:   (408) 720-8419         =
=                                           =                                 =
===============================================================================

From daemon@vxw.ee.lbl.gov  Sat Apr  4 04:00:35 1992
From: daemon@vxw.ee.lbl.gov
Date: Sat Apr  4 04:00:43 PST 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Apr  4 04:00:28 PST 1992

        Subject: Re: Compiler option problems
        Subject: PEP 3U VME Cards

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Compiler option problems
Date: 3 Apr 92 18:45:32 GMT
From: sjk@strl.labs.tek.com
Organization: Software Technology Research Lab, Tektronix, Inc.
Message-ID: <4019@crl.LABS.TEK.COM>
References: <9204031525.AA04096@ss4u02.ssd.ray.com>
Reply-To: sjk@crl.labs.tek.com (Steven King)
Sender: news@crl.LABS.TEK.COM

In article <9204031525.AA04096@ss4u02.ssd.ray.com>, fjr@ss4u02.ssd.ray.com (Roeber) writes:

|> Greetings,
|> 
|>   We are trying to figure out how to handle a subtle compiler problem with the
|> GCC compiler used with VxWorks and are wondering if
|> anyone else has run into it.  The problem has to do with how driver and
|> configuration files are compiled.  As delivered, configuration files are
|> compiled with the the optimization switches:
|>   -O -fvolatile
|> This says optimize things (-O) but don't remove accesses to anything that is
|> referenced through a pointer (-fvolatile).  The volatile part is important
|> since you don't want the compiler removing code that, for instance, reads 
|> the same hardware register multiple times to retrieve different values.
|> Without the -fvolatile the optimizer could eliminate such code.
|>    The problem comes in because the compiler generates stupid code for certain
|> types of statements when these options are used.  For this whole discussion,
|> the same sample code below will be used:
|> 
|> 
|>    #define REG1 (char *)0x5000
|>    #define REG2 (long *)0x6000
|> 
|>    test()
|>    {
|>         *REG1 |= 10;
|>         *REG2 |= 1000;
|>    }

Have you tried:

    test()
        {
	asm ("movew #20480,a0");
	asm ("orb #10,a0@");
	asm ("movew #24576,a0");
	asm ("orl #1000,a0@");
        }

or:

    test()
        {
        int intKey;

        intKey = intLock();
        *REG1 |= 10;
        *REG2 |= 1000;
        intUnlock(intKey);
        }

Sometimes you just have to bite the bullet when dealing with devices.
It always pays to look at the disassembled code to see if it is really
talking to the hardware in the correct manner.  After a few go-rounds,
you'll know what works and what doesn't.  Welcome to the wonderful world 
of controlling bit-mapped I/O with C!  ;^)

Steven

- ----------------------------------------------------------------------
e-mail: sjk@strl.labs.tek.com      |  Steven King
phone: 503-627-2736                |  Software Technology Research Lab
voice mail: 503-727-6651           |  Tektronix, Inc.
fax: 503-627-5502                  |  P.O. Box 500   MS 50-662
			           |  Beaverton, OR  97077
- ----------------------------------------------------------------------

---------------------------

Newsgroups: comp.os.vxworks
Subject: PEP 3U VME Cards
Date: 3 Apr 92 19:52:46 GMT
From: shi@frc2.frc.ri.cmu.edu (WenFan Shi)
Organization: Field Robotic Center, CMU
Message-ID: <SHI.92Apr3145246@hay.frc.ri.cmu.edu>
Reply-To: shi@frc2.frc.ri.cmu.edu (Wenfan Shi)

Hello,

Is there anyone have experience with PEP 3U VME cards and VxWorks
software supports? any ups and down? I am especially concern about
software device drivers, how robust it is, and how long since PEP
support VxWorks in general or the boards you are using. Email is
preferd. Thank you in advance!

- -wenfan
- --
Wenfan Shi        Research Programmer             Field Robotics Center
ARPAnet/Internet: shi@frc2.frc.ri.cmu.edu         Robotics Institute
Office:  (412) 268-6558                           Carnegie-Mellon University
Home:    (412) 621-3153                           Pittsburgh, PA. 15213

---------------------------

End of New-News digest
**********************

From daemon@vxw.ee.lbl.gov  Mon Apr  6 04:00:24 1992
From: daemon@vxw.ee.lbl.gov
Date: Mon Apr  6 04:00:32 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Mon Apr  6 04:00:16 PDT 1992

        Subject: Re: select problems
        Subject: Re: TCP Bandwith on VxWorks
        Subject: Re: Intermittent Failure

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: select problems
Date: Sun, 5 Apr 1992 03:49:13 GMT
From: rypma@hppad.waterloo.hp.com (Ted Rypma)
Organization: HP Panacom Div Waterloo ON Canada
Message-ID: <27550005@hppad.waterloo.hp.com>
References: <9203280034.AA01155@comtec.UUCP>

From some of our internal notes.  This may be of some help.

Ted Rypma
HP Panacom Division

This basenote provides an overview on how to use the new VxWorks 5.0 select()
facilities. The discussion is targetted for developers of VxWorks IO System
compliant device drivers. Its assumed that you know how the VxWorks IO System
works and how you tie in your device driver into the IO system. If you
don't, there is some rather pleasant reading that you should do in Chapter 4
of the VxWorks 5.0 Programmers Guide, and in particular, all of subsection 4.9.

First of all, the selectLib library has these routines that you need to be
aware of:

- - selectInit(): initialaizes the select() library,
- - select()
- - selWakeup(): wake up a pended task in select(),
- - selWakeupAll(): wake up all tasks on a select() wake up list,
- - selNodeAdd(): add a wakeup node to the select wakeup list,
- - selNodeDelete(): remove a wakeup node
- - selWakeupListInit(): initialize a list of nodes,
- - selWakeupListLen(): gets number of nodes in the wakeup list,
- - selWakeupType(): type of wakeup node.

If you want the detailed guts of the above functions, see the VxWorks 5.0
Reference Manual.

The first thing you do is make sure that selectLib is initialized by
calling selectInit(). This should be done ONCE and ONLY ONCE. It should be
done in usrRoot() in usrConfig.c, for example.

A driver must include selectLib.h if the select() facilities are to be used.

Each driver must declare a structure that contains the wakeup nodes. This
is a list of type SEL_WAKEUP_LIST and should be a part of the device
descriptor data structure. Its important that it be here since the driver
code may be installed as a number of different devices, all being of the
same driver type, and each instance of the device will manage its own device
descriptor data structure block. This preserves code re-entrancy. 

So to accomplish this, the device driver xxDevCreate() entry call must call
selWakeupListInit() to intialize the device's wakeup list structure:

         SEL_WAKEUP_LIST *pWakeupList;
      
         selWakeupListInit (pWakeupList);

In the device driver interrupt handler, when the device is ready for writing,
it should call:

         selWakeupAll (pWakeupList, SELWRITE);

In the device driver interrupt handler, when the device has data for reading,
it should call:

         selWakeupAll (pWakeupList, SELREAD);

That takes care of the interrupt handlers.

The device driver xxIoctl() entry must support two new io contols:

- - FIOSELECT
- - FIOUNSELECT

When an application calls select() with the fd set for this device, the
select() service calls the device's xxIoctl(..,FIOSELECT,..) to arm the
device for responding with the desired IO action. The device driver will
do the following in FIOSELECT:

         /* add the pending caller info to the select wakeup list of
            this device driver */
         selNodeAdd (pWakeupList, (SEL_WAKEUP_NODE *)arg);

         /* now check if we already have the right conditions for the
            original caller to continue IO. If the conditions are met,
            notify the pended caller via selWakup(). Doing this here
            just takes care of the case where the driver is ready to
            go and the caller calls select(). It allows an immediate
            result to be returned to the caller. */
         if (selWakupType ((SEL_WAKEUP_NODE *)arg) == SELREAD) &&
             thereIsDataToRead)
             selWakeup ((SEL_WAKEUP_NODE *)arg);
         if (selWakupType ((SEL_WAKEUP_NODE *)arg) == SELWRITE) &&
             thereIsRoomToWrite)
             selWakeup ((SEL_WAKEUP_NODE *)arg);

If the device doesn't meet the above conditions, the interrupt handler(s)
will wakeup the pended caller when data is available by calling selWakeupAll().

After a select completes due to a timeout or because data is available, the
io control entry for FIOUNSELECT is called to remove the caller wakeup node
from the device wakeup list. FIOUNSELECT will do:

         selNodeDelete (pWakeupList, (SEL_WAKEUP_NODE *) arg);

That's what you gotta do. Please note, this stuff hasn't been tested yet.
It's just my current understanding, so please no flames :-)

(With thanks to Louis Gaiot)

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: TCP Bandwith on VxWorks
Date: Sun, 5 Apr 1992 03:56:30 GMT
From: rypma@hppad.waterloo.hp.com (Ted Rypma)
Organization: HP Panacom Div Waterloo ON Canada
Message-ID: <27550006@hppad.waterloo.hp.com>
References: <0dfW028U0fSC01@JUTS.ccc.amdahl.com>

> Does anybody know what's the maximum data throughput achivable at the socket
> (TCP) interface in VxWorks.  As this figure depends highly on the particular
> hardware used, please specify the type and speed of CPU and network.

We get between 600 and 700 Kbytes/sec with a 25 MHz Intel i960 processor and an
Intel 82596 LAN controller. We haven't measured the CPU overhead, but at this
data rate there appears to be enough horsepower left to do other things.

Ted Rypma
HP Panacom Division

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Intermittent Failure
Date: Mon, 6 Apr 1992 01:29:12 GMT
From: rypma@hppad.waterloo.hp.com (Ted Rypma)
Organization: HP Panacom Div Waterloo ON Canada
Message-ID: <27550007@hppad.waterloo.hp.com>
References: <1992Apr2.232957.2995@elroy.jpl.nasa.gov>

> I sometimes get a cryptic message from vxWorks, both 4.0.2
> and 5.0.2, that I have not been able to figure out. The target 
> is a Heurikon HKV3F (68030).
.
.
> RUStart: RU unexpectedly not idle - aborting.
>
> scb 0x1f4534 (Magic OK): fr rnr

I can't explain it, but I can tell you where it's coming from...

The ethernet controller sounds like it is an Intel 82596 (or pretty close).
The way the driver is written, it must be shutting off the LAN controller
receive unit from time to time, and is not being successful when your
message is issued.

I would suspect an ethernet or a driver problem. (I remember seeing
similar messages from our hkv960 version when we were working on the
driver.)

Ted Rypma
HP Panacom Division

---------------------------

End of New-News digest
**********************

From Christina_Goette@mac_smtp.wrs.com  Mon Apr  6 09:45:51 1992
From: Christina_Goette@mac_smtp.wrs.com (Christina Goette)
Date: Mon Apr  6 09:45:59 PDT 1992
Subject: West Coast Users Meeting
                       Subject:                               Time:8:41 AM
  OFFICE MEMO          West Coast Users Meeting               Date:4/6/92
Just one last reminder that the next VxWorks Users Group meeting is this
Friday, April 10, 1992 in Newport Beach.  The meeting, chaired by Steven King
with Tektronix, will run from 8:30 am to about 4:30 pm.  In addition to
presentations by Wind River Systems representatives covering WRS, VxWorks and
POSIX status, users will be making applications and issues presentations.

The meeting will be held  at the Newport Beach Marriott, 900 Newport Center,
Newport Beach, CA  92660  714/640-4000.

There is a $50 registration fee to attend the meeting which may be paid at the
door with Visa, Mastercard, check or cash.

If you are interested in attending, please contact me via email at tina@wrs.com
or at 1-800-545-9463 for more information.

Christina Goette

From rayssd!ss4u02.ssd.ray.com!fjr@uunet.uu.net  Mon Apr  6 20:30:38 1992
From: "Roeber" <fjr@ss4u02.ssd.ray.com>
Date: Mon Apr  6 20:30:46 PDT 1992
Subject: Re:  Compiler option problems

>  Newsgroups: comp.os.vxworks
>  Subject: Re: Compiler option problems
>  Date: 3 Apr 92 18:45:32 GMT
>  From: sjk@strl.labs.tek.com
>  Organization: Software Technology Research Lab, Tektronix, Inc.
>  Message-ID: <4019@crl.LABS.TEK.COM>
>  References: <9204031525.AA04096@ss4u02.ssd.ray.com>
>  Reply-To: sjk@crl.labs.tek.com (Steven King)
>  Sender: news@crl.LABS.TEK.COM
>  
>  In article <9204031525.AA04096@ss4u02.ssd.ray.com>, fjr@ss4u02.ssd.ray.com (Roeber) writes:
>  
>  |> Greetings,
>  |> 
>  |>   We are trying to figure out how to handle a subtle compiler problem
>  |> with the GCC compiler used with VxWorks
..
>  
>  Have you tried:
>  
>      test()
>          {
>  	asm ("movew #20480,a0");
>  	asm ("orb #10,a0@");
>  	asm ("movew #24576,a0");
>  	asm ("orl #1000,a0@");
>          }
>  
>  or:
>  
>      test()
>          {
>          int intKey;
>  
>          intKey = intLock();
>          *REG1 |= 10;
>          *REG2 |= 1000;
>          intUnlock(intKey);
>          }
>  
>  Sometimes you just have to bite the bullet when dealing with devices.
>  It always pays to look at the disassembled code to see if it is really
>  talking to the hardware in the correct manner.  After a few go-rounds,
>  you'll know what works and what doesn't.  Welcome to the wonderful world 
>  of controlling bit-mapped I/O with C!  ;^)

The reason I brought up this problem was mainly to see how people were dealing
with the fact that all the configuration code is by default compiled with the
"-O -fvolatile" switches.  As I showed, using these switches can cause code
to be generated that will result in execution errors if interrupts occur
at the wrong time.  Specifically, there are problems with any of the config
code that can run at interrupt and task level, possibly concurrently, that
uses the "|=" or "&=" assignment statements.  My feeling is that this could
be the cause of some of the infrequent glitches people see when running
VxWorks.  I was sort of hoping that some of the Wind River people who had
thought this stuff through would chime in.  I say the compiler is busted and
should be fixed but Richard Stallman (who wrote gcc) wasn't too interested
(although he said the problem is likeley in code in the combine.c routine).
I have seen some good suggestions for fixing the erroneous code (like that
above).  The question is how to attack the problem since it crosses all the
BSPs.  Also, the drv source code is compiled with the same options.  That
means that the various SCSI chip interface routines in that library could
have problems.  

From marc@sun-valley.stanford.edu  Tue Apr  7 00:38:28 1992
From: marc@sun-valley.stanford.edu (Marc Ullman)
Date: Tue Apr  7 00:38:36 PDT 1992
Subject: Re: Compiler option problems 
>The reason I brought up this problem was mainly to see how people were dealing
>with the fact that all the configuration code is by default compiled with the
>"-O -fvolatile" switches. 

Since using the -fvolatile flag basically defeats the purpose of having an
optimizer we dealt with this by cleaning up the WRS supplied code (and
makefiles) until it would compile error and warning free using "-O -Wall"
(WITHOUT the -fvolatile flag).  This meant ANSIfying it, reordering it,
adding "volatile" to variable declarations corresponding to hardware
registers, fixing header files, etc.  

> As I showed, using these switches can cause code
>to be generated that will result in execution errors if interrupts occur
>at the wrong time.  Specifically, there are problems with any of the config
>code that can run at interrupt and task level, possibly concurrently, that
>uses the "|=" or "&=" assignment statements.  My feeling is that this could
>be the cause of some of the infrequent glitches people see when running
>VxWorks.

This would be a fundamental design/coding flaw--not a compiler bug.  Task
and interrupt code should not be mucking with the same piece of hardware at
the same time (unless it is "dual ported").  Clearly said hardware represents
a "critical section" and should be appropriately protected using semaphores
(e.g. the TAS variety) or int locks.

BTW, would you care to point out a specific instance of this problem in one of
the common config source files?

>  I was sort of hoping that some of the Wind River people who had
>thought this stuff through would chime in.  I say the compiler is busted and
>should be fixed but Richard Stallman (who wrote gcc) wasn't too interested
>(although he said the problem is likeley in code in the combine.c routine).

As for GCC being "busted"--that is a rather unfair accusation.  There is 
nothing in the ANSI C standard that says how efficiently a compiler has
to perform any particular operation.  I will grant you that GCC does not
produce the tightest possible code when pointers are declared to be volatile,
but to make assumptions of the nature you imply is simply unreasonable.
If you want atomic actions, you should surround them with int locks.
This would be true even if you were writing in assembly language.

--Marc Ullman
  Stanford University

From daemon@vxw.ee.lbl.gov  Tue Apr  7 04:00:27 1992
From: daemon@vxw.ee.lbl.gov
Date: Tue Apr  7 04:00:34 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Apr  7 04:00:20 PDT 1992

        Subject: X for vxworks?
        Subject: Re: TCP Bandwith on VxWorks
        Subject: etherAddrResolve() help, please
        Subject: Re: etherAddrResolve() help, please

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: X for vxworks?
Date: 6 Apr 92 16:05:58 GMT
From: amidi+@CS.CMU.EDU (Omead Amidi)
Organization: Carnegie Mellon University
Message-ID: <1992Apr06.160558.278791@cs.cmu.edu>

Hello,

I would like to run some X clients on my vxworks target.  I found an old
(v. 3.0) port of Xlib from thor.ucar. but nothing more recent.  Is anyone
using or porting X to vxworks?

thanks.

- -- Omead

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: TCP Bandwith on VxWorks
Date: 6 Apr 92 16:00:45 GMT
From: els@icf.hrb.com (Eric L. Schott)
Organization: HRB Systems, Inc.
Message-ID: <1992Apr6.110045.19052@icf.hrb.com>
References: <0dfW028U0fSC01@JUTS.ccc.amdahl.com> <27550006@hppad.waterloo.hp.com>

In article <27550006@hppad.waterloo.hp.com>, rypma@hppad.waterloo.hp.com (Ted Rypma) writes:
>> Does anybody know what's the maximum data throughput achivable at the socket
>> (TCP) interface in VxWorks.  As this figure depends highly on the particular
>> hardware used, please specify the type and speed of CPU and network.
> 
> We get between 600 and 700 Kbytes/sec with a 25 MHz Intel i960 processor and an
> Intel 82596 LAN controller. We haven't measured the CPU overhead, but at this
> data rate there appears to be enough horsepower left to do other things.
> 

I have measured over 800 Kbytes/sec between an 040 SBC (VxWorks)
and a SPARCstation 2 (SunOS 4.1.1).  We used TCP sockets.
- -- 

Eric L. Schott, HRB Systems, Inc.   814/238-4311
  Internet: ELS@ICF.HRB.COM

---------------------------

Newsgroups: comp.os.vxworks
Subject: etherAddrResolve() help, please
Date: 6 Apr 92 17:51:30 GMT
From: bgeer@javelin.sim.es.com (Bob Geer)
Organization: Evans & Sutherland Computer Corporation
Message-ID: <1992Apr6.175130.16667@javelin.sim.es.com>
Reply-To: bgeer@javelin.sim.es.com

The man page for the VxWorks function etherAddrResolve() (as well as
the page for etherOutput) includes the following reference via code
fragment:

      struct ifnet *pIf;
      pIf = ifunit ("ln0");

I can't find a macro definition or function prototype for ifunit()
anywhere in the Vx stuff.  Structure "ifnet" includes a member "short
if_unit", which doesn't look pertinent.

I can infer that ifunit() can be properly prototyped as:
	"struct ifnet *ifunit( char *)" 

However, I'd appreciate confirmation...

Thanks in advance, Bob
- -- 
<> Bob `Bear' Geer <>  bgeer@beorn.sim.es.com             __o    <>
<>    bike-a-holic <>   (this *often* works)             -\<,    <>
<> Salt Lake City, <>  speaking only for myself,   ......O/ O    <>
<>          Ootah  <>  one of my many tricks                     <>

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: etherAddrResolve() help, please
Date: 6 Apr 92 20:00:31 GMT
From: bgeer@javelin.sim.es.com (Bob Geer)
Organization: Evans & Sutherland Computer Corporation
Message-ID: <1992Apr6.200031.17695@javelin.sim.es.com>
References: <1992Apr6.175130.16667@javelin.sim.es.com>
Reply-To: bgeer@javelin.sim.es.com

bgeer@javelin.sim.es.com (Bob Geer) writes:

>The man page for the VxWorks function etherAddrResolve() (as well as
>the page for etherOutput) includes the following reference via code
>fragment:

>      struct ifnet *pIf;
>      pIf = ifunit ("ln0");

>I can't find a macro definition or function prototype for ifunit()
>anywhere in the Vx stuff.  Structure "ifnet" includes a member "short
>if_unit", which doesn't look pertinent.

>I can infer that ifunit() can be properly prototyped as:
>	"struct ifnet *ifunit( char *)" 

>However, I'd appreciate confirmation...

To follow up, my contrived prototype (as mentioned above) appears to
work.  However, I now note that if I try to arp an unresponsive
machine, the timeout status is OK, not ERROR as advertised.  Is there
a work-around for this?  I'm using vw5.0.2 for a -147 board.

As before, thanks in advance...Bob

Hope this damned e-mail system works!
- -- 
<> Bob `Bear' Geer <>  bgeer@beorn.sim.es.com                           /  <>
<>                 <>   (this *often* works)       __o      o   ,______/o  <>
<> Salt Lake City, <>  speaking only for myself,  -\<,     <\   ,__/   >   <>
<>          Ootah  <>  one of my many tricks      O/ O  __ /__,       /    <>

---------------------------

End of New-News digest
**********************

From rayssd!ss4u02.ssd.ray.com!fjr@uunet.uu.net  Tue Apr  7 11:28:16 1992
From: "Roeber" <fjr@ss4u02.ssd.ray.com>
Date: Tue Apr  7 11:28:25 PDT 1992
Subject: Re: Compiler option problems

>  Submitted-by marc@sun-valley.stanford.edu  Tue Apr  7 00:38:28 1992
>  
>  Since using the -fvolatile flag basically defeats the purpose of having an
>  optimizer we dealt with this by cleaning up the WRS supplied code (and
>  makefiles) until it would compile error and warning free using "-O -Wall"
>  (WITHOUT the -fvolatile flag).  This meant ANSIfying it, reordering it,
>  adding "volatile" to variable declarations corresponding to hardware
>  registers, fixing header files, etc.

Wow, that clearly is the right way to handle things but involves a lot of
work.  It will be nice when VxWorks is all ansified but I haven't heard
any definitive schedule for when that will be.
  
>  This would be a fundamental design/coding flaw--not a compiler bug.  Task
>  and interrupt code should not be mucking with the same piece of hardware at
>  the same time (unless it is "dual ported").  Clearly said hardware represents
>  a "critical section" and should be appropriately protected using semaphores
>  (e.g. the TAS variety) or int locks.
>  
>  BTW, would you care to point out a specific instance of this problem in one of
>  the common config source files?

Very good points.  Note though that the restriction that you are mucking with
hardware only this way is not valid.  This problem applies to any data
structure that is shared across interrupt and task level and is updating using
bit fields or the "|=" and "&=" constructs; some task level code moves
a flag value into a register, gets interrupted by a handler that changes the
flag value, and then when the tasks resumes it moves a new copy of the register
back to memory overwriting the flag.  I initially ran into this problem more
than a year ago when we were using an older VxWorks release with the GNU tools
before GNU support was available officially.  We had compiled the whole system
(including all the VxWorks source code) with -fvolatile and were having strange
problems.  After much enlightening discussion, Dave Wilner at WRS tracked it
down to the -fvolatile problem.  Well, since most of the kernel doesn't use
-fvolatile (only the SCSI drivers in the drv library do), there isn't a
problem.  But this is only because the bit modification instructions DO
generate atomic instructions in the normal case.  Sure it would be "correct"
to always lock interrupts before doing anything that is messing with structures
shared across task and interrupt level but think of the performance penalty.
When you are coding things, don't you have a mental model of what is and isn't
safe to do?  I guess I had figured that bit operations were.
  In a number of places, VxWorks is coded around the concept that bit
manupulation operations are safe (the terminal library and ethernet driver
are two examples that I can think of).  I went through the configuration
code, though, and couldn't find any examples of where there could be problems.
In the specific board support packages I checked there were a few places
where this problem could bite one.  Also, in some configuration code we had
added there were problems (we got bit by the fact that since we could see how
WRS had done some things we used the same mechanisms but without the safety of
having the code in a directory that got compiled with the right options).

>  As for GCC being "busted"--that is a rather unfair accusation.  There is 
>  nothing in the ANSI C standard that says how efficiently a compiler has
>  to perform any particular operation.  I will grant you that GCC does not
>  produce the tightest possible code when pointers are declared to be
>  volatile, but to make assumptions of the nature you imply is simply
>  unreasonable. If you want atomic actions, you should surround them
>  with int locks. This would be true even if you were writing in assembly
>  language.

Again, I guess I agree about GCC not being "busted".  It is just unfortunate
that it generates such poor code with volatile things.  Since you have dealt
with ANSI code out of GCC it sounds like we can count on any volatile
variables accessed through pointers to generate non atomic operations.  Do
you also have to make sure that global variables that are shared across
task and interrupt level are declared volatile to make sure that all updates
to them get written to memory in the order performed?  If such is the case
then ANSIfying VxWorks may not be so easy since bit field and read modify
write operations (like &=) will have to all be fixed.  I guess the bottom
line is having an accurate model of the compiler generated code when
programming.  You can't assume the worst case code and still have a system
that works but if you are too optimistic, you can end up with buggy code.

>  --Marc Ullman
>    Stanford University

Thanks for the info.   Fred

From iphasew!hwajin@apple.com  Tue Apr  7 14:29:42 1992
From: hwajin@iphasew.com (Hwa-Jin Bae)
Date: Tue Apr  7 14:29:49 PDT 1992
Subject: Re: Compiler option problems 

>Since using the -fvolatile flag basically defeats the purpose of having an
>optimizer we dealt with this by cleaning up the WRS supplied code (and
>makefiles) until it would compile error and warning free using "-O -Wall"
>(WITHOUT the -fvolatile flag).  This meant ANSIfying it, reordering it,
>adding "volatile" to variable declarations corresponding to hardware
>registers, fixing header files, etc

This is definitely the right thing to do in my opinion.  It is also a lot
of work.  If you prefer to stay with "-traditional" (non-ANSI, K&R) GCC,
you can still use the "volatile" type.  GCC provides "__volatile__" and
a few other ANSI types and qualifiers that can be used for non-ANSI
mode compilation.  A convenient hack most people perform to make 
"__volatile__" equal to "volatile" when "-traditional" is being used
is  adding a line like "%{traditional:-Dvolatile=__volatile__}" to
the "struct compiler compilers[]" array in gcc.c.  With a compiler
like this, all one has to do is to add "volatile" to variable declarations
corresponding to hardware registers, etc.; no need to muck with headers
or ANSI-fy your code.

--
Hwa-Jin Bae
Interphase West

From Enterprise!arete.com!reder@uu.psi.com  Tue Apr  7 14:30:46 1992
From: reder@arete.com (Leonard J. Reder)
Date: Tue Apr  7 14:30:54 PDT 1992
Subject: Re: comp.os.vxworks newsdigest

> >> Does anybody know what's the maximum data throughput achivable at the socket
> >> (TCP) interface in VxWorks.  As this figure depends highly on the particular
> >> hardware used, please specify the type and speed of CPU and network.
> > 
> > We get between 600 and 700 Kbytes/sec with a 25 MHz Intel i960 processor and an
> > Intel 82596 LAN controller. We haven't measured the CPU overhead, but at this
> > data rate there appears to be enough horsepower left to do other things.
> > 
> 
> I have measured over 800 Kbytes/sec between an 040 SBC (VxWorks)
> and a SPARCstation 2 (SunOS 4.1.1).  We used TCP sockets.
> 
I have measured the data rate between a SPARCstation2 (SunOS 4.1.1)
and a MV147S (68030) SBC (VxWorks 5.0) tobe as high as 200Kbytes/sec.
I could not get any more speed out of the configuration. We also used
TCP sockets.
s

From marc@sun-valley.stanford.edu  Tue Apr  7 15:47:05 1992
From: marc@sun-valley.stanford.edu (Marc Ullman)
Date: Tue Apr  7 15:47:12 PDT 1992
Subject: Re: Compiler option problems 
>>  This would be a fundamental design/coding flaw--not a compiler bug.  Task
>>  and interrupt code should not be mucking with the same piece of hardware at
>>  the same time (unless it is "dual ported").  Clearly said hardware represen
> ts
>>  a "critical section" and should be appropriately protected using semaphores
>>  (e.g. the TAS variety) or int locks.
>>  
>>  BTW, would you care to point out a specific instance of this problem in one
>  of
>>  the common config source files?
>
>Very good points.  Note though that the restriction that you are mucking with
>hardware only this way is not valid.  This problem applies to any data
>structure that is shared across interrupt and task level and is updating using
>bit fields or the "|=" and "&=" constructs; some task level code moves
>a flag value into a register, gets interrupted by a handler that changes the
>flag value, and then when the tasks resumes it moves a new copy of the registe
> r
>back to memory overwriting the flag.

I certainly agree that "shared" data structures present the same problem.

>I initially ran into this problem more
>than a year ago when we were using an older VxWorks release with the GNU tools
>before GNU support was available officially.  We had compiled the whole system
>(including all the VxWorks source code) with -fvolatile and were having strang
> e
>problems.  After much enlightening discussion, Dave Wilner at WRS tracked it
>down to the -fvolatile problem.  Well, since most of the kernel doesn't use
>-fvolatile (only the SCSI drivers in the drv library do), there isn't a
>problem.  But this is only because the bit modification instructions DO
>generate atomic instructions in the normal case.  Sure it would be "correct"
>to always lock interrupts before doing anything that is messing with structure
> s
>shared across task and interrupt level but think of the performance penalty.
>When you are coding things, don't you have a mental model of what is and isn't
>safe to do?  I guess I had figured that bit operations were.

I guess this comes down to a choice of speed vs. portability.  Again there
is nothing in the ANSI-C language spec about the atomic nature of any opera-
tion.  For instance, if I recall correctly, most Load/Store RISC chips (e.g.
SPARC) do not have instructions for doing bitwise read-modify-write operations.
Thus on those machines, the compiler is forced to generate multiple instruc-
tions.  Consider the following code example:

	int *a = 0;

	void main ()
	{
	    *a |= 0x1;
	}

Compile this with Sun's stock distribution C compiler using the -O flag
and you get:

0x2290 <main>:          sethi %hi(0x4000), %o0
0x2294 <main+4>:        ld [%o0+0x98], %o0      ! 0x4098 <a>
0x2298 <main+8>:        ld [%o0], %o1	<==== READ
0x229c <main+12>:       or 1, %o1, %o1	<==== MODIFY
0x22a0 <main+16>:       retl 
0x22a4 <main+20>:       st %o1, [%o0]	<==== WRITE (in delay slot)

Thus in my opinion, one should either code "conservatively" in C,
meaning you take the hit of placing intlocks around events that must be
atomic, or you code in assembly when you really want to specify a specific
set of machine level instructions.

>  In a number of places, VxWorks is coded around the concept that bit
>manupulation operations are safe (the terminal library and ethernet driver
>are two examples that I can think of).

If what you say is true, and I assume that it is, I suspect you have just
found a boatload of latent bugs in the various RISC ports of VxWorks.
I believe that the code example above clealy invalidates this notion of
"safe".

>  I went through the configuration
>code, though, and couldn't find any examples of where there could be problems.
>In the specific board support packages I checked there were a few places
>where this problem could bite one.  Also, in some configuration code we had
>added there were problems (we got bit by the fact that since we could see how
>WRS had done some things we used the same mechanisms but without the safety of
>having the code in a directory that got compiled with the right options).

See above.  Of course when VxWorks was originally written, its authors were
probably not overly concerned with issues like portability etc.  It's the
kind of thing you only learn about after you've been burned by it.

">Again, I guess I agree about GCC not being "busted".  It is just unfortunate
>that it generates such poor code with volatile things.  Since you have dealt
>with ANSI code out of GCC it sounds like we can count on any volatile
>variables accessed through pointers to generate non atomic operations.

That seems to be my observation, even with the latest version (2.1) and the
-O2 flag.  I have not tried playing with the many additional optimization
options to see if any of them affect this.  It would probably not be a big
deal to "fix" this up in the 68k code generator; however, even if that were
done, the source code should still be rewritten to be portable and robust.

>Do you also have to make sure that global variables that are shared across
>task and interrupt level are declared volatile to make sure that all updates
>to them get written to memory in the order performed? 

Effectively, the answer is YES.  The compiler can very easily elect to
cache any non-volatile variable in a register.  And most new optimizing
compilers will.  This is where much of the performance improvement comes
from.

> If such is the case
>then ANSIfying VxWorks may not be so easy since bit field and read modify
>write operations (like &=) will have to all be fixed.  I guess the bottom
>line is having an accurate model of the compiler generated code when
>programming.  You can't assume the worst case code and still have a system
>that works but if you are too optimistic, you can end up with buggy code.

As mentioned above, one should design and code in such a way as to not make
assumptions on unspecified behaviors.  If performance is paramount (as it
often is in a real-time kernel or a device driver), there is still no
substitute for assembly language.  However, a properly designed system
should minimize the occurances of this type of situation (the philosophy
behind micro-kernels--which Wind essentially is).  I believe in the approach
that ISRs should be as small as possible and do as little as possible.
This helps make interrupt latency more predictable and overall performance
better (by among other things eliminating as much as possible, occurances of
the type of mutual access problems you have described).

--Marc

P.S. While on the subject of ANSI C coding style--the liberal use of "const"
    (the exact opposite of "volatile"), can help improve one's code by (1)
    exposing coding errors (like trying to overwrite constants) and/or
    ROM and (2) by telling the compiler when it is safe to leave things in 
    registers across function calls (i.e. it reduces the compiler's burden 
    of having to worry about side effects).

From marc@sun-valley.stanford.edu  Tue Apr  7 15:54:11 1992
From: marc@sun-valley.stanford.edu (Marc Ullman)
Date: Tue Apr  7 15:54:18 PDT 1992
Subject: Re: Compiler option problems 

>This is definitely the right thing to do in my opinion.  It is also a lot
>of work.  If you prefer to stay with "-traditional" (non-ANSI, K&R) GCC,
>you can still use the "volatile" type.  GCC provides "__volatile__" and
>a few other ANSI types and qualifiers that can be used for non-ANSI
>mode compilation.  A convenient hack most people perform to make 
>"__volatile__" equal to "volatile" when "-traditional" is being used
>is  adding a line like "%{traditional:-Dvolatile=__volatile__}" to
>the "struct compiler compilers[]" array in gcc.c.  With a compiler
>like this, all one has to do is to add "volatile" to variable declarations
>corresponding to hardware registers, etc.; no need to muck with headers
>or ANSI-fy your code.

This does circumvent the "volatile" issue, but it does not provide all the
other benefits that clean ANSI code provides.  IMHO, not using ANSI C, now
that the spec is formally approved and excellent conforming compilers like
GCC are available, is like programming with one hand tied behind one's back.
In the PC and Mac world, any tool vendor who didn't support ANSI C would
be dead meat.  It baffles me why the UNIX community (e.g. Sun, WRS, etc.),
which prides itself as being at the leading edge of technology, is so far
behind on this one.

--Marc

From hill@luke.atdiv.lanl.gov  Wed Apr  8 10:17:06 1992
From: hill@luke.atdiv.lanl.gov (Jeff Hill)
Date: Wed Apr  8 10:17:15 PDT 1992
Subject: Re: Compiler option problems

> Consider the following code example:
> 
> 	int *a = 0;
> 
> 	void main ()
> 	{
> 	    *a |= 0x1;
> 	}
> 
> Compile this with Sun's stock distribution C compiler using the -O flag
> and you get:
> 
> 0x2290 <main>:          sethi %hi(0x4000), %o0
> 0x2294 <main+4>:        ld [%o0+0x98], %o0      ! 0x4098 <a>
> 0x2298 <main+8>:        ld [%o0], %o1	<==== READ
> 0x229c <main+12>:       or 1, %o1, %o1	<==== MODIFY
> 0x22a0 <main+16>:       retl 
> 0x22a4 <main+20>:       st %o1, [%o0]	<==== WRITE (in delay slot)

hm ... thats interesting that "*i |= 1" is also not atomic when compiled 
with sun's stock compiler for the sparc. Is this a architecture 
limitation?

While I have never assumed that "*i |= 1" was atomic 
I have always assumed that "(*i)++" was an atomic operation. This turns 
out to be the case with every compiler/architecture combination that I 
have written code for. This is certainly the case with sun's sparc compiler 
and with gcc68k -O -fvolatile (and all other gcc68k compiler switches 
that I tried). Has anyone out there ever seen an architecture/compiler 
combination where "(*i)++" or "i++" were not atomic?

Jeff

From bernard@aar.alcatel-alsthom.fr  Wed Apr  8 10:46:24 1992
From: bernard@aar.alcatel-alsthom.fr ( Olivier Bernard )
Date: Wed Apr  8 10:46:32 PDT 1992
Subject: SLIP overrun
We have some problems when using SLIP between our
UNIX host (a SPARC II with sunOS 4.1.2) and VxWorks 5.0.
Slip is used over a radio modem link (9600 bds, full duplex).

After a few minutes of correct working, the following message appeared 
on the UNIX console:

>> Apr  8 14:57:28 serpentine vmunix: slip0: inlen(1075) > SLIPMTU(1006)
>> Apr  8 14:58:00 serpentine vmunix: slip0: inlen(1056) > SLIPMTU(1006)
>> Apr  8 14:59:14 serpentine vmunix: slip0: inlen(1063) > SLIPMTU(1006)
>> Apr  8 15:00:04 serpentine vmunix: slip0: inlen(1070) > SLIPMTU(1006)

We use, on the UNIX side, sliplogin 1.4 and the module tty_slip.c
has version 1.10. 

Does anybody can help ? Are our slip version obsolete ? In that case
where can I find a new version ?

Thanks

-- Olivier

PS: sorry for my last message about flow control on the VxWorks side,
    I ran ifShow and it reported there was no transmit error .. so
    I guess flow control is ok on vxWorks.

 -----------------------------------------------------------
!                                                           !
! Olivier BERNARD                                           !
! Alcatel Alsthom Recherche                                 !
! Route de Nozay                                            !
! 91460 Marcoussis                                          !
! France                                                    !
!                                                           !
! mail: bernard@aar.alcatel-alsthom.fr                      !
!                                                           !
 -----------------------------------------------------------

From marc@sun-valley.stanford.edu  Wed Apr  8 11:29:14 1992
From: marc@sun-valley.stanford.edu (Marc Ullman)
Date: Wed Apr  8 11:29:22 PDT 1992
Subject: Re: Compiler option problems 
>hm ... thats interesting that "*i |= 1" is also not atomic when compiled 
>with sun's stock compiler for the sparc. Is this a architecture 
>limitation?

YES.

>While I have never assumed that "*i |= 1" was atomic 
>I have always assumed that "(*i)++" was an atomic operation. This turns 
>out to be the case with every compiler/architecture combination that I 
>have written code for. This is certainly the case with sun's sparc compiler 
>and with gcc68k -O -fvolatile (and all other gcc68k compiler switches 
>that I tried). Has anyone out there ever seen an architecture/compiler 
>combination where "(*i)++" or "i++" were not atomic?

Are you sure about that?  (*i)++ is also a RMW operation, which most load/
store risc architectures do not support.  Consider the following example:

	int *a = 0;

	void main ()
	{
	      (*a)++;
	}

Compile this with Sun's standard C compiler (with optimization) and you'll get:

	0x2290 <main>:          sethi %hi(0x4000), %o0
	0x2294 <main+4>:        ld [%o0+0x98], %o0      ! 0x4098 <a>
	0x2298 <main+8>:        ld [%o0], %o1   <==== READ
	0x229c <main+12>:       inc %o1         <==== MODIFY
	0x22a0 <main+16>:       retl 
	0x22a4 <main+20>:       st %o1, [%o0]   <==== WRITE (in delay slot)

--Marc

From jones@cs.buffalo.edu  Wed Apr  8 12:18:57 1992
From: jones@cs.buffalo.edu (Terry A. Jones)
Date: Wed Apr  8 12:19:18 PDT 1992
Subject: Re: Compiler option problems.

> hm ... thats interesting that "*i |= 1" is also not atomic when compiled 
> with sun's stock compiler for the sparc. Is this a architecture 
> limitation?

	This depends on your definition of atomic.  I would not assume that
any C statement generated code that was atomic.  Excepting maybe the case
of assignment.  It is up to the architecture to support non-interruptable
read-modify-writes for the operation you desire.  Then you would have to
check to make sure that the C code generator you are using actually knows
enough to make use of these machine instructions.

> While I have never assumed that "*i |= 1" was atomic 
> I have always assumed that "(*i)++" was an atomic operation. This turns 
> out to be the case with every compiler/architecture combination that I 
> have written code for. This is certainly the case with sun's sparc compiler 

	I would not rely on this to be atomic either.  In the case of the
Sparc, there is no read-modify-write instruction that performs this 
increment operation.  

	The code sequence:

	(*i)++;

	Gives you:

	ld	[%o0],%o1
	inc	%o1
	st	%o1,[%o0]

	Which is not atomic as far as I can see.

	Terry Jones

From iphasew!hwajin@apple.com  Wed Apr  8 13:17:27 1992
From: hwajin@iphasew.com (Hwa-Jin Bae)
Date: Wed Apr  8 13:17:38 PDT 1992
Subject: Re: Compiler option problems 

>IMHO, not using ANSI C, now
>that the spec is formally approved and excellent conforming compilers like
>GCC are available, is like programming with one hand tied behind one's back.
>In the PC and Mac world, any tool vendor who didn't support ANSI C would
>be dead meat.  It baffles me why the UNIX community (e.g. Sun, WRS, etc.),
>which prides itself as being at the leading edge of technology, is so far
>behind on this one.

[Soapbox begin...]

Partly this is perhaps due to the sheer amount of source code that
needs to be converted to ANSI.  One could condemn an engineer to
sit down and ANSI-fy the vast amount of operating system source code,
or one could encourage incremental conversion while promoting use
of ANSI style prototypes, etc. for any new code being written (well,
maybe not ;-) ).

UNIX C programs have existed long before ANSI C was developed, long
before the DOS and MAC versions of C compilers.  Not only the kernel
source, but a vast amount of UNIX utilities as well --- now including
a good megaton of X11 code and, yes, GCC itself, which is written mostly
in elegant K&R C.

Another reason is that most operating system vendors (and certainly
the lint-religious engineers at WRS) lint every single line of 
their operating system software, including cross-file checking 
using  generated lint libraries.  

Apart from the benefit you get using "const, volatile ", etc.,
lint actually does more checking beyond what's possible
even with GCC with "-Wall".  It also does not have ANSI C brain-damage
that defines a scope of type declaration to function prototypes, causing
in some cases incompatible type error for the same type depending
on the order of declaration.

Using automatic prototype generators or ANSI conversion
programs is at best too risky for operating system
source code.  I agree that in an ideal world, we'd all have enough
time to invest in ANSI-fying every line of C code we come across,
and the world would be "better" place.  In the mean time, hacking up
GCC gives you what's missing in K&R C, and lint gives you all the
checking you usually want for your code.  A caveat of course is that
most UNIX vendors do ship their lint libraries, while WRS may or may not.

[ ... end]

Obligatory technical content: 

Even GCC, a mind-bogglingly good compiler, when used with -ansi 
option, is not 100% ANSI compatible.   For that one must also use rare and exotic options such as -pedantic and -trigraphs.

--
Hwa-Jin Bae

From christ@mordor.pen.tek.com  Wed Apr  8 14:02:52 1992
From: christ@mordor.pen.tek.com
Date: Wed Apr  8 14:03:00 PDT 1992
Subject: Handling events at a guaranteed rate. Question.

Hi folks.

  Reading the latest commentary on ISR level processing has me asking
some questions. Timely too, because we are designing a system with
at least one hard dead-line.

  How can I build a system that will guarantee that an event will be
processed every X time units? And announce via logMsg() if I missed one?

  For example, let's say X = 10 msec and we can get a system clock tick
every 10 or 5 or so msec (programmable). From what I've heard I want
to have a high priority task that "takes" a binary semaphore and an
ISR that "gives" the semaphore (see section 3.3.3.2 of vxWorks
programmer's guide)...

taskInit()
	{
	semId = semBCreate (SEM_Q_FIFO, SEM_EMPTY);
	taskSpawn (..., taskCode);
	}

taskCode ()
	{
	while (1)
		{
		semTake (semId, WAIT_FOREVER);	/* wait for event */
		/*
		 * Do processing of event here...
		 */
		}
	}

taskISR ()
	{
	semGive (semId);	/* let taskCode process event */
	}

  Given something like this, no work is being done at interrupt level,
which seems good because it makes the system easier to tune via priority
levels and doesn't turn off interrupts with intLock(). Are there better
ways to do this for timer based events?

  I'd also like to add some code that warns me if I miss this dead line.
Initialy I wanted to put in a watch dog, but at a clock rate so close to
the event rate, the resolution seems to be questionable. The other approach
might be to add an extra call to semTake (semId, NO_WAIT) above the
semtake (..., WAIT_FOREVER) and check for absence of ERROR which indicates
that an event was missed because we expect to block until the "give"
happens. Was that clear? The point is that I'd like to know if I miss
an event, but if interrupts are flogging the processor we may not get
to the semTake() until after another event has passed; in this case,
we would never know we missed one because the semTake (..., NO_WAIT)
never happened. Whew!

  So, do you guys mask off interrupts (which seems deadly) in the ISR
"give" code and then turn them on again in the "take" code to guarantee
that you don't miss an event? I'm probably going to get pulverized with
flames here, but I'd appretiate an in-depth explanation of the trade-offs.

  Thanks in advance!

   Chris Tilt
   Tektronix, Inc.

From marc@sun-valley.stanford.edu  Wed Apr  8 16:21:59 1992
From: marc@sun-valley.stanford.edu (Marc Ullman)
Date: Wed Apr  8 16:22:06 PDT 1992
Subject: Re: Compiler option problems 
>Submitted-by iphasew!hwajin@apple.com  Wed Apr  8 13:17:27 1992
>Submitted-by: hwajin@iphasew.com (Hwa-Jin Bae)
> 
>
>>IMHO, not using ANSI C, now
>>that the spec is formally approved and excellent conforming compilers like
>>GCC are available, is like programming with one hand tied behind one's back.
>>In the PC and Mac world, any tool vendor who didn't support ANSI C would
>>be dead meat.  It baffles me why the UNIX community (e.g. Sun, WRS, etc.),
>>which prides itself as being at the leading edge of technology, is so far
>>behind on this one.
>
>
>[Soapbox begin...]
>
>Partly this is perhaps due to the sheer amount of source code that
>needs to be converted to ANSI.  One could condemn an engineer to
>sit down and ANSI-fy the vast amount of operating system source code,
>or one could encourage incremental conversion while promoting use
>of ANSI style prototypes, etc. for any new code being written (well,
>maybe not ;-) ).

Not that my objective is to get into a shouting match, but ANSI C has
become very dear to me, so I must add a few caveats:

	Yes, it takes time and effort, but it only needs to be done once
	and the benefits, in my opinion and experience, more than
	justify the effort.  We have ANSIfied everything we write
	as well as much of what we deal with.  This means fixing header
	files for SunOS, VxWorks, etc.  If a couple of busy students can
	do this, I fail to understand why big companies can't.  Further-
	more, I do a fair amount of consulting work to "real companies"
	and I have pushed all of them to do the same with very positive
	results.

>UNIX C programs have existed long before ANSI C was developed, long
>before the DOS and MAC versions of C compilers.  Not only the kernel
>source, but a vast amount of UNIX utilities as well --- now including
>a good megaton of X11 code and, yes, GCC itself, which is written mostly
>in elegant K&R C.

	I imagine that there are far more total lines of code running on
	the 40 million PC's than the couple of million UNIX boxes.

	I admit that it frustrates me that GCC 2.X was not written in
	ANSI C.  Now that it has such fabulous cross development support,
	it could always be bootstraped by using GCC 1.X and then using
	2.X on an originally supported platform to cross compile for one
	of the newer platforms they now support.

>Another reason is that most operating system vendors (and certainly
>the lint-religious engineers at WRS) lint every single line of 
>their operating system software, including cross-file checking 
>using  generated lint libraries.  

	The problem with lint is that it requires extra effort.  Compiling
	with GCC and the -Wall flag is totally automatic.  Your code gets
	re-checked everytime you change anything.  See also comments
	below on automatic header file generation--something else that
	lint doesn't do for you automatically.

>Apart from the benefit you get using "const, volatile ", etc.,
>lint actually does more checking beyond what's possible
>even with GCC with "-Wall".  It also does not have ANSI C brain-damage
>that defines a scope of type declaration to function prototypes, causing
>in some cases incompatible type error for the same type depending
>on the order of declaration.

	If lint does more than GCC -Wall, then why does GCC -Wall pick
	the WRS supplied code to pieces.  GCC V2.1 does everything and
	more than lint, including validating arguments to printf format
	strings, again without any extra effort on the part of the pro-
	grammer.  I think that's pretty hot!

>Using automatic prototype generators or ANSI conversion
>programs is at best too risky for operating system
>source code.

	We have developed a system (and philosphy) for automatically
	generating header files (which we have being trying to get
	WRS to adopt) that has been used both at Stanford and by a
	number of commerical software vendors.  It works very nicely.
	[Note: it does NOT convert K&R code to ANSI C.  It produces
	header files from C source files automatically everytime you
	update your source code--thus guaranteeing that the protoypes
	that you export to other source files always match the defini-
	tions in the implementing source file.  It works for typedefs
	and structure, variable, constant, etc. definitions as well.]
	

>  I agree that in an ideal world, we'd all have enough
>time to invest in ANSI-fying every line of C code we come across,
>and the world would be "better" place.

	I fully admit to being a idealist. :-)

>  In the mean time, hacking up
>GCC gives you what's missing in K&R C, and lint gives you all the
>checking you usually want for your code.  A caveat of course is that
>most UNIX vendors do ship their lint libraries, while WRS may or may not.

	See comments regarding lint above.  Again it requires a conscience
	extra effort, which is usually only performed when one is getting
	ready to release a product, whereas GCC checks your code every time
	you recompile it and makeheader (our header file generating tool)
	updates your header files every time you run make.  Everything is
	totally automatic and thereby prevents any part from getting out of
	sync with any other part.  It really does work and it really is 
	worth it.  The amount of time now spent using a debugger has been
	reduced by an order of magnitude.  By the time code compiles warning
	free, it ususally runs the first time it's tried (assuming the under-
	lying design was sound).
	
>Obligatory technical content: 
>
>Even GCC, a mind-bogglingly good compiler, when used with -ansi 
>option, is not 100% ANSI compatible.   For that one must also use rare and exo
> tic options such as -pedantic and -trigraphs.

	Tis true.

	--Marc

From marc@sun-valley.stanford.edu  Wed Apr  8 16:35:23 1992
From: marc@sun-valley.stanford.edu (Marc Ullman)
Date: Wed Apr  8 16:35:30 PDT 1992
Subject: Re: Handling events at a guaranteed rate. Question. 

>  How can I build a system that will guarantee that an event will be
>processed every X time units? And announce via logMsg() if I missed one?
>
>  For example, let's say X = 10 msec and we can get a system clock tick
>every 10 or 5 or so msec (programmable). From what I've heard I want
>to have a high priority task that "takes" a binary semaphore and an
>ISR that "gives" the semaphore (see section 3.3.3.2 of vxWorks
>programmer's guide)...

I would certainly agree with that approach.  You could add the additional
event checking you wanted by clearing a TAS flag at the end of your
"task code" just before the call to semTake.  The ISR could then call
TAS before doing the semGive and call logMsg() if it doesn't get the
flag, meaning the task code didn't finish in time.

Note--I'm dashing this suggestion off with out a lot of thought, so it may
have subtleties I haven't considered.  For instance, I assuming that
rather than "missing an event" you want to know if you finished processing
the previous event "in time for the next one".  Also, I'm assuming that
you aren't trying to recover gracefully from falling behind, since the
call to logMsg from the ISR will slow things down even more.

--Marc Ullman
  Stanford University

From daemon@vxw.ee.lbl.gov  Thu Apr  9 04:00:27 1992
From: daemon@vxw.ee.lbl.gov
Date: Thu Apr  9 04:00:34 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Apr  9 04:00:20 PDT 1992

        Subject: Need information on VXWORKS for VME
        Subject: for sale

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Need information on VXWORKS for VME
Date: 8 Apr 92 18:40:40 GMT
From: syong@gridlock.ardfa.calpoly.edu (Shane Shew-Shin Yong)
Organization: Applied Research and Development, San Luis Obispo CA
Message-ID: <1992Apr8.184040.13682@petunia.csc.calpoly.edu>
Sender: news@petunia.csc.calpoly.edu (Flower Power)

I am a student researcher here at Cal Poly doing work for California Dept. of
Transportation (CAL TRANS).  We (my research group) have been using OS/9 for
our VME (147A) as a platform for developing real-time data collecting software.
Recently, we've heard of the operating system, VXWORKS.  Someone suggested that
it would be a good replacement for OS/9 since we have encountered some problems
with it.  However, it will take a lot of work to port over code developed on
another operating system (especially real-time software).  I was hoping that
somebody out there has had a similar experience and would care to share his/her
ideas and comment on VXWORKS as a software development platform.  Of course, I
would welcome any opinions, suggestions, etc.

I know very little about this operating system; therefore, I would also
appreciate the names of any books (and their author) and references that can
help me.

I am most interested in these areas:
1. TCP/IP, and RPC support (our VME will be communicating with a bunch of Suns).
2. Reliability; our real-time software must not fail because of OS bugs.
3. Serial device communications. (modems & serial connected workstations).
4. Good technical support.
5. A UNIX-like interface would be nice.

Thanks in advance.
sHaNe

email: syong@onramp.ardfa.calpoly.edu

---------------------------

Newsgroups: comp.os.vxworks
Subject: for sale
Date: 8 Apr 92 20:42:42 GMT
From: fester@etorofu.island.COM
Organization: Island Graphics, Marin County, California
Keywords: heurikon
Message-ID: <1992Apr8.204242.841@island.COM>
Sender: usenet@island.COM (The Usenet mail target)

For sale:

Heurikon  HK68 and MLZ-91/21 Microcomputer.

Includes all manuals and documentation.

Still in box.

$1500 OBO

Mike Fester	day 	(415) 491-1000 x190
		evening	(415) 750-9220

or email me at fester@island.com

- -- 
Disclaimer - These opiini^H^H damn! ^H^H ^Q ^[ .... :w  :q  :wq  :wq! ^d  X ^?
exit X Q  ^C ^? :quitbye  CtrlAltDel   ~~q  :~q  logout  save/quit :!QUIT
^[zz ^[ZZZZZZ ^H  man vi ^@  ^L  ^[c  ^# ^E ^X ^I ^T ? help  helpquit ^D  ^d 
man help ^C ^c help exit ?Quit ?q CtrlShftDel "Hey, what does this button d..."

---------------------------

End of New-News digest
**********************

From daemon@vxw.ee.lbl.gov  Fri Apr 10 04:00:26 1992
From: daemon@vxw.ee.lbl.gov
Date: Fri Apr 10 04:00:33 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Apr 10 04:00:20 PDT 1992

        Subject: heurikon

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: heurikon
Date: Thu, 9 Apr 1992 16:41:29 GMT
From: fester@etorofu.island.COM ()
Organization: Island Graphics, Marin County, California
Keywords: for sale
Message-ID: <1992Apr9.164129.8597@island.COM>
Sender: usenet@island.COM (The Usenet mail target)

Heurikon  HK68 and MLZ-91/21 Microcomputer. Includes all manuals and 
documentation. Still in the box.

$1500 OBO

Mike Fester	day 	(415) 491-1000 x190
		evening	(415) 750-9220

or email me at fester@island.com

- -- 
Disclaimer - These opiini^H^H damn! ^H^H ^Q ^[ .... :w  :q  :wq  :wq! ^d  X ^?
exit X Q  ^C ^? :quitbye  CtrlAltDel   ~~q  :~q  logout  save/quit :!QUIT
^[zz ^[ZZZZZZ ^H  man vi ^@  ^L  ^[c  ^# ^E ^X ^I ^T ? help  helpquit ^D  ^d 
man help ^C ^c help exit ?Quit ?q CtrlShftDel "Hey, what does this button d..."

---------------------------

End of New-News digest
**********************

From bard@cutter.ssd.loral.com  Fri Apr 10 05:43:17 1992
From: bard@cutter.ssd.loral.com (James Woodyatt)
Date: Fri Apr 10 05:43:26 PDT 1992
Subject: Exabyte 8200/8500 driver wanted for VxWorks 5.0.2
Does such a beast exist? We've got a bunch of 8200's now and we're
replacing them with 8500's. I've got a driver that came from
I'm-not-sure-where that we use under VxWorks 4.0.2 but it makes some
faulty assumptions about the filesystem for 5.0 and the SCSI interface
is otherworldly.

Before I go blindly into the task of porting this monster, is there any
chance of finding a driver already built to go with the 5.0 scsiLib?
I've heard rumors that such a creature exists, and that someone on the
net knows where to find it. Is this true?

Please point me in the right direction.

--
 __________________________________________________________________
|
| James Woodyatt                 VOICE:  (415) 852-5429
| Space Systems/Loral (M/S G87)  FAX:    (415) 852-6286
| 3825 Fabian Way                E-MAIL: bard@cutter.ssd.loral.com
| Palo Alto, CA  9430
|

From susanna@tomato.lbl.gov  Fri Apr 10 14:34:36 1992
From: susanna@tomato.lbl.gov (Susanna Jacobson)
Date: Fri Apr 10 14:34:43 PDT 1992
Subject: SCSI DMA from offboard VME mem
In hopes of saving hours of search through catalogs and calls to sales
offices, I ask you, the vxWorks community, for pointers to VME boards
that

	1.  Do DMA to SCSI from off-board memory.

	2.  Run vxWorks or run with vxWorks software.

And of course if you have actually used used such a board, I'd like to
hear about your experience.

(I guess I wouldn't object to an SBC with DMA to SCSI from its onboard
8MB of VSB-port data memory, in excess of any system memory.  However I
am also guessing that boards fitting that description are less likely
to exist than what I have specified above.)

The current system setup includes a VME crate, with an MVME147 running
a "Taper" process among others, that receives data via VSB from other
VME crates and then writes to tape via the 147's SCSI.  (MVME165's in
the other VME crates write directly into dual-ported VME/VSB memory
cards in the Taper crate.)  Since the 147 does DMA to SCSI only from
on-board memory, data must first be transferred from the dual-ported
memory to the 147 onboard memory.  (The 147 is running Version 5.0.1 of
VxWorks; the 165 Version 5.0.2.)  The goal of this query is to learn
whether we can add a board to the VME crate that will eliminate that
intermediate mem-to-mem copy.

Any information welcome.  
========================================================================
Susanna Jacobson			MS 46A-1123
SRJacobson@LBL.Gov			Lawrence Berkeley Laboratory
VOICE:  (510) 486-7801			1 Cyclotron Road
FAX:    (510) 486-5936			Berkeley, CA 94720
========================================================================

From daemon@vxw.ee.lbl.gov  Sat Apr 11 04:00:24 1992
From: daemon@vxw.ee.lbl.gov
Date: Sat Apr 11 04:00:32 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Apr 11 04:00:18 PDT 1992

        Subject: Differences between shell and sp task starts??

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Differences between shell and sp task starts??
Date: 10 Apr 92 06:32:07 GMT
From: paulg@tplrd.tpl.oz.au (Paul Gittings)
Organization: Telectronics Pacing Systems
Message-ID: <1992Apr10.165244.20964@tpl68k0.tplrd.tpl.oz.au>

This is a beginners question and I apologize in advance if I've wasted
bandwidth by asking for information which I should have been able to find 
in the manual (I did look, Honest).

Are there any major differences in a tasks environment when it is run
from the shell:

   -> main

to when it is spawned off using "sp" ?:

   -> sp main

The reason I ask is that we have just started to play around with vxworks
and I wrote a simple "socket" program which, prints a line of text sent to
it from the unix boxes (code is at the end of this article).  Well if I run 
the program from the shell everything works, if I use sp to spawn off the 
program the target locks up and has to be reset with the off/on button.  I 
traced through with vxgdb and for some reason it shows that accept() has 5 
arguments instead of the 3 I would expect.  The extra two are 0xeeeeeeee, 
which is what vxworks writes to the stack right?   Within accept() (or a 
function called by accept() ) a call is made to bcopy() with 0xeeeeeeee as 
the length of the copy, no wonder the target locks up :-).

We have vxWorks 5.0.2 and our target is National Instruments  VXIcpu030.

Cheers,
Paul Gittings
________________________________________T_e_l_e_c_t_r_o_n_i_c_s__|/\  __
                                                 Pacing Systems     \/
7 Sirius Rd, Lane Cove, NSW 2066, Australia
61-2-4136963 (voice), 61-2-4136868 (fax). 
Telex: AA 120576      ACSnet/AARnet/usent: paulg@tplrd.tpl.oz.au      
- ------------------------------------------------------------------------

/* Hacked sample program to try out sockets on vxi target */

#include "vxWorks.h"

#include "types.h"
#include "in.h"
#include "socket.h"

struct sockaddr_in cnnSocket;

main()
{
int sd,ns;
char buf[256];
int fromlen;

sd = socket(PF_INET,SOCK_STREAM,0);

if(sd < 0)
  {
  perror("socket");
  exit(1);
  }

bzero((char *) &cnnSocket, sizeof(struct sockaddr_in));
cnnSocket.sin_family = AF_INET;
cnnSocket.sin_addr.s_addr = htonl(INADDR_ANY);
cnnSocket.sin_port = 7000;

if(bind(sd, (struct sockaddr *) &cnnSocket, sizeof(struct sockaddr_in)) < 0)
  {
  perror("test->bind");
  exit(1);
  }

if(listen(sd,1) == ERROR)
  {
  perror("test->listen");
  exit(1);
  }

printf("Socket = %d\n", sd);

for(;;)
  {
  ns = accept(sd, &cnnSocket, &fromlen);
  if( ns == ERROR)
    {
    perror("test->accept");
    exit(1);
    }
  read(ns, buf, sizeof(buf));
  printf("server read '%s'\n", buf);
  close(ns);
  }
}

---------------------------

End of New-News digest
**********************

From daemon@vxw.ee.lbl.gov  Sun Apr 12 04:00:22 1992
From: daemon@vxw.ee.lbl.gov
Date: Sun Apr 12 04:00:29 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Apr 12 04:00:15 PDT 1992

        Subject: Request Basic VxWorks Info
        Subject: heurikon for sale

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Request Basic VxWorks Info
Date: 9 Apr 92 15:09:54 GMT
From: hoff@bnlux1.bnl.gov (Lawrence T. Hoff)
Organization: Brookhaven National Laboratory, Upton, NY 11973
Message-ID: <1992Apr9.150954.5631@bnlux1.bnl.gov>
Sender: hoff@bnlux1.bnl.gov (Lawrence T. Hoff)

        I wonder if some experienced VxWorks users could answer
some questions for a non-user (me :-), so that I can make a rational
decision about using it in an upcoming project (where network support
is crucial) ?

        1) Has anyone used VxWorks NFS work with NFS servers from either :
HP/Apollo NFS (Domain 10.3.5) or SGI (IRIX 4.0)? What other NFS servers have
you used?

        2) What is the maximum number of (simultaneously active) sockets
in a VxWorks system? Is this configurable by the user?

        3) What is the default size for a UDP socket (what is the maximum
length that can be used in sendto(), without first using setsockopt())?
Is this configurable by the user?

        4) If the answer to 3 is < 8Kbytes, does VxWorks' implementation
of RPC use setsockopt() to allow 8Kbyte UDP transmissions?

        5) Does VxWorks support parts of XDR which are *not* needed for
RPC (specifically xdr_stdio_create())?

        6) Does VxWorks provide some mechanism for allowing a task to
'clean up' I/O objects when it is deleted? Specifically, if a task
creates a socket and binds to an address, but then the task is deleted,
will that socket (and address) continue to be in use by 'the system',
even though the task has been deleted (effectively 'orphaned')?
        I would be content with the answer that VxWorks has a 'signal'
interface, allowing one to install a 'signal' handler which can do the
cleanup. Although this would require me to *only* delete tasks with
signals, this is acceptable. The VRTX32 solution of 'task delete hooks'
is ideal, because there is no restriction on *how* the task was deleted.

        7) Is there any word on Xclient in the near future?

        8) Does VxWorks provide 'C' function prototypes for it's system calls?

Thanx in advance - Larry

- -- 

     _ @_      _@_      _ @_      _@_       _ @_      _@_      _ @_      _@_   

---------------------------

Newsgroups: comp.os.vxworks
Subject: heurikon for sale
Date: 10 Apr 92 17:35:05 GMT
From: fester@etorofu.island.COM
Organization: Island Graphics, Marin County, California
Message-ID: <1992Apr10.173505.3673@island.COM>
Sender: usenet@island.COM (The Usenet mail target)

Heurikon  HK68 and MLZ-91/21 Microcomputer. Includes all manuals and
documentation. Still in the box.

$1200 OBO

Mike Fester	day 	(415) 491-1000 x190
		evening	(415) 750-9220

or email me at fester@island.com
- -- 
Disclaimer - These opiini^H^H damn! ^H^H ^Q ^[ .... :w  :q  :wq  :wq! ^d  X ^?
exit X Q  ^C ^? :quitbye  CtrlAltDel   ~~q  :~q  logout  save/quit :!QUIT
^[zz ^[ZZZZZZ ^H  man vi ^@  ^L  ^[c  ^# ^E ^X ^I ^T ? help  helpquit ^D  ^d 
man help ^C ^c help exit ?Quit ?q CtrlShftDel "Hey, what does this button d..."

---------------------------

End of New-News digest
**********************

From leonid@amil.co.il  Sun Apr 12 07:08:55 1992
From: leonid@amil.co.il (Leonid Rosenboim)
Date: Sun Apr 12 07:09:03 PDT 1992
Subject: Re: Vx Exploder Digest

> Date: 9 Apr 92 15:09:54 GMT
> From: hoff@bnlux1.bnl.gov (Lawrence T. Hoff)
> Organization: Brookhaven National Laboratory, Upton, NY 11973
> 
> ..... 
>         2) What is the maximum number of (simultaneously active) sockets
> in a VxWorks system? Is this configurable by the user?

Configurable, actually as maximum number of file descriptors.

> 
>         3) What is the default size for a UDP socket (what is the maximum
> length that can be used in sendto(), without first using setsockopt())?
> Is this configurable by the user?

4400 bytes, if I remember well. It was some time ago that I've handled that.
Didnt look for a configuration parameter to change this. Used setsockopt
on the socket before that socket was passed to RPC.
> 
>         4) If the answer to 3 is < 8Kbytes, does VxWorks' implementation
> of RPC use setsockopt() to allow 8Kbyte UDP transmissions?

No. I think I reported this to WRS, so maybe your version already will
include a fix to this.
NFS client code however has it's own RPC library, which apparently works
just great with 8KB buffers.

> ....
> 
>         6) Does VxWorks provide some mechanism for allowing a task to
> 'clean up' I/O objects when it is deleted? Specifically, if a task
> creates a socket and binds to an address, but then the task is deleted,
> will that socket (and address) continue to be in use by 'the system',
> even though the task has been deleted (effectively 'orphaned')?

By default, the socket will not be deleted, simply because the application
could have passed the FD on to some other task. If you want to do such
a cleaup, you can use the taskDeleteHookCreate() and program whatever you
want to be done when the task is deleted.

>         I would be content with the answer that VxWorks has a 'signal'
> interface, allowing one to install a 'signal' handler which can do the
> cleanup. Although this would require me to *only* delete tasks with
> signals, this is acceptable. The VRTX32 solution of 'task delete hooks'
> is ideal, because there is no restriction on *how* the task was deleted.

Vx's solution is as ideal then.

> 
>         7) Is there any word on Xclient in the near future?
Sure there is. It's a whole product from WRS ! Plus there is one from 3rd
party too, and an Xserver from 3rd party if you fancy.

> 
>         8) Does VxWorks provide 'C' function prototypes for it's system calls?
> 
Yes, and they're supposed to come out right with the current release.

> Thanx in advance - Larry

You're welcome.
---------------------------------------------------------------------
| Leonid Rosenboim                                                  |
| Freelance Consultant                   P.O.Box 13652, Azur ISRAEL |
| Computer Systems and Networks          Phone: +972-3-5561-661     |
---------------------------------------------------------------------

From mea@sparta.com  Sun Apr 12 11:20:10 1992
From: mea@sparta.com (Mike Anderson)
Date: Sun Apr 12 11:20:26 PDT 1992
Subject: New rsh support for VxWorks
Greetings!

  As I had promised, here is a new copy of a working rshd for VxWorks
as developed my John Monroe here at SPARTA.  I checked with him and found
that he essentially completely rewrote the vxrshd from the archives
in order to incorporate support for the Berkeley flavor of rsh.  He
used the good ideas from the archive's version (thanks Benny...) and
grafted them into the UC Berkeley code and got a pretty flexible
version for VxWorks.  There are a few caveats that are documented
in the code, but the vast majority of VxWorks functions work even
if someone else is logged into the shell!  Well, the file that is
attached to this mail message is a compressed tar file that's been
uuencoded for mail transfer.  There're 3 files in the tar file:

Makefile
rshd.c
rshd.c.VxVer402

The last file probably isn't needed because John's incorporated all of
the 402 specific stuff into rshd.c and used a compiler define flag to
deal with the make.  As usual, there are no warrantees expressed or implied
with the use of this code and SPARTA, Inc. makes no guarantees of 
merchantability nor fitness for particular purpose, etc...  This code
is FREE so please respect the spirit of the Free Software Foundation's
copyleft as we do.

Good luck and have fun,

==============================================================================
    AAAA  D D    D D    EEEEE   M   M  TM  // AAAA RRRR  TTTTTT SSSSS EEEEE TM
   A   A  D   D  D   D  E      M M M M    // A   A R   R   TT   S     E
  AAAAAA  D   D  D   D  EEEEE  M  M  M   // AAAAAA RRRR    TT    SSS  EEEEE
 A     A  D   D  D   D  E      M     M  // A     A R  R    TT       S E
A      A  D D    D D    EEEEE  M     M // A      A R   R   TT   SSSSS EEEEE

Process Distribution/Control and Communications for Distributed Systems

Mike Anderson                       Voice: (703) 448-0210 ext. 235
Director, ADDEM(TM) Project Office  FAX:   (703) 734-3323
SPARTA, Inc.                        EMAIL: mea@sparta.com
Suite 900                     
7926 Jones Branch Drive        "The optimist proclaims that we live in the
McLean, VA  22102               best of all possible worlds, and the pessimist
                                fears that this is true."

                                    J.B. Cabell

==============================================================================
----------------------------- Cut Here -------------------------------------
begin 644 rshd.tar.Z
M'YV03<*L*6,F#9LR !(J7,BPH<.'$"-*G$@1 (B+-FC0 &'Q8HP;,SA>]!A#
MY,B1-&+,L'&QQD<8,V+4N&'CQL@:-6S$L%BQI\^?0(,*'4JTJ-&C2),J73IQ
M1(($6T"\J#-'3HX7<N:@(?,BX,""!T%T43""[%,J;T",D5,F#)TR((0\H8($
M!!TT<-/DL $#1!@W9$#8P $#2U\[9;*F>>-F#H@W9D!DW0J"S9LP@=N\(5/G
MX!P79,T^E3(%R9>],%R\>>JB=0++F$%HYAS6S!LY()*X><L&A%Z^(.#(>3.F
MS)PYM^>(3D#:]. EJEF[GMT9KFW<3=[0N?V&31C!A T''U[\^'#E95TL*5($
MRI<I5()0*:)#@0(G3Y@D<;)D9 \0+8P!@@)-R%?72?^UT,9@.. 0PU,)C ""
M$;>I-<9@:ZCU1AMP&)08"'?@Y08(5*7AQAG@-5@28W:%(<<99=!A'Q)&?&'%
M#(45D4""1 P!114]-#'$8##UU0(=<F"6!AV+N1%&;R2@4"!=*4 H(9'BF1%&
M&P;EH0"-7R2!VHX ]OAC#V+R-400  :Q)H!(*LDD8T]"^)2$O_4%@I9<LN$E
M62T$*NB@A!9JZ*&()JIHH&8] 4=B;IF(XA1YS/%6&RVPY=U;@9GAW1GHF866
M7V.,L>%F;L%UA8F!29$&8G*<X!A;3G)YXF.1V>'B8E3MZ>$<+)B% AMI#*06
M&G^=(2D((M3!9!MEN("&"':E)<(<E3X;[;1[5FBBI7\5EX)98< !![%C1,J8
M8R&F,08:LE%%AV1UC,AB&YTQ>2Y<L,[1I&.0@6 %'E?<M@9Z":0[(F:!?4<&
M02;RNVL88H2UG5UX:<BAAY5%[)=C6KUQQXABE&'9'?65-8057]  @PQ/]9! 
M"T18@<453TBQQ!1?%*A$SC8605H23SC1PT9<*&#GS$FX & 24U5UE1UWO(#&
MTE8*3+#!CM'@0FHR*(WUV';BB9K8$"JP\A<UP!0S"#/7?'/.._<<Q,]2!#UT
MT3W4 $+22[?0]--16_6"'5O+<7 +J!U^1PMMSV!UU@,7K+AC-7SMP@QHDSVV
MV7S9MW;;#Y(9M\TXZ\RSST!;(?041!OM-^!V"NZTX(5/G?CB&!Z^^QR0PQ##
MY!)6SC4(F:<60^>>+WTE#DN(SG+;,)M.,^ITKWYWZZ_'WO??S-M..%6&(VXY
M[SBLX?OYP%-/O-;L(Z]YV,V3_7ST:K,\1;U/3/&V^+@CWPM,- 8VU.%A]@/!
M_MS0/^;5[TX*A$(0I# $<,UI1$F PA#L,X(.@F!T+WL;TVX'-0$22PQ/BY(5
MKI""R44(!%<0D<"NX!N0Q:A;N$F>"\)FGX&AQ@AL )7,H@2F-,$@!1>)$@AG
M@,3KS4UU"A@8AH HQ 00L48WRA$2E3B]ES51;JG;F7T4\"0VZ& TI0F3$^;#
M!.:DL0ESR5E^@C#&$?3@CGC,HQ[WR,<^^O&/@-RC68:PH0Z%Q00@8(*),O2=
M?C4)AQB#BVYXXQO4[&E+7<+5>(AC'.1D)33-42,;S^A&TZ!&-0-20"A/^88S
MGJ%4S5&-TL[ !C)8,E, 2LLJ^8+*5XXAEF^8Y1SN0+%;]F:7J0EF A3@2V"2
M,@&3(8,+QC#+4EDR2OC1#W^:F)9FE@:5*L3##X,X!R1&<YIU#*0ZU\G.=MYQ
MD(7D&"(5Z09&@L"1++I.)$&0G>T,QSO@@0$>^L*G3 9,.)P\3G) ^<8X2F&.
M9PSE<U!I'XE"3S5GA.4WE5E+# $(-RW091HGNAJ-(D&6"C I1I]R3FHF[$+I
M P$V\[.?)7#30L"4*0JDF#XJEE,R6I$F-17 E*(:]:A(3:I2E\K4ICKUJ"U]
MJE0E,I*,;*0C(/A(2+":U9)P%2,SD,$,_(:\C\@ !C2! 0W(BCP9K)4G4XVK
M7.=*U[K:]:@O4('2HM)2L3S%>)>[9V+\Q:* 2:$,FGF+ O'"AMZ0(0R(98S3
M4ID *J A#8ZA0QCFD"&%@:!DE;G,PQH&&-^XP0YO&$BGAM,&OX  7'*@0QW@
MH+$V_*5ACK%-8T4VA_HL$T)N,,,<LE.O>8D #6^PE A8P"RPE(%2ED+L<IEE
MF72QP0E;*H,(T#:&P(B@5MI%6W#G$ 1GH:$*;D@#'J80(Q0<-[ETF&X=TD &
MYBJKOB X$7V!Y9?9?N&^Y41;+4' @]!B)CNT*0/:-,O9*< A#"-S+WBG*YS%
MR&%)>6#N&^!P0?Z":PQKF$(:]% &YI9A-W+(0Q#(0 :V'&=<]DE $?"PI7UI
M$C9D6-9M7_O@D2WK+G Y;&+A,@7&.A:RFG'#&<5&R-V<F X BPR07ZO9V,[6
M5P<A)=JVD+L7J.$.;7B!$-Z@'2/\:H"-LX/+9/ "V,H6#BVPPBG'T 8RC*5S
MXR7N;IC%V,7,8;HBR!V@N[Q=.W6765U&G*7J8 8S%!JXPBWO7="K7O;2 05\
M-IF?IQL#L3(W!\R%0:A!,"X[#;C B<;#HAO] F!VCL$A[K$;,"V":$XW!Z(&
M0:YC (->Y_H+T21UC&,<!#.\!3=39LN07VMD$#PVLB/"K(%'ZY?2SD'690@,
MBZ8,V(.! +F68J[2IDQI/(#@!),Y06UW[%G04B7;U0I.8J[36F5K!RZF:H-M
M 0,P-XP;6?,"][Q08(<T?.<NT@XVK)&XV6[M]@Z]59K2C,#:#Q+KR;("0;D7
M:S(S+O,D<(.F5D 0E1;TYMUR *]8O@U?E4<EW_L.S%A SM*1"]SE #KY'!*C
M\BZ0?-VEO;/$94QC#GE&DS"_+;LN^RX8TDV!51C"$(HPA2D8H0I,8$(60+0D
M>"$<9$:NC]C@!?*1;,$-/B^[VJ%PX3VCH$([IP,2M=+Q;V/6GUYZ2AK4?I$M
MP#KM?%=@'?3MHCQH$M9S4#<5AB $Y3R%27R'=>!/0DBCQR@OP4T+BQ8O!$C"
M6FS7YCMFY, "%X&J-9,]B8,AO+ 6<9:Y%>X!KW.]83KT(->66D,/;N!KL<%Z
M]2/+;W994&$6U)X%N2]]BTO_HL^T1H&R=NWG'Q\8M4M^\A<A@LDN+_W-KL'W
MCK&^][%_D?U=^\0-<_WW'X\;\7.6_" X[!P&#Y>#>U]LU5?[%D:_!1:XX0ZW
M009ST 6 1P28=2YA8'C0HADI)C9P8 9PP%Q0%H&2D084"(%]]W?9=X#>87@/
M2('7QEP71H$[AH$!8W^<)39R, .9(A/V!0,M< 8QL!$GX7?>EW8&>&T=Z%IL
MH2S1A1LGJ'YB@T\C G]EQW8F,B_=YAA$:%JVP5P[)@9D-B_$X@8*IG=;HG;-
MLG-R( +])P(/=AQW0 8BD':61B)<*'S04FV!$8;#1 9B$R*7P25&N'9M-R\H
MIX97F  /8P?A5X=EITB6XFQE4'#E(3:'IH4/=A?4,GEG. 9U( >T,B\ J#C+
MLHAHX(!C"(A\AX1[5HEK<(END8E/P09_"'); (:C6(:!)XCS8BI.MAM1YFQI
MP!9C@'=B,V#ZARUM, ?]YP9O$ 12&%L$F$BB166!82*F=3$+>!M>0G,)P(EJ
MAP*\Z!C_P3"OE0=M((6F&&^:53%E4!_0*(UJUP(E\1_ :(6C]A^T] 9B\"3\
M=8Y^T5BE]AIK<&6H>"UU( :6TH6 =Q*NF(W;V!V.H8S8$EVMQ8O<V"+@B(AX
M 6)3H%D@EH$WV(IWIWY4%@83Z2\DYA@[1A5A ",.>(=%((G >!&Z8D!P$7B>
M."]3IG)!:$&]DI)UL(<Q5GDQMW3N B]$\ 0@@!]4X'0ZPW5W@3'21G>-Y5L)
MP%BT18XCT9)&Z1C$8BGX)P9G@ 0FTY32")4/(P9U< 8P@AM,Z83*E "M)7HM
M9H0(E@9FH("1U8!/,5Y8R09:R8E0.5[?EI5D*3962 =S69> >)<Q HIY29=[
M^137E@=_Z910*7F792EO< 9)HF\?,I8F8AN@!P=YEP")&9$;YGMI "UXL)AV
M>8<@4 9X4 :0>$%V$9J5J9>7698WN2$Y"2),!R_(@A@_.1>?508G9A?&P2E$
MZ76/R6P=IY2FHIEEEXHF4H9?^ ;.PHH704C*J8S.%6_0.2_7B0)]\1^6DHQN
M\ +968]M<%B@@HH:.'EKV9;=QUD9UX-W-UC+""FW^"HFLYF/<F&;<1([-P; 
M,GK,=WK/!WPC(GD78UV]80;U4I\LDI^+D6,(NIFTDETG(0+=088L\%UE< >-
M2'G(<B)P 9.1X5PJ6 :/XA8GX0;*1WJFYWRI!WVLAY$'6D9[LJ"L6:"NZ1C<
MV0/748B)48\YQEDFLB07(0)]Z"[:%7@4(@>V-2\[-J1,\B0C%F148(XE<:3%
M 7IQ4)-E0&(C8:2%B*0=6G93L*6^Z:5FP!9P<6T:"1<L(@55&@-7&J99.D9$
M5V-'=X*W6 =/8IR-!70":)L[^5J^V5H70YA/L 1*.1F5Q!?FJ!;>U65?%F9C
MT!@Y0 ./QJAY\JAP,(8J.'*;6A*F^*GP$JJ5X5T\@ 1+( 1?, 14( 5,H!J9
M"JJH\:AL<(^T=5QP@ >S6JJU6A*AAP:[REPB$ ,Y( ,N0 ,XX )R&@.; P. 
M9JPRD . IJJLZJJP"FC7QJN=<QNDVJ@P6!*_%WW":FZSIVMXP&L@X"#'^FV[
MRBS2FJS+VJS/2BW%>JS4RBS6VJJOR@3VNJV/]JVFNG<B,*8C42$GH:F_ZAO,
MTI=4X'V]"JZ/&A@"=:X"=58"N[#P4K!V@@+*@AB.\9AXITE+Z*=LP%S ."]Y
M )U948\*ZZ@E46&[$1DG( )S:1DP=!L#AGK,<@)/@0(I"Q=D )W@" );JAW+
MPA9QT :[X;*T"K/'HIHA)I$9HJ%T\+"<%;&FRA92J!W#1B";P9;NHBZ-X5LP
MP!)&4 9BP%S&>JP),*E/,03RLB%3JFT7IBQ.TAM1)P2),1!^HB$/ TE+Z$!+
M0T &E&.WLGW0(HM[4G$E6P5<F'%',!RS1;AVXB+O8I],.%B/%#"(,QE* Q/\
MY")LFP-N"[<)< 7#H5@EBY2]@5B=0;: >X5H!0)!(!RE>[I@]A3KF0;PAJ"9
ME187LV$GA@)(A$BU9+SQ]J%D<!"6FP EVX0/\RB <6)CX+N.42*W,F7/FV^&
M)#$71C%A(0+8HSIV@S=Z SM%LUWVH;I+\A8DDP?/I 1O@ 8CDAUN,!QE "%3
M($%P&@3,I1MCX (_RWM,! (:@0,M\#*\I@#N], 0',$*H (OH !YI0(C\# %
M887Q5QI$\ 5$4 1"4 5'H (4;"=Y18@;;!T5TI5?.1Y)F)V.0<$<9+@'M+\\
M8#Y<(RT^0!8V'+@\@!P@%B,\[,-N4$ W3& F4L0C\,-P$<250BEM0 454\1C
M%$W&JP![H#1)"#<59ELI!@6W00<[P,6[P9FJR1B/%<9C7,8)D(2<21P#00=?
M0 < Z,;]6 >W^%IRS#!R\ 7*6%UE/!+OXB()<W&[@5W0L@4Q8 -=L ,0DL(%
MY+M[IG([MV=B8'CHIA7JEG2E1<.$C"QRD  HI\AEP,B.#,F1K (CD8>6_&2?
MI<GI!J@@ ,H74<BC3&=DX)5FP,@R@ ./C,*L/,D8YQB>'!@TK#07++-T8 ;N
M%9$NPB2W4K*;O!7J]FQ)Q@5N( (IL ,F7,$#D@!YE0!#P!:ILD](",:&)\1S
M#$G$+(L)8,MO'!DH@ )?7'AB'%L@X)UR?$,H$ 0ULA]%0 7,-05/, 1+\!ZO
M6@1!T 0!# 50\%!4\ 1?L'A0D )(=$< $@-(M,4GD0#Y.1QRX%[L'",ZH'%.
M4K07 R/STH]MD9#]'%_=+#9GH!UIL<&8-<APTP?V<1&O01PNX"]N\ 5^'-1$
MS6*X\1_[$01$0 1Y$P1.D 4Z_=,#+-1?4%!_"W+_ =!J--!375U!;2)?  =C
MS'?_@0;;T1@HX!(TT,U2P<I2,'+''!QEG<SBK ()( 2LPL=#[)+"FS'5K&YD
MK<]L7<O@##=L"0(H( :L@FD@?6'JG,]T$"P^W;%YO,?L[,>UG (F4%V437Z<
M.:6008U(HL<MW<=(#<AN@-'[G" </2 CD0 >7=DA?1ONQ=B <=+<K-,?7=,7
M@]-S,-4)P-/*C->N^)OZ],Y0%F\(:EKQ?-CSK-A3";_V#-GX/,8L( ,9[=H=
M[8")(=+N-=TGI@.[3=,V[2OI%=P*L--V.LY-)LTU&6])MB05,F7I7'ATK<_Z
MI)%,4G!T8'AVG<*6!1>,BLTL<@*PIGT=J&X6A%BP+&U_X1=T<"D<%F_?DAA.
M^EJV]:=*4\N$N(,E8\>^&6VGE5ID^QD785E'6:C!6YBT)=19&HVL;-&$BE@@
M<S*F]5GF'(K;FS&P:(4,:B\C,MCSPM:@(>,5/'$Y4P2N(P4@L,5ZY\R/0;U?
M4-*79@+WS,:QQ5PFT)]J?-U;#@)='M-U#(!(Y .Z1FI/'F-/D5?,<UBQ,65W
MH::V.P5#D 1)0&5M!RHGK1:(3 <M@'(M %[!LC1<""N!SH6#/GQL2,O]*"E'
M_A0T#"$LW8_42.9V_ ;,I=RFS%P<60:CS>G9E0+$*NK04MZ4'B.6;N5EKNEH
MF!B=_EJB[<RE/.K$6NNG/M,^; 8:W,%(\,$A/,)'@#;,[,PBH-P[D@ E, ?:
M/%VF7@8S#2'%3M*) 2MD @++WNS,A>O07L8C@'YLB39NOC3%=FSW)*6/)<TH
M@G*>CGXHK5[G-LLML$G;82J]<1',HY%K (QW<!!D ".Q3*B H6.R?B)AD<F*
M%3"XC=\D-AR1GC9+8\*L[ 3WUN?XH7%3(#0"$P3Z003R$3NY,05Q403[<00@
M  5"8P0YTP1%0 2U;,+,(_%\E\E1*1G9Z3$H*AS&\60OJG82SSS,,^!Z+BG&
MS!B:%3'@>6[/KFZ(= +<WLD1#EK,\VZ!<3%O,8CZE)+T]>I9X1N1\3#^PA;2
M=!$GL/3,$S*=$1B@-64HEW&6@;>YX?+M$A9.SX6FK&YW8!"]P3RP>/0C4@9=
M]R%L'[E2&9G*F 0N7R'?\>BWXH;PQCS*.&6!K18TB@)3=G.C_O"3_A1W<&%O
M<>E]W>H9NEP<K<IW;;L3J=SO*=>TN6/)+.YZM32'51SVZ5J3/]=INB'[)'#Y
M7EJHJ9K.DA<#E\EN^&,9T[I&IOE)GNI0AB2@/\>BKQ9UQLN>/NLHH,N\3.K,
M@OV,ANI/\?NK609#4&?7/_V,YNF8#H#M#HMKG >2K>NQ?<C)50;/'R.MWLW"
M# (#KJ+ R:0F<LY3YL>I)M9DRT). 9E_U"B- 08P)W?*F-CH VV.E24VY59#
M*%]C61:;S_=X'P67@%  KL%_JZPRW!#M@!>0C?>9%?6B6J2%24?<@-N2D7\[
MI[J%)@88[=B";$DYIF]II##41*0NQD&Z%(9- 1 W!<  +)C$.X)(, DJP27(
M!)N@$VR"2D/%.08F0!SZ5)&I.[!K4QB'?8+\Z@Z[B7!R( 4VG.\@ ZQ-\E,:
M26"YP8%(1-9V3@6\&. O^.V3V]?Z2DO>NPO9"034-.-'N<X *7I)MV'#F2S%
MUBZ:CFTQ/*#E[<$(\'0Q4-24T0P+2.Z AB=("2NA);R$$B_),8&#QO$42'R@
M E5 Y,7!MS#^R$#YVV7GS\]1,CHP!>38IOMS)4FDC0M<%L^XGQG(@3IPF/TY
M6E:%X (-ZV*';!6V0A#S"E=A++P-.R#^2;)=^)UT@YA#1D_ 6?"U.3;#*M@6
MRV 0PPHE@*OC!%Q5[( 0I>/T*:@CQIH,DC9:2-\H+- P;+C"$@ 2* )8P$9P
MO"J@(Q) ]3A])T"@J)L*D0^Q (-#$LLB8.089;'<UJ$&BQ@)((0- 7G(!.CA
M4Y@!(9#QH0B!J)IFH&-) P2Q&L886AC/3(\=0&7!+ 2.PR ' E8 B: M%T,F
M^(7F$P3?V!E+ *9G#.#"T^<&!D_) $*1P?30'\;E^-2>+.-D+9$CJ@!>!,UB
MRXII,:8OA;D9OX#41I<:J!!FX!:-"&I$@6J)B:$# PR)3#JA&!7I@!LHBG3@
M*,H!59;"-%L3,!%042HJ-LE3,I8%FQH9V48K5K $ !_D0RB$&S)I#AR6&^@&
M_D.B(HNL+%&] *'Q4)Q<7I0,,2(262&?6*/(X2.9=' L 12$K! 67T0.3&'_
M@1MZPZ+!7-YA/+0"\[ (:!C<H! 9(CT,@CZ-(_(B4[8%,D)(/'T*J3OHH6Y1
M+P*#%7(1KJ49I1BFV&(Z25 494^A-@X64\$6A "C:8TT()BEL -ESA3+":AR
MVDC=T!ND4P>1&73K8C[M0D4D,J ;-$PMV8[1<+(]AN](!\A +(1D.Q /W!VW
MJ%D6H!P(#%##)_$ZC9@:15G(40%P8,5D!5RX U&,!WH#70P%^+%.@D0"QDCL
M,*@1;M0+?W$&%N.QP(W_[5%<1E9V(!^)"(B02:H  D/)2 9F8@J[3F!O+5@@
M?X*=J->[,S?.12/FM2>0'_3.'- ^UVO#3<A]]JI.8V)31MR)<9B39%%B3I,I
M@@L]P APO(P7!,T8'= [S$4->$A6QB7F0'%H+'\!U/4*"G<;\)NN"%_@B#XB
MMI>8DC1,H[$TS"4)68$G49.@T(M@ B?&C0E%TP,%D(0#7&]P0SN6Q_"XSWS#
M&S@"EN$=L8'M> 3\&7SX8$^@"E !$*@4PX!NN@T8\?_UAN_T&*2A/%L,>-(=
M/8GM>(90P)_\ H&2H*G")S,,UX!;BVU*\88PRCRH3T8A_9.+/2U.DD?S*(GJ
M)*3,DY.R//;)@7,I"2.A9&5SP%"ZJ;NE*)%1HYP7C_).PLH]61XK9:V4 E*@
M&#Z98R@'/J5/"Y4MK3S^2DAB*I57,FMBO(X@^#I@)\)(F-*8=B( )^T8>D)D
M8!G-FPPG+=MMLTUG_LS 3/MV \\,I,JW]A2@@(MP@P&P.G8,#G;)Y@7-$SCQ
M#BA*GDEW'5! &K@]R3 -\(!&EC!7P I@."_B(Z8!G_,?G #680(.$":^" '!
MCNQ?B\(T_>@@S!I;J/ULH9D\ W: U&1,MH1I8B((0'-]H;OMNE[7'+BEL!M)
M2<C8H8!HD@+29<-@B?TRX 4V;;<27TFTDXRV[6#"@(3) V)BPWR8,&QFN9>+
M4 ("P[Q3E],E#9Q,B=D%WB6XDY=/06R,,[KHF[Q>5AE$.G%QS0L(]_?\8XZ;
M,K&Q-Z3#_;7YQF80*!4F:EX /B"#&TZ Z=F'?9.HO0AUTW!B -I\$3N1#A P
M2;?\YADUTD9F!C (@3Q@RA[G')!B5.QD%<V/" .Z )?+CRV&OY@ #+G=0$"B
MDIG0B"A6F;#8%/\#Z-R/:&,R6HH@\"+JI&:D K'# <:V/N CW> 60QL$!T"2
M@11P;>X0K:M>68$XE@'C: :(U1=8=M/%(VZ!SHG_RB*+.3=?0-TTPMI9 */<
MXVP#D9,,3,[*>9 P9\78=LC32=Z&Y9D*L9Q^%)VDL[693INRYLH.8M)&8%$L
MULG7J=[LA.RLC"@B,U:!;H@[BP9O>PK$;7>F$HE3V1(;"OB?M#. "E "&CLZ
MVNE+ E(F8QA.)U4[B4EN@4ZE)?)E#'E6/Y3B.92-<U,"[48XF)K"GV\ EHWS
MKCT%)'!;QM?YN5Y/@EJDBYV36VI1N(DD!2ICB  88862!!O0H9ME"]JU"!C!
MFJ@3O2.;SW'J.3H#!P1DQ)R>GI.ZD*'2>42>7 34HM3"\HV?3<C4S$D9,%.#
MZ%JR)9KIP4!8MQQV=@)<4L'88 2DXDG; LNN"Q!-Z4D]W1B$*)AJ0/8D0S6P
M,&/ ('68W:UP23G2)@=$IA5%F5M #73-EPD"M)N80R2,U)%*3TF*1!:F#4 B
MB71I@,N^4S6[P$DS/2B@:F8T;,?LUJ6>TZ17E),FR:T92;NF'X40/,U.\#1X
MF6/D9><8FP_+6*0+MG!X,H;8JT4#L'/E)[=0(3 -#T PU4'-15$9F@ HWENP
M>&F!396'WB3B?M,)X &$L[3@&-FP&:*IRIFF;!))U$GI&0,>6>< I @3!!#2
MD%F\V*DME:>(=,TITI;Y(MJD'*BE\O.;JALUMP>^J(NY(5/&]-"U)/0AINE3
ML*=UT@2DTW^J!E9 .P6,\>;1T1;(0+/ Z5-HB4M##.RXF7CZ=@R0X7\L;5J>
M!(>:2W&IG5IE3\%1_*9Q2AUJ \=0H_2L?-4-UI$WFISZ<@+RLZW!R9##(>LD
M\9HUFY.195$IP-!<'@C\HK "@;D <[,.OV8-RZE/9*=NCY[:/8J&_*P!XR+^
M%=7_<%3Y*21MI\R%J3*U4(,';H!;59E0]4-D#JI:P7AIN!NJ$()E\CH"HVNZ
MFUA];$DH%@(C[C33/IJT^VZV303LS*#2,T$ LYQR)V99.)?R9EA_%FJA+RD 
M7"[6K=!8A\!?0'"0E<2M0>W$,4[ LCL!+F"/7M%VJC+/GF:1+7HQ,::<.DD8
M<\8M#9MBE7>:#-_Y4E<9X7(+%,ZOA9:)E <U4GEH<7"SV1"NDM&C7@LQ,1?+
M(CX"B,_B+#:=T3,1\>TOY %BD@<>'N.$?%+.=5%!$(,":F01*)U"D@D0R5":
M_X(G9@67Z$5\P86+,5XSQ!5L+,W.K3G4TR<%*R!0<BU<B%<X!H0"CEJ+/N%W
MDX6ELCF82A=UI5J(1)/($Q*!_? ,X\Y)A"0X1E(\-SBY-.0D=QP1_^%52DIB
M209FI6*[E/NAL!)5O2,L1RRE])-4X(/M!^;"ZW1=+GP*<[3J90QWI 8&(#E-
M,,LH+>A& %=7':A.U1[HRZ>"/(TF5)=&2JJ3R4O7,!?S"E=#8%3U&G25+%A5
M;*G8CNSYXAY[ ZAJ-+#*/)[L?TA>N<:\TM)V6CU9652=JT'0KOK2I>%>AR>X
MI$E $ML%AO\@4$H 'B":7?+<]08;*\Q&0W!:GQ*6PB(23=$6\&7&<%T)LG"U
M6#WY8FEEC%4CWI$,;$?= /]6;'2C1D:FOJ* ])KQT.N0/*]#U=."-,0ZTFI-
M4#EIGG5$I"S$>!"2Z#YQ7?F5MZE: 5><I,U_77R)0<!ND@(+21!LD5P:!S &
MUM@9F6SA DTMIS95'2:YW'KZCNHS'*<H*$/45%\80R'@<ARC3X"I(48T"D-[
MZV[=0W?MB:I;"!9%6>84Y1"/E'-FT6L!![B9_.RB!?7TT=LP*GGZ5Q"X D[ 
MC));D/I OB@*N(/P0H.%@7P1'%Q$=CDV/P6GLM%?YT9O9APUGB2-MM11KWA'
M\ZAJA:1]])W:MD!J2.5I(3VD4!/*V0EWFTGK:2R=I&C.DIH 3$I/9\TFG:2>
M%)3J4U&*<1L1'K4SI_1%I-+A62>QIJ=#$K 4DLI2>4I+.>EM'6Z=8Y=:U5_*
MRL@98X 5VLE&/1*5$V^5*A*!@VZ3K'6Q 7D<""XU92]Y841I71;!-D^3VQ2A
M:^J$RDWY"B',KMW$FQ5N;Y; <_,W'T/@[+MC$'&JS15[;/,J/>-%X7-\9A?+
M:3XUISW]G.^3R\5/C78ZZV=EE8Q2,7^VSN#P/G5G91MNO1,N_$XZ>UF'9_',
MF2A .";/]<D\G2?T7+.V%*\:WN^9>"GGXBV?VBASHL^'L7J+8_ODGY(W#SR*
M%'!'*N]LN[Q=\2NN3OWI.COOO-2EH7?-R5X&2P52S(_)IM'G.U1(%C%K(9$D
M>C)_"\? FP+X>2VK\,RL/=>T)I[\HAVF#;R)8;+A+777C_L16>O1M!-Y<2\J
M1MJ*+&WK](6ZN76!KMSP^EJI@OZ=K2'@/]16)^=7_ZJ956Q)* 4X-DPS:@>H
MCWA5Q!-_+M^F6(_&!J9)OIIW^:Q8I8AM.H5:U&S[]:.&'.DI [*H])P!+OB*
M)D?F<OIR0,-E4BIR;%0VZ3F#DZHCHZ4W((M:KAU\18$9+<T!,?BL=D["5=DZ
M<-T-.8060M19](MZ10">+;I[%EWY64#[))C+DW5K47?!>EM6MF_7XOCQMP!7
MX-:D-)KDT,:YA7WK-@ZSDW9+@.4 %>VZG9-8C2O68V\U&K[]HA?2^Q H:J&T
MUG"Y+;BYD!!V'16&]&YP+TH!$E=;ULR*ZRTO;A7>P\%GXRH9DN-Q72D?C;W^
M<^0*4I,KIU N>_6>BJWF=EU.2DEE+LU%NBY7Z>+<1J9S5:XEEIH^MY0&W3,P
M=%>IT7VEL?@C+ETUT'1!L2X-PW)VP9X^JWM:,%QC)(E<UYY^W;3P9':CV-TS
M9#<'1\"G@';-YO:--AZI;2()PP-W!1(ZI+L?=9K>W>*0=P-?W^R[_%!PG@'"
MZ9$$+RRS$X4WRJ5BR,DJ%"^T8+RY]WPF5;0JYH"OF)N\?I%^'M_R"X(W<%IJ
MOJ'3\Q)5W?HCI2_I/;^G5VJJ7O7I>YLGLWB>?P;VJM@5RS(1;S^VO?\8]TXQ
M@;R1E6?K+<B1]R +7VA7?!5RJF7(F=<A)S7.&Y&?+RZ-OK_SKU+3ZIL'KB^/
MB5':=^W*VO;K?2=1^!4MX_>P">4I#"[5K[J9M>*7$0I9^9M:/?%J]3GW%T+D
M7]D*8AUK_Y4"!]2E!N#>*D7',E\$ 0G8+!=&@MHY@)Z=2+5VX@$;S*8U@16;
M9H0"&%AU1C/]625.'R9>&$V1_'H.%* QSZKGQ!K?]OV<4ZFL:B_7=D@#7;<%
MD[K\)WDJ#*+\;PFR_&(-9HJ97W#79 'YK_;\"Q 1@$)S9880I+GK)L?-'!&I
MUJ=3; C/.*#*RXLU&O)@1FJH.01*GFKL@<HM;UX:TO,'0V969GI*@F+V'-(S
M" ?G_&=Z9(!K;A[2TP@G522\9O,P;!/*R'FU$F1VVH+7+ P6-\?Y<JW6'LQ.
M:T 7^*+-N2\\Y['AA%7P4XC"YO>]]MPK_!^J9IWLLW_6E0;:+YP,PS#:&,/,
MXC 3XC-JB(MD;\TK<CA"ZY$H>FZ_:!#X4T^ ;\*/XV$$E+(VML5AL] R#WN9
M%>!"6V@Z:1.6-1S=<C(BC@-I,EBW:(*,U;DL$.ZYT8=^]T;[P^6%F@3M&O:N
M<>OJ.N,6)1LP URX,B?H3PW$)='B'D:,[%-X]C,X$#3I8&D4"?P01'I!?:A%
MZ%V7J-ZID^;HM@ZMG9M7'29&=3-1)B>NS=NS89E'"F/&,1HKF9N(M.?B382;
M)&4@+ D,,FD<$NQ<S'\)H G(BXRDSVQT/L0#@%-':\^T %JTWMCSTJCXD:+)
MOJB*I>?$9&T^P#I;T-,7' P($^+3^1@V]U-U>HVNZ,1\NE+TD?I3+!I08< )
M.%Z(I'-<7@H\495J0$742(0/\ '%5JM9JT8[ ?X0E!*N4[Q/&98?5G,0M';^
M!\]H&HL JLZKNV%,JJ0ZB1?P@ Q(0BA HH[J?ZJ9G_5#-=444['ALLVVC*1U
M34*/K(PM(*#B ")>@(_FMMWKNM;$,L ?61DBX8'SX@2,Z;E7!M2-9=@P9A>!
M,H^6NDS<-%Y+ !B4_6:X:OVN-]U#RA#[C1 ]Z=Z 9R&$0QV;,-H9PTB+J$  
MXHEH<0SZ53P)6(:G];2Y-@X;]L8&ZD$-6AQ&HER;093 \4C%9B1 0 Y (M#H
MN^:[;;U.P?73Q2P;6Q#^!_/Z=.'ITC2YE1I<N[6*FG(=",NMU9(4G+KJ7+VK
M5362J*4^X 3D@%>MYH!V113:$^+4/EV"C8J]]L2FRUA#3(+J:W29K7:S1-66
M.EQ?/_NH I"(VE9)&%5=>P=V;:.O\'YUMWOG6".19!U 04!I!(T-T5D[D+Z'
M7>DUV4AA]UH]YNM]?5D.@K\F,[1%P2ICWLFO(7#3W)BZ#EM.7)M9B:5=SZ5X
M3*I/:>*..X#H+Q8-RZ/T)[T!IQ%!K9&>_;AC #^[6Y>)YDH"L3;:@_1SOQ)3
M3*9G;RJ&Q3;WY9ZY2@JKCW<C#<:UM)/28K2--6+W14"EJK1.1H5E)Q:8RT40
MF?W9)UX]HOF\( 0Q3JJ2].@^[^0MBS$:JJ;(O'5L6.^BV8O_,Q[PLUCX(A <
M/IT"R/<#.=][6>Z@[RP:P"%F^W[? QL93]T+A@D;N -?@@K W?:C._R)B56Q
MZ\-\M@$+VCI9P"EP!>Z&@%D*9. V$(*;)? 4 ?,!/I2\V^T&@L 9" ,F@FAV
MFAD0:F@I>[ZB[EG<B&I(^H.3JG1.JMI9>G+G@4P]Q<9,XVD//(DK\6166?5R
M!/;@?SDP:^#?W&+J\T?MNN/YBI;GI'J>D^H-AZ0Y/)QAC>M]17MX=$["'S&(
M7]$ASDZ+^!AOK9V#*N_GM:UG[?<6%M!=>(.#X0-]^BYT;\C0>[=D=6C'N"X<
MM-A4 1(ZD>.1)0J_1>\7_9]%<S<%I:1,R$=$!C3>#]2' E#YR:P1-SVDVHJ-
M<,O/PQT::[$R3@!.O&DEU<Z)KM\UU_E3H(69P9N0$5O^ED,UV#!QPB&6"O?;
M]EJ$(\YO,V/,S?S2%I!-<4+!?UHL:R/6V#GKI,7,.D_7)$O./'"R ?)*UIR!
MMLLM<T;G/D-G\!V^&3/_I53^QJ=>E]MTA,>\*5:(D]%0D_G]!)\GF7Q&L8"L
M.5<C-S?(HW,FX^<$P%'/T'_8W[UAWA5P_GDKC6JCL;"YK[4 \PKW^HIU/<-E
M*> 3O\S_H&ZX]LQ5;'/;143T*]K,>0!%]P-<6V9B#3E>A?ES'>>S]]O<4/02
M, ;437]V#"810/OO!S*@\WB@M>?0PDN:@3.TSQNY1;[(^KFDTW'_C-+Q]TLO
MB5HX0$^7\@TA:GH]W^8Y'5?L]!NRQY<&<7.I$._[562T :+!I7!<88$A;J;+
M5AH].;HQ1DP%.+:^905\EF_I58>Z(1I!HZA:.XA*0HK>,TP<L4W:6*EIV\NQ
M3);C4=.6QUCH+$^?B_$GNS)1YBU?^=TBK8BEM,72KU_:3)EIP:.S*.PI[+ C
M6D2)M_K4J'24T*W97K\_URD[+30ARR SK1_@$:'K>&=Z!'ZDD/RA2OM0!!GX
M$K_M2'""'>Q!3A(OQH,IT:[EF3.!(Y$8;$6J" QSK1?J]H=:6FS@_GU)-A%+
MVV/&91MJXR3$[=@]$S(3C]E\AD7$^ (B\PS<!>;2"[?FN "&O1"\GQCQC@;*
M&"U4 ;W0O=O'>*8"/&(9@W+C^FB]A1B TF7 #6 N^KT,R(#^+@/.M*0X),Z&
M:(6% *\BQW4M=&/ 4&O*TS?Y:=-[>"]*&NVU.?>40UB3XL2[F$/O5FQ%*!LQ
M(/Q_=F-JX,0K#7YM,/FJA5_O=T&D-V9A'*YE8OZSL%8(#W!0%'&-S=WF8_&*
M306,@01\ KC U)ZY%%C(WY&*G@)T-0I0\CV@R-.!5^WDH?P)8 $AG7J_,3.M
M%LST%Q52M"4,^4OO4$_XRS<2G>LF![?4FULG;3QLO"$*E</@!A25X^<%Q7,#
M-$/3< ESA\OX6SMG<RS7RAMYKJVK(; /Z $O_D3$>#6WX6>-&B"T@7X,W)$ 
M_]H*_9.7]#T@P%M2"RK)'C8D"?!AW6.?IQ3\N%D9KSX.],<Q-*EW,<M5'<Z.
MQ)%A$@>[T@TNP>*RB )UX-[8KKQ5*3#+20ND>C9,AN]-UY_'@/J6%"]]IC>/
MBW"^);R0WW1>,UXNV#3 Y<> E_^BFD$WB7D1J"1N18 OTHJ#X++Y_^#F(3>A
MCI9UFF_":P@!Y"\]D1_TS=O=9_I<O]_CO9!/P)K>E LS5@8NP7RZ' -$4\CK
MUVE*[5= ,K3V!O] HXU(O^3A/0BP]&G@T"=Z]JYS&ST*>/0.4'1+XC8ZZ^'H
M4P"716#@W0I<K^N# *_W%[U%G@Y[W[#R)3VV,_8A_@PD>U?*U)]"LV<NSUXM
M1/M>NF"%?)TL\J[:PR/&=6VB13Z*^/8V^M@8=Q+9;JO]M3]]V1XN;'M0'_.?
MH5?B$)'<5!07@LNTD^&X5PNWM-W?^R@/[Y'\I5_RYZ;)\X&S3_:GO-IG^U?^
M5>M[B\TQS\V@S]LF:F_#A:1?W/\?TW?G!?_@FVF%G]53M:"?V@^_:D=\1/_=
M+SP:J/BH'>.CC:]?[G$EG(^6T4R3W/D\3RSV_)]_@$!YP8K](4_VC[P)D/=,
M'LF/?2G_JE4_Z8_[<U_O.'V#C^W?@&X"N]HF)]9.B4AP";:0=Y@__^Y_4:7O
M]^O/[A?U!#?PXU/:/_Q%!'.Y^K1%H6I]O-XX$335KQ";G^HKU!_P XXM@N[<
M".6X+HLG@TQYH<>8=$K#XF-\@TJ6-<36/T'3?;E5]T_6AF>FMLP/'TS)%@VE
MX>#Q(Y(PI$828I,DK4STS,2'X?T'&AYJ=T1@5,)=U3?IR'GR2'S'Q:AX;PL%
MR.+M'06& ?CX[5Q?'P3H1W5N]8S_)P>4!'$9T-?Z85(B( E(T:5]%YVL]N1!
M@' 918?EV7LP8 G(!;A]%T$*H'*-!('?;Q&-7 00X. GL'E/+^#_%U"E?99>
M"AA0S8")7Y ' _YJ-Z#<MW.-!"D@\$?1W7UB P\X^&6!%P&+5P2.@$<@E5>U
M*8%0H-L72I4=06#"IX*=!($?%P@"O'4^7;Z5POQV\T+ D%#%?PY@XS02I(%^
ME!:H!L)U;\O3E\) ?_O$7?>*@%#EEM*02ZE_!5VCY_[M&?#?&9 X?5"U49SU
M-9E.3$#^UU4Y ?9!+F4?V';972AX"4TPAE9LL/@@?PG=K1733!9>P9H2B0@_
MO@*486)49%J"9O&Z2"*WP74G"NZ"E5 %4^DX/T+,\Y<*52KBT7<#+<P!9\!Y
M=\8(,?*=(:,"\#)E#!Q##,Y(G\YH\W7Y./:1BY D$%DI!7"D AB#QL$9@%$I
M(SN4B88+X@;'8*X$\!1BR)1UI,7P?\ 1S/?=- '(X!9 &+A3O\689HNY6^:,
M*10,BCDPWVL3EW$TS .^A@*4/B$0JY6C%0%/@!&0CSV#C(85"/8M?%).H$ ,
MWEM:'F>")(P!F@D*, \B@R:&)'(,)H.WU03G%GB$D@@]> 80*]/5=I 66 8G
M@O?S%+0!>< 7P&J!/B&A'* 2AF4&X0)V?^52G%OE!A=</S%@7S4CU42P7!Z@
M6!!_3L+5<VLA?S0,[S1&@(*\("5$"I)-I<7D,^\@%/6.;*00ZCO\CK\CDE2%
MF% %0Q/:A.<@3GB:I(2=1$@"[41PRR!QT SB!M\@6W@<N(7W'3QHR'R$9X ]
MR,H-'>-.+?,4,$OU&(%#EL$;%\/DH[V@"%,&BR8R7"*K"W'0'?@6@N%38&90
M1K&,8O$?+#R[$6,P%!*$,@Z$$ 38.7C.6BC2Q%]W(<#C&$(<'<[!5EGT?4TA
MO&&C?0=62+\3,;2&RP]?R*HA@'C,1M@1F@"Z(4$V#[:%,$*T8Q)>.<'AO)5K
MK7B>#_WS#_*%ZILCQ1>Z;W7956<$D878H1*TWN@5'LY(P-M=$'T./T?E6#G9
M6I;C_F W8HZ7XQZ=AV'.F!/Z9#IA%7=8=6D?3M(( A[Z-$) =>%M$!-+@F2E
M^&Q*>\:,TEB !I6A[-,6!"IPDP+4_N0W\T)-M(T(/FF! +3'; <$HFMH)\A4
MC0& I2#B-U9.*I;^O &#&]PQV$DB%>+8T&0 .<N-U>/C_#D91X<H T4V8TP*
M4"%NAV7':G?2)  UFY9@$+R"-*(1D@"4!//._($W'0<]HE-B)!Z)?(=NEQTN
MB=\,7%@'CH<QS8O( *T_7XZ6(QZQ.O"ADP@WX$?6C96(\ZF'[8]D$PV>,4/1
MAY@7^C27S6D#8O@QJHVS82F =W(AAX4=^0;D'9$SU3AXO PC\Q?Z-'",IQ"2
MS &WQ_,'*/(:.DV,,<[DAW(,B ##J3ON#(O8XDB(A]@X8V*I/AX)4N,;Y75O
M3)U4#3HS:>(TQ"::""K6IQ7D88D R#6"=UT:M8QY*-EP.0(('>/9B#E[A\ZE
MT9@C&EQL4]NT6L95WD3>C&2QC<6W ')8"11BX\Q@&H$;8C0&V %/'JGHZE _
MGP5_X2>""CI7@8%O$3LW8:VAFM@!,J%H5R:^AV;.+>4KAHK!8J;(M@%(BPVC
M$2JVBG!B52/6$#G46EHS!]0S=4"5@US$%G:;KE/<?!#-4?T1[^P\<@!B0 :H
M&^P%^X/?L(O;QHJX"K5$XTPK^%J\@B]4!?0=H!O\HK_(X*R"D19=4M8H-1!-
MSD %? %,5<8C!;@.+L^\ P#RB?1,LK@A6HEUTO<U!]@!1$ZV9C'2BVK.K/C:
M[ %OS4_BFZ0?!U6_"&^PB\_9K>A>J(PLXQBCV_"*+(4"""X:BGC-B>ACJ8CX
MAJ-(J B,N]'.%#'&10RB8T?/0(HF(]3('DXVC)1IXRDF9IP-NNC9E&^;8M>(
MV: V+89JP]K(C+6B3^,S'CN, 8JX*^I:J9%E$ -MB] /?$@WP@W?XB #=7%8
M%E_I(P1-A4SB$[3<;4-*&7,CI.DW%<=H>.?D.1<#0Q66*(F%XQ)4P8Q=;5N 
M,:[Y(N[4%M/%:$UN0,94EBU-2D/!I#3M +[(Q#31W6A,#R*1.OH<'MVYL;7M
M  5?/5*6J2NLS(A@$KV.TU4^= *X,1;?:E/&#$%48>7(!!V.W^$C<3$X@E/&
M%1:$R&DQ'^5H/#9!%4RU=JWM!M3(+$2WJ3=0#AQSMP6*,=^D%B:Y,4J#1#2I
M:8K(6_8(X=5ADL+Y"#-1;Z9C/*4PF8]IDF^03XU>VQC"UA@PC(:@PR@"O7"]
M <-6L=%AC%D]PSL>>JQCO,<[QHY:FQ38!#(/!N06H#HBD'Z314=S29"P(T5G
M!CB0A9X8)X51(QCDZG@"! $69"H60C*01H #>9_]=(5+M-:G(')9A0WPK-UM
M)9%W$D+..[YC. =ZG5O%VRK#)59A$D\2T%CD:7T*]$BG84 F#"?6NKE2Y80W
MDX+UC5^40AA%M51 87&C65F/$=A)P_N]="C !CCO.&D<FTE7-1%-_,7=ULU,
M.HY@ ">M'7$*@ 46PHUP)9P5%XU@<6C<%K#%F68V7!T9QC%A/E@=^<-E9W4D
M&[=:N7%+0PZH0R8 )!TN)D9F83(='H?-]2E5'0+5QV%H&IH@YZ$9<DR4(I?(
M,7) V2.GR45RO]8S1@#]:0I 2^$"# Q60&*P9MP52455H1&8!%D%2 !+=A6S
M)$8@5GP$+8%9@5;8 &<%2X 1U  TP P 5["2Q&0Q:4P>D\@D7A'[\!5!Q33A
M5T OOX-@H1@4%K%>9*%8W%='!K0Q6<08_97DT6XX6U 9:0&>H!:J1>.B^YR"
MT<R5,=>L:-U!B^9;B!?"A9YA7 @<@(9S 5U<"H!&=?$DF#*/1L+@74P8\"1Y
M85Z4&Y:&>T%/;COTA7V14.87  84XE\ &!W8J3%M0%/."X1PF$D8V06%H9]X
M/AG&E--A'%WZCHA!8I@8_I%81"#9*3,&GN*F1 89UJVP8[Q%Z46/$V18DT1&
MLV'@*!D^X'OS9,PB<-/J=&4X%UH&A,!ED ]7P:0B9DPA9H9G@&;P!8?#FM%F
M^)1PAIS!2^@R=X:=D&<@@ID&L9!<#!I$)5<I-;P _:0_B6@0E5X&F/$"5"IS
MP*425HX7DL9YD5ZL%^U%5KEIL"V>ALU6PZ4Y3IA$*:F8E6CEI=)J;!2OAB F
M:] :ML:GD6OL&K[&KQ%LP!@%6P)0[@@^QA1-.0C=E!505M;HP)3P1L$(%Y0L
M H<.1VZ\E0$3&M#)Z$O?Y*M3]:0%^<ET9&\H%L=,O_%OH"@ $\%A<-0\"H?W
MP7!\4 ]'Q/%;4!RZSQ#@-&X<V.22 8TP*B6'SL%S4"@^!^:SAKP<^M+,85@Q
M*LHE7%!<<CT]Q\\QUP@=OT5*:7G,(JVEH-)TA!%0A]1!=5@=%]/6D?05)ZZ+
MV/$4D!WZ!]IAA$ E;P=N$'?,'<V&R.*,B U[!]]A@W 6_XC:L3\0'IVAE'$"
M*1Z,A^.1 $ >[D>&0'Y4'ON"8A&;/ 8C N?A>=P?B E@,A( *"T*SP)R$"CM
MR1H >UP8LD>OH6%P&.!C[K%[]!Z/AV 9HQ ZQ<?QD7Q@F,T'S\)A9EN^1_X!
M<EP?V(>"PWW0F(_'*7(2X)B."%5 O:0?T\>!V7Z4'4!FX"%_T!\=)OX1>.P?
M+<8O4HD((,7(!J*#)"#Q%P."GT @$D@(4H%<($W)?KD&X" <");Y@7@Z%,@(
M H64%B9(3B2$L!0LR A8 [P@,<@,@IY4)(9;F6EX? ?PR0^B2?"8J!SGPB*0
M(U!)]")HDCA/2*/3M5 AMR$6<I: '%M(8N"%9"ANR!@BG9PAK@R%LF-4FG (
MYX-<8!)&(E22:4(+^$<AXF-*(P$)EF(<("(V9H6"B1@L9,H-T93!,J"(*'(7
M:"*M)J%IFM2:C<\HDHN<FGV'*L*(])< R472]^R4FD2.88O@(J5(KMEW5"._
M2# RC- !Q4B.Y2LI(_#7D'63K8%&XO=DNV$C<1-R)5^)(X85DG@1/"KHB&>X
MCNA!PU(\LD[1([D(KK*<Z"/\")(@G8 < 4FXF>/\0(B%.89"R5<.B=0"S4PD
M)$=ZHG8$))+'AY$A?#KA6&  DH@D'Q])8I*D!:X<2V*:O"042DR2UKUK8L-L
M0GCP&]XE3^*3_%?@Y7EYE(0=8X=><B0V)L7)=%.57"4JYU9BFK@P8,EK8IC$
M)F+#HUEVC!YJ2=C"GFB;<8EP09K(G%T,7F*99!Y\28PP=)8F1>=@8C"X.(<)
M9Z*9+)V!R<4Y?MB7DLF6 "V(); )TEEA;B:=R78 !X FH@G5"7] ):.0\NB:
M<)TWI]?96(I+(&<AA)LX6/]5R?";7#W"B<D)=APGB,B&87CD(\U)%_"<1"> 
M!W5"CHT(U\GP(@UM)]W)M1F>C"<YIWGB8XJ9Q";(L9[LF>K'>Y*GQ2==#T.5
M)-0GB(&?X-WH)S9F?_*?+!\9YH 2?1@H$2*-\HW)&Z3GV-)82"@G!H7RI5PH
MRX6&PJ&4'4/ EA:B9)PCBH=0HIPH\\)(H*+ F +*B\)ALIX64(*2..(HQR#-
MQJ.L3[ "D()9\#A$"K.@:L*:WF$@A*(\*>E%E$(L>"EPBI5"B!@B>\@<8*9T
M*2N)]DFG)"E\1YG"I: I=(XVY::,".6GG')^(BECA-)0!(0!*N4L0LYY=LU&
M=REWUCB&2EJ J"@J&0O4<F@$&F2E4=E78BH-:+@2''@J-8>O K6,*AFHQ"*J
MH"K["K82J[P!6LO"<JM<&;H*M]*!FBK!RK "KQPK\@JS(J?4*\2*M$*M$"LA
M:+^BK>PJ8:6WLH(N+(>9NV*N]!KHBKK"KEAGY<H+BJPH*S*HLX(CV"LVJ+V2
M@V8KS + TG'^H% +P<)](BPCP<MB@1(L#@O$4H%.+$4H$7JQP !C:$FPL8@ 
M'<O'L@79EP'FAA98N"XH2_NULD0B 086:H$6.^>&S=)QI 66P\[R?(@ /@LB
M&;0D>/O(@D?O)2UG%-,B=Z2A40M$0K4T+#$"UK(&E*!0"]<RA7PMO4NZT&&8
M+6B+VI*[P RHB]P"F7 ))(;=HMCU*7M+WW*?S"Z"R^_ U.T8#(-DU1;<0%O0
M_)?T/"Z$#U,WN4 GM 7ME+F +-(D86$OY IX .B"(X8$ 0'ID568+J3H[I*Z
MK"Z;930):65!LHNI\#",$>Z++A>_S"_UR_W"&.@O_(O_$A\$,$?,XH0"&#!(
M1 *SP,@ #8PF*8_Z$1-,!7/!L$,>@ZSW1GTS^<]!Q,'H$S1GU+0=. L:D1&#
MQ" 0.<SOP,0X,02&E;.0'C&'RQ.SQ* !/4P3 Y$F,5#,Y43/63'V 18S+G2/
M>P9@!2/&%A#>,G@R;HTEZ9&D+/:&8=#9N":F-H%,G!C*&#+/#D@D]%% KPPF
M\Q.)EK1, 40+<3LV:?YS$8R::XJYM)..EA^G.SB3YC+MDB\#S#!;3N-<$^"8
M,+4>C3;-1)/5S+_H;" 9C$&NU22&,^Y-OHC.=(GK3$S3**Y"<\"&13)B=*KB
MQ3@-^3-<C4"C*1DT"(U"HU8Y-+D!1"/14#06S=K(W5A>;F.U:.6<-/&52M--
MB$I(PDOSELHT?I1O<],,*>J-3Q,N@C5635$S!QPU#UENX 0P-4[-%P#52#4<
M%F4JUF U?R>"8+L$-$Z 5Q.: C56#;NH=IPU[N):,X.X-2E,7 ,OS#4\X_)S
M*.XU'2+3&%H*-F5-8?,HT3.XC2GDQ9"EJR*'9=F4-B[I&H""<39C(_P1VI 8
MHTVGF-G I*M-Z40K?F=PP_'U\56+Q>G0N#<F (XI>I/3**=7W3ASW"">%8)R
M\RC2*":"6BHL2C?QR:S1EFXYEA3;N'.]C>*-DN']E*? C=\X!,E0[TWC)M\P
M!O2-,0<7W#?66%FSWX">&,:QQ6L1.",'98G@;$ F0P+R#Z4*@U?;!5SM<L+5
MA://+#X;SMXCXWPX6&:(<P>,.*8%.7GB3!;]U<YAX_!HA@F,<X5X.#2.C-J+
MO!8XCC(B4K4%/ YCZ./$C<E483'D!*<SR)%S;*D\3%63LW.Y6T=5E1,E8CG(
M*7K8Y9RDJV)Z^"$N;S$3"SGNV EPCHXU7Z$!=([C6!I*1"D?@ CH"#J$SME3
M[20&B0Z<2N@T.G.-1*3\H V_X$BC+"I+B0RC4S8^.]K/L?/G\)/W5YY:_] Q
MF<ZV8_?XJ=8/MQ.H<COEC?T7ZW%\;Q2QTW,A.S+#+P:HWE+]WILZROP'K!31
MY*AZ.U:5;T7N&!L?@J,6*=P*[([ $QAL'%HAO2,9WCL>Y$,%8H2%V0; 0_-<
M,H@+BK#X''AP06ZF27"&AD?#,[O997:"S&--A2,7P<43"FD\B!OB\_%X54F 
MR",$D#Q.@,F#\D@!3"K+X_+\/!%/$JEVT#Q?A\WC+. \\X+.TR_U/&4'N'J7
M+0U"#YJJ(>P&,)R#I(R4/8-J=L'TG!M/#^5#,L %4\_.<5H")UA/A>"H<3T%
MR==C'+2#DP6^N@K=/6</<I'V]";[1-M3^, ]B(^@0O?TJWD/AX-L&3WUZFGB
MCE6LA$]H@;$F/G->U=<3U:HNT1PTRS0WED_&$%W*B&A#%-7Y+ G.X8<X^K  
M"*&%EOHXC8R*5-J&F:I@JFH"^.@F#^/+JB^E@I</?-'[! :F4L.XV A?FX50
M(Z16H_&#ZW*GXJFJ#C"HLTH_J)!']J>V2X&J+203FDJET"G$+.ZI3V.5N#5V
M6@:0W9BS<HL@XHRT_T@@L"$ -*2Z 2CB8R25/06B'9A( X5S$-#I,P'M0M(&
M@H(!D9(I)F?! >4!'M "F/\<!'6@AH9XT L%"IG1$K5 D.D+)-K=IPU0^D>6
MD52G#[Z6464+_694.$;4=M-C51@%%2?CE174;&"C3B&W88TV&U_0B! &+0P>
M225E!G4<1TX:-&"Q0?//&T2-M5!RD.2CM":EPTD>M ?U.'W0'Y0Q ".IVZ+4
M;!Q<MTF1A@B!DS6G5B;A[!.0$&(A"4F/K2MVIPEQ0DR )V07B4+(:VQG"IE,
M:FJGQ*?2 <R2]N@,VD*DZ^E# 25WY]_E&)(J-_*KFLHL)4.5S3)T,#9#(X+K
M."=)0U:.1G0-^:/[R^WT#3T%X="'E#B:0P/)W%6T&$39T/[2R85&3\$]E,(<
M:HE:/_0/U6D"T<NF$>&CVA IE[@]1+49"JNPGFU+6D&T_*Q)JU4JD_^\GB;1
ME9$2^0U$&F3T$CE-RUE^$=WA1$73)-AP'0?P!LTS^6Q%P%$\(Y@914B-T+<4
MF45AP%.$&R1?J5A5A%_$"%G1;V3(Q#.^&16+%,%G3=%91+WN"6J1&/5^M$6W
M F9)=$TZ=1$H)/)HA&Z! 4:6)608E6"T@&4DL!5BQ!<UL8;'ZRG$'DF2D287
M0<U($]1FY 1T1O!0LS8:&6Y%P$+DR14!D99J!-6=,JZ1%2MWS4:Z*#&'&WT'
M0Q9OY&(T>%%L2\9Z'4>=K&$6(8JESQ$O(AT%0M01\_HH[1G9T:K4'05VEIUX
MY&&=1Z6K>F0IL$>WA8L '[T \E&@(L\X>/$,_U2ON5WCV$+E=F1C!9+:5<EI
M2:1,8X 1.4CC&H8T([V>%]),1BUH2"$IA[0D81E"BW$@(G$8]8WF82)M'"E2
M2R07M$AOS(OTM3T)C"R5=2--13#(S289\$BSH!L4))U:QU9D).$I245LD_0D
MD7E24F:QRU5)N]&59'!D28X=EY3']7,Q0ICD0JHD)].DIB9%L?7=MO8FY;*"
M'1E )X58>QV)96)92I.=H%30Y4J'$J^TV'UVQIE>%RE!=GV=I04H"4KS:VE'
MP#Y+EE^TI&TLGA5"M33;D;3;42SD*J6T?!*,]<'82F>:@\79]4HTK6/'U$9V
M.NT70!C-K_7K3PLW0$N^$JE4U+:OIU*1I/%-JA17Q_<M]5QP9V! +BD01BE0
M@0:,=403R42J2GM#U=A$HCE:^(:^U L)//Z2X0$P33X#TUP4/QYM"A/#9#]"
M37&;,W<Q94PN4\=$QWQ,P-C(1+:R2V'KU@3'25&\&UXI?9VUVQ(EYO%I5CR3
MSR2C ;9"4[J!NQU-ARW3Y#0MMDA$[.:?74UD79A$2UUJ=RW/%Z*=76538K-!
M);$=:C@&S>Y&Y5C<Q) <!"D;-74WL6-ZT\CJ-PU..=IS!'@Y!K^M(;@XM6G>
MDS0G/J%DSN$\=\W14MY9-Y<5?'/0COQD?,U+E<T4RSIEILYL[*3(*FL3@@56
M0#D!$MD.69'ACXADZ44\33NJ;$?F>H5DJYPM55)=3\_1HA;)=4^.DW;KCW6W
M&NEW2R*D3R[9[Q63Y7/#EWEKD]E/G,D49\;N9.VM__3>%FX2K $E>P6+.XT 
MIIPZ4**<1A/B!EQ>5 J3L$T9U6T'Q4Y6@N48"=4\F% 9['';(T6S+!1L!PMZ
M:6,3#048V%"/ @YU1%$^/)2O0!E)(#+$E#%$G1B0PI%;#A:DJ\P\JL@1D.]6
M%57!@5%<U*:6PH@ M02_!6Z54>-6@P;KA;9J[2W6S+@7UN;JID3J45X9R'76
M(4TC#<D5O)5BRQ^QQG(E;>U;*Z9 IH\WE_3V266$$6<51DH!7?1;]C;S31=\
M+HVG_9QO@>[8IL#AM85692$0X!LNPDJY3QQ3RZ8R!2F02,X410D7H$J5[K**
M31UEVY2*RJ(*5(W.LP5D36:=PT35LSEFMQ7PAK0!NE_9TG8_@E=FU:HF2054
MX%0.Z$49=CN/2Y(QQ'D DI-!%[ISWYIC%E%!;1952+0<95, T4;5:)P;'A62
MXT#\J (!2546E18GE7TQ DE#*Q6S2[8-J P6ACAM_%C1U'6"X#I.#U065E8]
M7FH5$<#:2(NU8AQ5+1Y5E-5?E4BNN<?.9_4D_B8FPFAU;IQ675E9Y^R&97@L
M;+7:\5^%T=,U?<6!;-E=\UOI<AR"<*4?3DNY8MGEFT):RQ5!@&@-$^5"AW K
M2%?SCE<B'C%N\UJUL5TE($":0R7!A5IR3'DE!7QR\A.IA<D2:Z?/OVOL%*86
M0UI07W$<^-4VHU\QN_Q5K^48A)(!%G0R8 T'Q-:!)3+X:0D<+M=@Z2:SYI[Q
M)RE:A H>0EOH$RWE&2"?=EBZ;%GVV/%U*RV*%7 )-WG559O3GEB7UHRU)PQ/
MAR0U96U.&3R6C[5M!5E9IC,2L#U@45::=?/NO'7O!8.2]"EGEBDD^-)#(AD!
MJT^DDM/DB !GO3S,KL_K7BR2=IQ2YX79=)!DX7NPR1^(7:(%5"U:VX>ME5S5
M'38NBW73\G7&4MS[R/*RY1&GY7DI4JD8S4M>Z;RFEGJ%:AUG;V,T 6M%.+,6
MHV7Z/EI&QG)XG/%:TH:OQ9L 6_I)KT!@'00&5H5@;$%J,!#]LVSE/\W6NKOW
MNKO3UN>%H%E;R,LQDFVQN]*6&&:8C;DN3R$6G#AH$,(;5N5:N9MD,B?!;83P
MUI:[;W6YP^Z7>VV(N>\'&L;BJK]L6,W77MEH"A?#]=L]7(/%; ?:ZJ,6E^E6
MA84>;BX>M40JO/)66 9/E5R$%)[+M.FYBU2C&[WYN9>4\Y9T.;H$QO3&\\9N
M/Y<IE>@278MN= B]#6/%&,-[[FI9E&X(!*<Y8Z]G-);KQAL+7;+KI%B*99<Z
M=K!U8XG-Z]EV 7/%[2<[-]5=0O!3L-SF32*KAO;<SF/1K3Q&CP&W]Q@3'$-]
M6@HN=VO-Z5X#618EWL)/^IR%VS;Z3SD9%<?A.E\3;^@'0>JW&=F:V]^R3QZ9
M" "24<!>5UJ6W?)CTYP\U^""P7/P2S8&D[?$5P]PWF*X3T$9N]ZNP3W9_T7Q
M_E]#F?6UO6!?2)DHN74Q91 6^&5X6);DEZ=E^1*BIY7"YGYYKT-6P@M[M598
M@UNV?[%U$:\CW :S9?-O'JO6[5]QV1^;[S9UB"\$QI?!#118%"?"J;>$V?/R
M@:7!&RX-%A&58&RL5V3*!FQ/6+/[$=V15U07QX-E4368(Z:-%9(KF Q61YIQ
M5]0/-X1EPY"4&@=)"9)*V%B@@T%A#D035O=^PIAO4:?Y"EJ;[Z!5H!UC?)S^
M6V^98?VO!)&&E;GK;T.GU>T<<!C\*Z%AN1-<_6O6Z6$JYLB P?55^2\9IJ#Q
MPP$P(C8 +V(0;!OB(CQB9RX#7+H5NKA8$!H!=V)X<,@5BM6YHU@&C 'ON@Z=
M!\R*Q5Q_[OJVBLUB@^X)W',=NBHP]L8"AZI,)*[;OLU2 YP,/.GR?%07W)"Q
MZ3?/)X5"1TYCP^U_-'8!P=?PV$0$6[,DT1'\=L5L_J8&B]RF8^[<.@8%ZUT?
MPA1<PEK!'P,67,YBQ<J8 ]4%^\&-%^P%>7ES,EF%2WE=N,@7,;P([T]L< #&
M0^*W^9GIQ=]"N*ML'7P'-[[_5TG&!V^W:#$]MWL-1WWQ6CS>ML4TF2$,%\?%
M7E$)1Q<WPG_5(RR4 5.2,&-("0<?E!PTA@E_7[O!4V:D*:6\V2=LE8G"EF6V
MR96Y;O87JJ8*SU:LL/]5&;_"93$!)@L_O+7P6981(JNXE0.6"W=PO+!?YD9*
M<22<3D9J#'\),6*6ELQG(]V,IU1-9\+9^ 'KIF>P6=O&@IUFG-GXX9EQE-<9
M=&8=1\/8<0BDFA5R4V9W3#;$9M,P;?;EV693"FZF%.IFYO'8H B+1=!Q9)8A
M+'0UK6@6GO%PCUDBUIS%QZ-9-]P?4V<O@G7&' ?(X7 @64?R&D(8=>P,,S)9
MW%D%#9]571Q>!IVM9PNR>P:?O0BX(V7F.5AQZO IQPX/=8QD2L>%/9+R<*WZ
MU@TW^M9##  G@@\:(B<0.U$4VH]DH5&2@5PTF3P6<E$4B.8#;F,CVKUDHFDD
M\$+_R$[FENKETC 4[W@S6C13HRUB)&QT6Q@8N (DGR:E80U+\FEK6P0N2%I.
MI*2IL/$&&"D(16E 6@) I2&M?\J5-N>Q1%H:CR1-= Z06K$8IG4.^B#D<^TI
M1:M3FO:]*DW8+:"6)1N1R%\CA$$X&2:;E4SU)F(KVR"R%!EJ.!H_-"7'&XT:
MNN,T4+]/VYET8O0 'O"E=N9H:@TQ$.BIN7+4;V/F3\VZ7!.J5BF? :M:,_>K
M(7XM(#[F[_)JVYJM]JOA:DV@VR8K4W3!FK!!G_60 QBQB!$.;A]NG?3!)F[>
MFDM$!YQLU!IJ<CU>.;5:M_:\-+;_W+A6MY5K?%HKI[>U*>T:J(ST0@@L[[F6
MB$5N1(J^IH *A9<;P+9?D6V 8&-9Z29LL]9W4"5SM)$HQ/8?BLE0&I]FL3&[
M&-OB."\$;5:0J >R;2DBF\@T+Y1L'\+)EI9>; >;H#:(M&RT"$$4S,EL( K-
M-EWYLSE;G[S#C<JE&B1UJD$^]NS9-K0-OD6;*':TS5,Z,=>DZS9M:=LB!;5U
M 5(;H5>UK<Q9V]:F<YEM'%MF)+8E<,4:S2P(\;QW6WPS+I9FVQK#ZQRKCM$R
MW6:W;;3>,K%+] TGVK+3)N4$;GP6LA8L_P<N+#V$JG7+CMO88.Z9KN*RQMJO
MA1;FLKG+E@6%'(/!)+SE;AG?&K7QI;65JIIK[*!N@M!'/ &#MW-N[$;QT&XL
M4?BVVAZ2N]O&1$GY;CVDK4M(O;8;,*^\YY;,'S!+' *W7.P;"9QS$;H<,<![
M$MC$J]3VYAAD4=_;I5S'Y6:U+<LZ-D"Z+Y<+W#A';T(SQ2N_S<07IM"EZ"9U
M^9MB@V?U;S3?_\9<%' #W.P<@?7$")Q5]Q/?5<5C^5H)17!U& 5W$#,+%QS^
M>WRE<G('%#<<_\(:[B+<@;D7*1SNE*VR<"Y<O2K#U96YQC1,2^V1.]Q'Q U#
M4G]D$:8@=V==DQ$W/)*OOG,OB-[BPKW!/_?$872^,!RID\F1L+)C1DM-R!^1
M-*P-;\]"V#F<G/F1=:0X_!&1P_47(>DJXV<C\K06OF6^)W(\K#)1%I)D"N/'
MF4Z5I(Y\2;X^A]R,K&YQDG>Q)XD9*E2AI"'+N$9J*>ZR%LE>LJ!<)D<915"C
M7"7;K)ER9=9O?#M_8JW<%=:Q]@:QW!TRR\V+=( MQ^SB<A]JQAMO;#"D15+\
M,.NXHJPQ!^$D9LPN3G?*J,H_R6-[]@S&DU,UIY*!P=F<$ZT8D\'@W"F7PHQS
M>TJ? LRA<TMT6K+.B0Q_GJ%#17O!5[1 ID7#9&PQA=OMG'(8[;SPSSU9 ET$
M1M!A5&3507=#I(+X,?O;*V-T$)U$1T&F?8MS1M<L270,)$@'0X]T^NV=12)G
MOC\?2^?2L5)(72.YU!5<3ET\[.ELLCH=3U?W/L*0]/DE22O0)QWK?-3%="9R
M[$S3<;Y/71L0Z]31#_0IMR(3;&[85@<A='4]UU?7B(EU.'%(/.>^QF79 N;6
ML3DME2)84E$AC=:\8-?A@9CBV4MB%91_764W(KYMH%*Z=F@14U/M3"LM-7;!
MTNH[34MV.ZVFY&&%1YB=-@V9<-,RK6<G+>5!RZS<.MH)0W*,:6?Q ;)Z[%O6
MVM6,:*MLYZ"QKNGS\6C"6(:)HV\G) =W%Q-QY__$ALB=7WL;#M0P47/7_D%W
M#^*:+ FJ390@8* +!M1)D"_(W8$*WIT5HMXI>F@ >1<QF'=:XFO0^,%X[5TW
MZ Q*@/U?2(LRY84)@WU$Z?5W_YW10N\)> 2>@6?PP 6(Q-"2B,(%#)X8BQL\
M> '@&S, VBD.E 8H/R6 ?%&'%P(U@+S?B'=FE7@3()^%XEF 0F&+EP&NU"2U
MC$?Y48,W1)T7R?5X:70",/J]>Z9?DH?I,7E5WEL=!;Y]5AX3&/LI?PC?F1:*
MA'F;Q9CW%QP,$@C%@.8E'6J>V#!6?WEP7NTDYWVO9O7FI^"$)C@K;M#GW2*?
M7Z1V^+G,AA[C)U([?I!?5"WYX9>+%)1'Z:70HO5.O>FUN,.,IZ=/4'WR*JFG
M-9MZ A*J%WVN>GA!6.?J7009,:7: %>E3O+(MU/O>D]"KY?R 7M5D[ 7[*D%
MQ=ZQ=R*TP)[S&W?SU3(P']I, P/%99K!U^4Q?U"?[2?U]=7<7J^J4^MZ8$R&
M$$4=UJ>/ IOY\7[J'L&U5I=^):2\-UHOSF-?OI<1&K[]WE[][P5\:#/EVSG@
MU4+@$&A9R]6('\0G\8'5%!^C%_F%;FHS6DNZ>7R %2X6\GG7))]B8?(%URC?
MK[?R'4S'M<O'TBG7,E\PK</)SG0B= WMY;9W%=T7_ 5](="US*Z!.][>;\WW
M+=3,U+*[\,U^0E_4M\3."ZPU\H=($(+2'U89175] UR;%_9UU4'>ZU?VG7YP
M'Q*X]@EZ;E]<O>3-@+%?+71B_X[LW]+\8B]]%0+!1V,3?KNMX0=@8]8&TX"]
M6;/4G;5B=/'=7^0U6(NB+$4!@V.MYT76A1<I[6EZ"&XU6WT"HGXLX.FW^LW5
MKA^19U<7;_PU\Y?"V-BXWY]Y_-5I4V3-BO!-V1@54WC.*%15M?S+Y75]PIGS
M1UUA?3WVUL?(G3[7'VZ0_>W4/Q.*P/UY?Z</^$<>=!+CWVY0_O&O' SZ=]IY
MUHU@^S?]U8&ZWT6-;(:R&#1HB_^E+[&#7GA4IX IJ0 XX<48336!?0!F%694
M5"VYGCY4-50X%SV!^Q*]EE7K&ENU5KWB==488+0]4A?8*E<'^/]]@$(A1J<$
MVH"FGQ-H!): >7:M:FZ#@24@$WC1?8$JH-V' Y(:.^!%T .Z@7S@ P1:AX!/
MX HH!J[;YX@,"&:3@5>@&3@%XM9I(*/M!K:!;J 72'"?&THVP!U0S=5G(,B1
M;W.;]G9_/1+ @9WDZ4,'%E/&GZV]9T3:;,X>^/]IW!GW']A24=I?%"%X!XK<
MAZ"FO?PL@@<VWO>6S=J&-LR=4;N#<A8FJ F&69V@Q'$=<M38W548I@)8J&#%
M 3=1C*.+L3!_$%-$2D$@"T9?M: 8?0YNU$3W$N=1-S]Z*G$@#'IDQ&!..!(J
M@RIIG/C>08-.8L*P&U"#UL\UB&]D@Y((EDG#O'?@(#(X#HX(Y:!I6"&D@VYA
MF=L.!D'X73R8$ZJ$?B$^J#34R<9;/Z@6F@ !(1(Q$-9G!F'/6KJ>@PMA0_@0
M\C(2H4Q$$6(:%N&>(;@5;Q-<1P@=FH9C=TFX$9Z$HS>U,.^XA*%%3!B6G84W
MX7.8$B*#/*'DA@+XA,<TZ 4""@AQV;+]12&%./1[W/\L?5M03XEH5S!2X2>8
M=5^%[$56*._(JO:.WCWGW:HB@UBH8&3=9F%-&'M[W:9A$T <OH5P##/H4M.%
MPV%J*&T'WGOA[-T7WH/DH\4;&LH8YV!A*,@J1HAA6J 86JW[Q&H(&=HT]@YE
MZ!I>A@NS\+T9_C^=(0=S$)8:!:*9FN<HA'RW:MA.\A:M(81 !>2M>><B1AMN
M*,J=MJLTZ(90- "H$=IAOV%R.'A_W\;AZ8T<JM_/,;.P'*K5S:%:.'JK8M-A
M6#8X2AR]<];=P&V'1>*$H)2%AU$J>4BESD!>8GJ(I5JIRF)\2",F1.JL?=@D
MA(>((HC!+BR*_F'*2@$)B&Q B8@UA*F9Q:-UDE:-#N)-I#CRK4OCL5H@7HC4
M2^\JN.Y&+F(1#DE\)[&0%:XD$ZFW"')E,!8SBZEB [K2K+5,#GX1V(AP0XX(
MPQD0;($>/GG\B-.5D'A<">+F9B(NC:#/-G@#Y[\.O$,->0BZ4HGK899:A*?4
M/^1(*AX-14,X29IVXXWV3Z9S)N)%S*F:Z)QBIVZBJRB3;DG%9XC],I(Q'!:>
M>!PQR%--G_@I (JY!C\28A:*Q4U>L_'RAXQB<N,T'BAP>*2(UTR*3F,V5B3Q
MB9JB]6.=HHU_#*A8B],SH^*':"HRMYA&)CXEBCEB(_=M L2*,>-?NI %IFFA
M") K<AASXTW&-QJ-4TVXR#+YRO^!+8(L@N*(JOI#77ED_ B-=8M'BPRQ+=;[
M7HO9HCQ-C]\_WB([#BRF2N*BA$,N9C]333>N+@XU[")LNB[ B_)BC.@;V(NG
M3SESB^J+$..ADVT C%LXP4@54T"33L)XZ2Z,4/?:U+MVY&^J5NJ05HP1>5X*
M!6B,'"/5(32 C-/5R#B?AH!G^-:8,KH806-LX3(2.;*B.%XS.@$W(P\R-;8A
M=8V'O&J5XT CD2.>6LA]XT'>BRN-$^)?TS2N0BWB%BXU>N1$5VXJ)UZ-Q7C6
MZ+:NBF:C*?Z<F@ .>:'C.92-S_A+FC:"BMKIS*B./^7@#=P(AM\BZ;C]I"T6
MX>-I5<[> (ZHG>!(/"[?$/6.G+G.JS%:*JB 6SB$<F+ B$^/C[A"CIEICO81
MYY@7?H[^A^A( ;:V!R1%YZJ%P LD13<[UHY\29V$.^872!WOB$,&?:)K5"T\
MSN!#=R../!;4:0'SF#$XCVXF]"@13>;I<_6H+&-KF#EN-!31U-[C1EMBBGKB
MHV_0?M./99DJUD1R,>SCB> ^>K8J5VOK&P0QS'G]6#MZJ0>;;O!TA]R)D_]X
M$ "0>8FY,4#*O\X,(@E"3I"B>7M=FLN.'.2N!D&^YSX'!1D&R.<GI 99G^,[
M=!9^+D*2D ID?WYNI)"L#13&0JY<&VTM@P#*D(0+#;D"V)"JXVO^.XIAH=]K
M_4/B8D'D$(F> \J(=A(I <.YC.X9^42RXU$DY9UH#X&Y5%YQ10[G38L6B?QQ
MD5ZDQ!9&DLADI$9[+#\)9^1<E$::D>?S\BP_J\'T,QUY/]>1^C,D]<5]1-SS
M&_<_ V$!]/A,Q)7/;QP"'4G/<:@T49?4-=!Z7(%6#[,R$S0@5S!;T-<L)IEN
M:=!.5#*IIJ_I;'J;[J:_Z7!ZG"ZGS^ET>IUNI]_I<'I.R]*6T]:T27O9_;3$
M[CJ=V'5VB]([#=K%XO(T %M/S[[W-#$-Q[EVK$P_;0K-=D10;6Z;)^:X^0WF
M!GT'PIU"37PWU,RK<@=1[QBZ>8ARQ(K%\A\(]28WXD?0UBV/O8L:H$FMCFQ.
M9#?<H '.A?$,3#W?F3#VW3M84^-&-S6ZXM\!>*9U3_WE :O/D%!=M!354"QN
MA%0;R\*VDL14%X#&-KR0X27;9K;OG<(TV\<W_T?B62$FGK5= 8KK%Z"+5ZV+
MU2^7D'WCE=6HR8XGS?IX?]IZ;0)R-J=?D8WVB8%PWUSM9$=Y?S9[%6CKU1;(
MC?U9D'F -4,R6+<^A?6#_.N2>V=:8LWCJ5-T7KLNN^%YC[7G)UF+,GZ>C+UO
MV^OL=0J]^&F 93:']UG_UY/>3EWIC8&8GGS-Z:764LNG!VK'?-=P"05;5ZVI
M7I&&%=767>]/8=8FV&ANV]Q@ [RVGF]=\IU\OI[*=UQCV,4U<OWR<=C,=<W'
M[-FV(K;.1V+/6;*?=9U7AT V]K97:WG7WUYX+>ZEZPS[%V5>ZS/H=0FT[LW9
M!T&=W;'#UZ3?>_UNQ]>F=91-7_=<_M[+AU\/?(#?EHW5D>QKNX"M69<!V_:B
MAZV+[ AVMJ1@B[:6:A7V8-]ZO_6$[2=4V$9[THZTXQ<:-LPG$37M!==SG?-)
MU\F8HLUHI]AY'[;,8A]]+O8BYFC_?3.VU2X(,DG:M<">8]=I._;@$?W53CCW
MC\WEC=5H@[Q^9(> ;[62G:\WV4OV6PUE9X0^WQ6(8BO->A_3?+IGV7F[ZOX'
MILN;-\<^K]?*'_NY;F##VK=4FAW4?J]L=F3@9G=^<#8'?=^*?D0VZK>[KWYY
MMOGN]O79_'J6!Z+]Z[7?[4>-E1:18![(9=="$J$)V&A3X"&W_5Y=HUQ"7[A[
M:<_N*$+M7OUQVB\[]L<8M #:7^TT:MLUWU^X'?ZAVHF+JDU,L=KK7FQN9J]_
MQ.[-C55&@DHLKEW_Z=J9(*^]__WJO[8'F%0?M 0@?3IFD]1/]> ^:RS;VSJ(
M1W*#-$;@50VN3]NDX[A.;5_;=':V#;)S@&![</!MQR'A-K]];AOO)Z#$C6XW
M\2[@N"UPTX!+O+S-M=';"[>7AV^?W"KWO@UOAX%JG\3]JS&!26"_;<6S-O5V
MJLC%*]QK(,.]!CK<9CQ</0;&\13WP7T27-P_(!N(<K^!R'3'/0=F?G;@L8L'
MDMQ;_ BXQ[>!_C7+??JXW((\S/T()H)P'2-H<^]?.#<(CU'31O3?=)W8[-KZ
M'R<X.!9L-3BK_CM_O@<BTEVG,:V/%M.M,([G#:/4S5_PD%7W+2C28-VB?%FX
MW7'=:B&S&':3WN$@V1W':-YG-Z,Q)AY)T^"-UW;O$^.:-BAW5S!TMT@8#M[=
M2*XY>!HVX(8AP"SV -Z^=L(P>->#[/?0@7BC8HKW/\AXLRV.-P((>=O>DO<.
M1'E7" RA0^BE081F0.9]2[E;G;<='36?8J$WY#IZU]TD8>=P'**$.B%(R"RT
MA)HK3'@&R(1FB?:=%LK> 7T_;R?TA&?93Z@(>LWB6E'H>]-$G4'PO13R[UGX
MFN)L"T$+5"A?.3+?[DZLRA7.JM(WJ;#O5-^YZO5-=&??:"%XP]![W^:W+R]^
M2\OEMSIX?F?SNF$W_UL$A@<;8;@2&8:#[,!Z?QL_+,S#L7]WA69$!&X9?I+"
MZ@#N)!3@GR$"[AH^Y@SX]^UPM&A._6L(8U?@1<D%;AM:(;AAC,&!AVL>>#Z?
MK8G@W3<)SI)ZHFL]"DZ0B0 K^,WZ^<ST CT,KGY3AW>9=2C2U_)04![>'5X$
MBCD/#B7V->5AE=H>]N19JGN8-YHY.+B'@X37AR/2$HX?ZH=/>']X*T1L4WCK
M.2!NAV,#%GYKA>1E31<.(<ZK*&*UX(:3X2>&&;Z%I^%;ZAI^3:_V$ )6GB)J
MY6IJBVB62HE6(AXN']:(9-F-Z(?OB('X8 _: (D+XY"H'!CWBGAS#X@ YX ]
M]:@E]N!1XB3>ME;BZ.$E#@QIXT$X)ZXUBHF?^$KZ#J*)I?C7.)>/" YY+8[+
MNN)V8BP^W^6)M+B<>,8\B[BXH+B+PTE(HR^>* +C47AN_R@6XPCC,2YK)N-,
M\3*.V#3CU"FG6-Y?I^=]J.A 5>-TZS6>-V7CUCU;_B:^BM^XFE.7MXU>3+5X
MCM,!?3G-(9@/YB1C/6.L&8OS.-O*+.;C>\(^KN;@NV3:/WXL!N0(T$"N-Z(-
M(_[?R(S_S.6BN]207_BLZ;KHEJ(U$WGJ59'#C&D 1I[":.2/]KX(EH/D6F/5
MJ%FJJ0%^H':2L_)$"H3CY+?D$V-?,RE#-Z]XG91!S.1P2DWN,>+D(N,T+FXS
M]FYI5#[&#.46^8;_Y!SE23F?N917C3UCM>CFQQ93^7-ID$NF^;UM[XW,X;M!
M5Q[E?^4M>6S;E(_EXEI9[MV?Y=A-6F[>TX5A(Y!O[)&-SOB"#XVKC7+^.-[A
ME^.08HC_T?SE6VI@_N?K^.MX5&V8$XY$]VU>R7WAC7GC2!I"CFF!Y"B98]]:
M8FQ6G,N76T#GJ"6"CIZYN Z:AY 4Y&A^T<WG#23MB$BEY@B@?,::[XXW).L(
M/*)VL_EA+LJ[^KU=;CY1[^:@VO/8H_WFM;QP;JT1Y_8K7<@]&DG&LK2VG.\Y
MS7D:\)QWY]%Y^CB=MV7P/B75I6;G29/\R)VS^][YK@O[/ 7B.?^(!VKYYWF?
M\B[7),FMX^2>A^8)Y.*,[,O,.%NA=Y\S_!5D@:XZ,I ;9(+>04[\Q#Y%1Z [
M_ ;Z"8"@XVPK)%X,K>WHO0$,R3!%Z WZA/Y:1/LY)(9^%Q,NRTS/U:$7_+T!
MB(Y$LC(C.AEIHF_+4.3D?1JNZ'!=B[ZA [Q=)(PN=\CH=1J-WD38Z&,RCLY$
MZNAKI#?CH[=_:B2/'J2#<,1Q',F$&>E)%?Z\!23I']&2O@4TZ=CPD^[#1>E'
MV()L0#]A5KHIC:7[S*FT)NU)=^D0-(LL0>/(8WK\H)@7I&P.A(:F-U%X>N%O
)^!_^B'_B'Z<#
 
end

From mea@sparta.com  Sun Apr 12 11:40:56 1992
From: mea@sparta.com (Mike Anderson)
Date: Sun Apr 12 11:41:04 PDT 1992
Subject: Re:  comp.os.vxworks newsdigest
Greetings!

----- Begin Included Message -----

From: paulg@tplrd.tpl.oz.au (Paul Gittings)
Organization: Telectronics Pacing Systems
Message-ID: <1992Apr10.165244.20964@tpl68k0.tplrd.tpl.oz.au>

This is a beginners question and I apologize in advance if I've wasted
bandwidth by asking for information which I should have been able to find 
in the manual (I did look, Honest).

Are there any major differences in a tasks environment when it is run
from the shell:

   -> main

to when it is spawned off using "sp" ?:

   -> sp main

We have vxWorks 5.0.2 and our target is National Instruments  VXIcpu030.

Cheers,
Paul Gittings

----- End Included Message -----

Well, first there was a syntax error in the code:

sd = socket(PF_INET,SOCK_STREAM,0);

should have been

sd = socket(AF_INET,SOCK_STREAM,0);

but that's not what's causing your problems.  The differences you're
experiencing are a result of the context your main is executing in.
When you run main from the shell, "main" runs as a subroutine within
the shell task's context and as such uses the shell task's stack.

-> main

    |---------------Shell Task---------------|
    |                             |----------|
    |          |----------|       | Stack    |
    |          |  main    |       |----------|
    |          |----------|                  |
    |----------------------------------------|

But, when you use "sp", "main" becomes a separate task and uses a
new stack whose size is determined by the parameters to "sp" as
defined in <vxWorks-dir>/config/all/usrLib.c.

-> sp main

    |---------------Shell Task---------------|   |------ main task -----|
    |                             |----------|   |              |-------|
    |                             | Stack    |   |              | Stack |
    |                             |----------|   |              |-------|
    |                                        |   |----------------------|
    |----------------------------------------|

To set it up so main has the same stack size as the shell task, either
use taskSpawn and explicitly fill in the stack size or modify the 
stack size parameter in usrLib.c when sp calls taskSpawn to actually
spawn the task.  Remember that "sp" is really just a front end for
taskSpawn that fills some of the pieces for you.  You can check the 
current stack parameters for a given task using checkStack.  Also,
anytime you use NFS in any of your tasks, be sure to have at least a 7K
stack and preferably more like 10K if you expect your code to avoid
stack crashes.

Good luck,

==============================================================================
    AAAA  D D    D D    EEEEE   M   M  TM  // AAAA RRRR  TTTTTT SSSSS EEEEE TM
   A   A  D   D  D   D  E      M M M M    // A   A R   R   TT   S     E
  AAAAAA  D   D  D   D  EEEEE  M  M  M   // AAAAAA RRRR    TT    SSS  EEEEE
 A     A  D   D  D   D  E      M     M  // A     A R  R    TT       S E
A      A  D D    D D    EEEEE  M     M // A      A R   R   TT   SSSSS EEEEE

Process Distribution/Control and Communications for Distributed Systems

Mike Anderson                       Voice: (703) 448-0210 ext. 235
Director, ADDEM(TM) Project Office  FAX:   (703) 734-3323
SPARTA, Inc.                        EMAIL: mea@sparta.com
Suite 900                     
7926 Jones Branch Drive        "The optimist proclaims that we live in the
McLean, VA  22102               best of all possible worlds, and the pessimist
                                fears that this is true."

                                    J.B. Cabell

==============================================================================

From iphasew!hwajin@apple.com  Mon Apr 13 12:29:30 1992
From: hwajin@iphasew.com (Hwa-Jin Bae)
Date: Mon Apr 13 12:29:37 PDT 1992
Subject: Re: Differences between shell and sp task starts??

>Well, first there was a syntax error in the code:
>
>sd = socket(PF_INET,SOCK_STREAM,0);
>
>should have been
>
>sd = socket(AF_INET,SOCK_STREAM,0);

PF_INET == AF_INET.  This isn't syntax error, it is now a preferred
way to specify protocol families. [ there is a reason for this. ]

From the original program,

>  ns = accept(sd, &cnnSocket, &fromlen);

Notice that fromlen is never initialized to any value.  The last
argument to accept() is a value/result.  You should set it to
something like "sizeof (struct sockaddr_in)".  [ there is a reason
for this. ]

*hwajin

From iphasew!hwajin@apple.com  Mon Apr 13 12:30:22 1992
From: hwajin@iphasew.com (Hwa-Jin Bae)
Date: Mon Apr 13 12:30:35 PDT 1992
Subject: Re: Request Basic VxWorks Info

>>         3) What is the default size for a UDP socket (what is the maximum
>> length that can be used in sendto(), without first using setsockopt())?
>> Is this configurable by the user?
>
>4400 bytes, if I remember well. It was some time ago that I've handled that.
>Didnt look for a configuration parameter to change this. Used setsockopt
>on the socket before that socket was passed to RPC.

Global variables (not changed from 4.3 Tahoe network code):

udp_sendspace = 2048
udp_recvspace = 4 * (1024 + sizeof (struct sockaddr_in));

These are adjustable  via setsockopt() SO_SNDBUF and SO_RCVBUF on
per socket basis.

>> 
>>         4) If the answer to 3 is < 8Kbytes, does VxWorks' implementation
>> of RPC use setsockopt() to allow 8Kbyte UDP transmissions?
>
>No. I think I reported this to WRS, so maybe your version already will
>include a fix to this.
>NFS client code however has it's own RPC library, which apparently works
>just great with 8KB buffers.
>

NFS code uses setsockopt() to allow 8 K byte UDP transmissions over RPC.
NFS uses the same RPC library as everyone else.

Other RPC applications would control socket buffer size themselves --
this is the standard method  --  SunOS RPC library does the same.

From daemon@vxw.ee.lbl.gov  Wed Apr 15 04:00:31 1992
From: daemon@vxw.ee.lbl.gov
Date: Wed Apr 15 04:00:39 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Apr 15 04:00:24 PDT 1992

        Subject: Heurikon for sale
        Subject: Re: rlogin to a target clobbers remote user name
        Subject: Re: heurikon for sale

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Heurikon for sale
Date: 13 Apr 92 20:13:25 GMT
From: fester@etorofu.island.COM
Organization: Island Graphics, Marin County, California
Message-ID: <1992Apr13.201325.4749@island.COM>
Sender: usenet@island.COM (The Usenet mail target)

$1200 OBO

Mike Fester	day 	(415) 491-1000 x190
		evening	(415) 750-9220

or email me at fester@island.com

- -- 
Disclaimer - These opiini^H^H damn! ^H^H ^Q ^[ .... :w  :q  :wq  :wq! ^d  X ^?
exit X Q  ^C ^? :quitbye  CtrlAltDel   ~~q  :~q  logout  save/quit :!QUIT
^[zz ^[ZZZZZZ ^H  man vi ^@  ^L  ^[c  ^# ^E ^X ^I ^T ? help  helpquit ^D  ^d 
man help ^C ^c help exit ?Quit ?q CtrlShftDel "Hey, what does this button d..."

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: rlogin to a target clobbers remote user name
Date: 15 Apr 92 06:34:34 GMT
From: pat@wrs.com (Patrick Boylan)
Organization: Wind River Systems, Inc.
Message-ID: <pat.703319674@wrs.com>
References: <HMP.92Mar26140203@deimos.frc.ri.cmu.edu>
Sender: usenet@wrs.com (News Manager)

hmp@frc2.frc.ri.cmu.edu (Henning Pangels) writes:

>Has anyone else observed this? 

>After a completed rlogin session to a vxWorks target, whoami on that
>target's console returns a null string. This happens even if I did
>nothing but rlogin and logout.

As Hwajin mentioned this problem surfaced when login security was introduced for 5.0.
The original user and password before a secure login is restored from originalUser and 
originalPasswd.  These were not stored.

The problem has been fixed for the next release and the patch for 5.0 and 5.0.2 is
as follows:

- -> remCurIdGet (&originalUser, &originalPasswd);

Patrick
- --
 Patrick Boylan, Consulting Engineer, FAE Asia/Pacific
 Wind River Systems
 1010 Atlantic Ave. Alameda, CA 94501
 pat@wrs.com	(510)748-4100

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: heurikon for sale
Date: 15 Apr 92 01:23:32 GMT
From: lampman@moose.heurikon.com (Ray Lampman)
Organization: Heurikon Corporation, Madison, WI
Message-ID: <1423@heurikon.heurikon.com>
References: <1992Apr10.173505.3673@island.COM>
Followup-To: comp.os.vxworks
Reply-To: Ray.Lampman@Heurikon.Com (Ray Lampman)
Sender: news@heurikon.heurikon.com

In article <1992Apr10.173505.3673@island.COM> fester@etorofu.island.COM writes:
#
# Heurikon  HK68 and MLZ-91/21 Microcomputer. Includes all manuals and
# documentation. Still in the box.
#
# $1200 OBO
#
# Mike Fester	day 	(415) 491-1000 x190
# 		evening	(415) 750-9220
#
# or email me at fester@island.com

I wasn't aware that the MLZ-91 has had VxWorks ported to it.  Can
Heurikon  get  a  copy?  :-)  Maybe  this  article  would be more
appropriate in one of the "forsale" groups. Here's a list:

comp.forsale.computers
misc.computers.forsale
misc.forsale
misc.forsale.computers

Ray.Lampman
VxWorks Coordinator
Heurikon Corporation
- --
Ray.Lampman@Heurikon.Com  ,^-_    "I say, what it occurs to me to
8310 Excelsior Drive      L   `;  say, when I think I hear people
Madison, WI 53717, USA    \ . J   say things, more I can not say"
+1 608 828 3431            L__]   - the man in the shack, D Adams

---------------------------

End of New-News digest
**********************

From jbg.MAILSERVER@wrsec.fr  Wed Apr 15 08:22:09 1992
From: jbg <jbg.MAILSERVER@wrsec.fr>
Date: Wed Apr 15 08:22:16 PDT 1992
Subject: OSI/MMS Feedback required
                       Subject:                               Time:16:40
  OFFICE MEMO          OSI/MMS Feedback required              Date:15/04/92

	As you might know, MARBEN is a french company developping OSI related
products. MARBEN did port part of their OSI software to VxWorks.

1-WHAT HAS BEEN DONE:

Today MARBEN/OSI protocol stack runs a VxWorks 68k based target up to the
transport layer (TP4 interface).

The Data Link level which has been tested is 802.3 (ethernet).
They tested it actually over on board ethernet link available on a typical VME
single board computer.

They also did some evaluation on porting MMS client on VxWorks.

WARNING: These ports must not be considered as off the shelf products.

2-MMS (Manufacturing Message Specification):

To be simple and quick MMS is a standard protocol standardized by OSI. The aim
of MMS is to inter-connect any kind of factory equipments (e.g: robots, PLCs,
numeric machine tools ...) and to have them communicate easily and efficiently.

The biggest part of MMS is the server side. MMS server services are subdivided
into several classes such as Communication,Equipment, Tasks, Domains,
Variables, Semaphores, Events and so forth.

As some equipments and applications don't have to support all MMS services, big
customers or OEMs have defined MMS Profiles. A MMS profile is actually a subset
of available MMS services. As an example the EDF Profile seems to be a
reference in France.

A MMS server software package can't be fully developped hardware independent.
That means MARBEN would provide a MMS server environment package that allows
customers to interface with their specific hardware equipments.

3-FEEDBACK NEEDED:

In order for MARBEN to port MMS server (or at least part of it) MARBEN and WRS
need to know whether or not it makes sense. Is there a real market and how big
is it? What MMS services are required? Does it make sense to productize
something? Idea of Pricing eventually?

Whenever you have a request regarding OSI and MMS feel free to let us know.
Although there is no real product for time being MARBEN is able to provide high
level consulting services around potential OSI/MMS implementation with VxWorks.

We need inputs from anyone and especially from the field (WRS ,OEMs and 
Partners Sales and FAEs for instance).

Send comments and inputs to me and thanks in advance for your contribution.

Jerome BRING
Wind River Systems Europe
e-mail: jerome@wrsec.fr

From jbg.MAILSERVER@wrsec.fr  Wed Apr 15 10:02:47 1992
From: jbg <jbg.MAILSERVER@wrsec.fr>
Date: Wed Apr 15 10:02:54 PDT 1992
Subject: Defining Embedded Systems
                       Subject:                               Time:18:42
  OFFICE MEMO          Defining Embedded Systems              Date:15/04/92

Hi everybody,

	As we talk more and more about embedded/real-time systems I think it is good
to propose a sort of definition. So please find below some caracteristics of
embedded systems I have been collecting. Feel free to comment and/or add
anything to it.

* The difference between an embedded system and a free standing computer
largely depends on how users perceive their interaction with it. If users
believe they are working with a computer, it's a computer. If users see
themselves as interacting with something else (a fax machine, an airplane or a
printer for instance), it's an embedded system.

* Embedded systems are part of a larger system whose main purpose is not
computing. There is a strong interaction with the rest of the system which
normally means direct physical and electrical connection.

* Embedded systems have absolute performance requirements. The system must
satisfy all requirements in absolute terms: if the requirements are not
satisfied, the system will not work. The most critical requirements are
generally specified in terms of time or temporal reactions, so, the terms
"real-time" and "embedded" are very closely related.

* Embedded systems have a specific purpose. Although most embedded systems are
a combination of hardware and software which allows a certain flexibility, the
purpose of the embedded system does not change during its lifetime. One
consequence is that operators do not generally load or change the software,
this being regarded as a maintenance operation.

Thanks in advance.
Bye

Jerome BRING
jerome@wrsec.fr

From dit@bach.jhuapl.edu  Wed Apr 15 11:31:44 1992
From: dit@bach.jhuapl.edu (Daryl I. Tewell)
Date: Wed Apr 15 11:31:51 PDT 1992
Dear Sirs:

     Please change my "Exploder" subscription address from
dit@melchor.jhuapl.edu to dit@bach.jhuapl.edu.

                                  Thank You,
                                  Daryl Tewell

From @ada3.ca.boeing.com:crispen@efftoo.boeing.com  Wed Apr 15 11:39:27 1992
From: crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com>
Date: Wed Apr 15 11:39:35 PDT 1992
Subject: Re:  Defining Embedded Systems
Jerome Bring writes:

>* The difference between an embedded system and a free standing computer
>largely depends on how users perceive their interaction with it.

Well, yes, but who's a user?  I'll offer two counter definitions.

(1) Embedded systems are something that embedded systems kinds of
people do.

In the flight simulation business, there are people who need to be concerned
with exactly the same kinds of things that concern people who design black
boxes, controllers, and so on.  They need to know about interrupts, hard time
deadlines, scheduling, resource locking, device control, and so on.

To the guy who's gotta know that stuff, a flight simulator is an
embedded system.  To the other engineers a flight simulator *shouldn't* be
an embedded system.

(2) Embedded systems are systems that are actually embedded in something.

The Air Force a while back defined "Embedded Training" as something that
was "built into or added onto" a system (aircraft, etc.) that provided
training capability.  For example, an embedded training system in
a submarine would let the sonarman turn a switch and his radar would start
showing bad guys.

By definition (2) an embedded system probably ought to be "built into or
[designed to be] added onto" something.

I *love* religious discussions like this, and it really just depends on
where you start drawing your boundaries.  I prefer to start at the extremes
(to find out if they really are extremes) rather than at the middle.

Best to you,

Bob Crispen
crispen@foxy.boeing.com

From daemon@vxw.ee.lbl.gov  Thu Apr 16 04:00:27 1992
From: daemon@vxw.ee.lbl.gov
Date: Thu Apr 16 04:00:34 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Apr 16 04:00:19 PDT 1992

        Subject: Stethoscope
        Subject: Re:  Defining Embedded Systems

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Stethoscope
Date: 15 Apr 92 19:19:28 GMT
From: mkb@frc.ri.cmu.edu (Mike Blackwell)
Organization: Field Robotics Center, CMU
Message-ID: <1992Apr15.191928.126541@cs.cmu.edu>
Reply-To: mkb@cs.cmu.edu

Could someone please send me a contact (email or phone) for the
Stethoscope product? I think it will perfectly solve a problem I'm
having. Thanks...		-mike-

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re:  Defining Embedded Systems
Date: 15 Apr 92 22:31:47 GMT
From: rlk@VisiCom.COM (Bob Kitzberger)
Organization: VisiCom Laboratories, Inc., San Diego, California
Message-ID: <173@visicom.com>
References: <9204151839.AA23989@vxw.ee.lbl.gov>
Sender: news@VisiCom.COM

Bob Crispen writes:

>In the flight simulation business, there are people who need to be concerned
>with exactly the same kinds of things that concern people who design black
>boxes, controllers, and so on.  They need to know about interrupts, hard time
>deadlines, scheduling, resource locking, device control, and so on.

These aspects make flight simulators real-time systems, not necessarily
embedded systems.  A flight simulator can also be considered an embedded 
system, the characteristics that determine this being that the computer(s) 
is embedded inside of controls, gauges, and other sundry devices not 
normally part of a general purpose computer.

There are real-time systems, and there are embedded systems, and then there
are real-time embedded systems.  'Real-time' and 'embedded' are often
used interchangeably, but to me they are quite distinct, the former
implying a set of temporal requirements, and the latter implying a set
of hardware/sensor interaction requirements.  I don't know how often I've 
seen something advertised as being a real-time tool, when really it's 
just an embedded systems tool.

>(2) Embedded systems are systems that are actually embedded in something.

This I like better.

>I *love* religious discussions like this, and it really just depends on
>where you start drawing your boundaries.  I prefer to start at the extremes
>(to find out if they really are extremes) rather than at the middle.

Good point.   Can anyone think of a system that directly interacts with 
sensors, gauges, or other non-general-purpose hardware that we would NOT 
consider to be an embedded system?   There may be a kernal of a definition
here... (no pun intended) unless of course one of Bob Crispen's extreme's
blows this out of the water ;-)

	.Bob.
- ----------------
Bob Kitzberger          VisiCom Laboratories, Inc.
rlk@visicom.com         10052 Mesa Ridge Court, San Diego CA 92121 USA
			+1 619 457 2111    FAX +1 619 457 0888

---------------------------

End of New-News digest
**********************

From honce@rhine.stx.com  Thu Apr 16 04:16:58 1992
From: Jhon Honce <honce@rhine.stx.com>
Date: Thu Apr 16 04:17:07 PDT 1992
Subject: BEEP! Re: comp.os.vxworks newsdigest 
    This is an automatic reply.  Feel free to send additional mail, as only
    this one notice will be generated.

I'm at the IMS retreat for the week of 4/13/1992 to 4/17/1992.

/jwh
jhon honce -- honce@spso.gsfc.nasa.gov
           -- honce@rhine.stx.com

From hebo@mbari.org  Thu Apr 16 08:49:51 1992
From: Bob Herlien <hebo@mbari.org>
Date: Thu Apr 16 08:49:58 PDT 1992
Subject: Re: Embedded Systems
> From: rlk@VisiCom.COM (Bob Kitzberger)
>
> Good point.   Can anyone think of a system that directly interacts with 
> sensors, gauges, or other non-general-purpose hardware that we would NOT 
> consider to be an embedded system?   There may be a kernal of a definition
> here... (no pun intended) unless of course one of Bob Crispen's extreme's
> blows this out of the water ;-)
> 
> 	.Bob.
> 
In the early '70s (around '70-'72) I did some work on the original PLATO
system at the University of Illinois.  PLATO was one of the early computer-
aided-instruction machines.  At the time, it was being migrated from a 
CDC 1600 to a CDC 6600 (both general-purpose, although now ancient, machines).

I was working with (taking a special projects class in) the EE department.  
We had a "typical" EE lab setup:  oscilloscope, function generator, oscillator,
etc., all wired through sensors & guages so that the students' configuration
could be sensed by the main CPU.  We wrote CAI software to "teach" EE lab.  
This software ran in a typical (for the day) timesharing type environment.
This was not an embedded system -- we had no embedded CPU's (this was before
the age of micros.  Oops, my age is showing :-).

-----------------------------------------------
Bob Herlien
MBARI (Monterey Bay Aquarium Research Institute)
hebo@hp850.mbari.org

From harvey@yuba.wrs.com  Thu Apr 16 11:57:37 1992
From: harvey@yuba.wrs.com (Harvey Wong)
Date: Thu Apr 16 11:57:44 PDT 1992
Subject: Stethescope
Dear VxWorks Users,

Wind River Systems is now a distributor for Real-Time Innovation's
Stethoscope product.  WRS will be shipping and supporting this unique
data collection and graphical monitoring tool by the end of April.

Stethoscope allows developers to choose any program variable and
watch them change in real-time.  This data can also be saved for
later analysis.  Stethoscope also includes a dynamic execution profiler
which enables developers to analyze the execution flow of their
aplication and how the CPU is being used.

Please feel free to call WRS directly at 510/748-4100 for more information.

Sincerely,

Harvey Wong
Wind River Systems, Inc.

From daemon@vxw.ee.lbl.gov  Fri Apr 17 04:00:44 1992
From: daemon@vxw.ee.lbl.gov
Date: Fri Apr 17 04:00:53 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Apr 17 04:00:36 PDT 1992

        Subject: Stethoscope found
        Subject: UNIX compatible rsh for VxWorks?
        Subject: tar/rmt

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Stethoscope found
Date: Thu, 16 Apr 92 14:09:44 GMT
From: mkb@frc.ri.cmu.edu (Mike Blackwell)
Organization: Field Robotics Center, CMU
Message-ID: <1992Apr16.140944.69631@cs.cmu.edu>
Reply-To: mkb@frc.ri.cmu.edu

I now have the contacts for Stethoscope. Sheesh, I must be the only person in the
world who didn't know...		cheers, -m-

---------------------------

Newsgroups: comp.os.vxworks
Subject: UNIX compatible rsh for VxWorks?
Date: Thu, 16 Apr 1992 16:25:32 GMT
From: jsnow@javelin.sim.es.com (John Snow)
Organization: Evans & Sutherland Computer Corporation
Keywords: rsh vxworks
Message-ID: <1992Apr16.162532.7341@javelin.sim.es.com>

Now that we have a UNIX compatible rsh deamon for VxWorks
that allows UNIX boxes to rsh to a VxWorks node, does
anyone have a UNIX compatible rsh command that will
run under VxWorks? We would like to be able to rsh from
VxWorks back to UNIX or from VxWorks to VxWorks.

Doesn't seem like it would be to difficult to write rsh
for VxWorks since VxWorks already supports rcmd. But,
not being one to reinvent the wheel, I was wondering if
someone has already done it.

Please, no responses about VxRsh - it's not UNIX compatible.

- -- 
- -----------------------------------------------------------------------------
John F. Snow                         INET:           jsnow@javelin.sim.es.com
Evans & Sutherland Computer Corp.    
Salt Lake City, Utah                 America Online: JohnSnow  GEnie: J.SNOW2

---------------------------

Newsgroups: comp.os.vxworks
Subject: tar/rmt
Date: 16 Apr 92 19:38:16 GMT
From: singer@ll.mit.edu (Matthew R. Singer)
Organization: MIT Lincoln Laboratory
Message-ID: <1992Apr16.193816.18979@ll.mit.edu>
Reply-To: singer@ll.mit.edu (Matthew R. Singer)
Sender: singer@ll.mit.edu (Matthew R. Singer)

- --
Before I go off and reinvent the wheel, does anyone have a hacked version of
one of the PD tar clones running under vxWorks?  

I'd sure like to tar off files on local disks to a tape drive on my Sun.  Of
course this would all go away if there was just server side NFS...
 

Thanks for you time and bandwidth...

- ---------------------------------------------------------------------------
Matthew R. Singer                                    MIT Lincoln Laboratory
(617) 981-3771                                       244 Wood Street
singer@ll.mit.edu                                    Lexington, MA 02173
- -----------------------------------------------------------------------------

---------------------------

End of New-News digest
**********************

From daemon@vxw.ee.lbl.gov  Sat Apr 18 04:00:25 1992
From: daemon@vxw.ee.lbl.gov
Date: Sat Apr 18 04:00:32 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Apr 18 04:00:18 PDT 1992

        Subject: accepted method of ld'ing many .o files
        Subject: setting up SCSI w/ vxWorks 5.0
        Subject: Re: tar/rmt
        Subject: Re: Differences between shell and sp task starts??

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: accepted method of ld'ing many .o files
Date: Fri, 17 Apr 1992 13:14:13 GMT
From: rg@msel.unh.edu (Roger Gonzalez)
Organization: UNH Marine Systems Engineering Lab
Message-ID: <RG.92Apr17081413@nymph.msel.unh.edu>
Sender: news@nic.unh.edu (USENET News System)

Now that I'm getting moving beyond one or two object file test programs into a
big project, I'm curious how people handle the need to load large numbers of
object files.

I was thinking about having some C code generated through shell scripts and
the makefile that would automatically produce some code like this:

char *app-name[] = {
	"/path/objfile1.o",
	"/path/objfile2.o",
	"/path/objfile3.o",
	"/path/objfile4.o",
	"/path/objfileN.o",
	0
};

boot(app, variable args)
{
	foreach string in app, do a ld
	then invoke the first one with the variable args.
}

Am I missing something easier?

- -Roger

- --
"The question of whether a computer can think is no more interesting
 than the question of whether a submarine can swim" - Edsger W. Dijkstra 

Roger Gonzalez   -  rg@msel.unh.edu
Division of Bit Banging and Reluctant Robotics
UNH Marine Systems Engineering Laboratory, Durham, NH  03824-3525
(603) 862-4600 -4399 (fax)

---------------------------

Newsgroups: comp.os.vxworks
Subject: setting up SCSI w/ vxWorks 5.0
Date: 17 Apr 92 13:50:14 GMT
From: kwaldman@bbn.com
Organization: bbn
Message-ID: <kutlsmINNb3b@news.bbn.com>

	I am trying to setup a scsi disk on two different vme systems
running VxWorks.  The system consists of a MV167 motorola board (68040) and
and 4 SkyBolt AP's (i860's), a harddisk connected using the scsi port
on the 712M transition module which connects to the MV167 via the P2 adapter
board.  The boot files reside on a Sun Sparcstation.  Both systems
are using the same file.  I have done this in the past, the only difference is
I added the #define INCLUDE_SCSI to the target config.h file.

	Both setups identical.

	The first fails right after it loads the kernel with

	Starting at 0x100...

	The second one boots fine!
		The difference is the type of vme chassis the first one
uses a Force Target 32 chassis and the second uses a ruggedized chassis
by Cyberchron, I have no reason to think either chassis is faulty.
	
	The main problem I have is how do I set up the scsi? I do have
the VxWorks Technical Notes "Using SCSI devices with VxWorks 5.x"
	
	I have run out of ideas, any suggestions?

	Thanks in advance

	Karl

Please reply to kwaldman@bbn.com if you can.

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: tar/rmt
Date: 17 Apr 92 17:24:36 GMT
From: james@wrs.com (James Moore)
Organization: Wind River Systems, Inc.
Message-ID: <james.703531476@wrs.com>
References: <1992Apr16.193816.18979@ll.mit.edu>
Sender: usenet@wrs.com (News Manager)

You could ftp from the sun to the vxWorks system and get the files
that way.  

- --
James Moore                                 | james@wrs.com
Wind River Systems                          | Alameda, California
      "Half of what he said meant something else, and the other half meant
				nothing at all"

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Differences between shell and sp task starts??
Date: 17 Apr 92 17:17:14 GMT
From: james@wrs.com (James Moore)
Organization: Wind River Systems, Inc.
Message-ID: <james.703531034@wrs.com>
References: <1992Apr10.165244.20964@tpl68k0.tplrd.tpl.oz.au>
Sender: usenet@wrs.com (News Manager)

paulg@tplrd.tpl.oz.au (Paul Gittings) writes:

>Are there any major differences in a tasks environment when it is run
>from the shell:
>   -> main
>to when it is spawned off using "sp" ?:
>   -> sp main

99 times out of a hundred, when something exhibits different behaviour
under the shell and as it's own task, it's a problem with the stack.
Run checkStack() and make sure you're not using any uninitialized
variables.

The hundredth time, it's a priority problem.

- --
James Moore                                 | james@wrs.com
Wind River Systems                          | Alameda, California
      "Half of what he said meant something else, and the other half meant
				nothing at all"

---------------------------

End of New-News digest
**********************

From dave@yuba.wrs.com  Mon Apr 20 23:26:31 1992
From: dave@yuba.wrs.com (David N. Wilner)
Date: Mon Apr 20 23:26:38 PDT 1992
Subject: bit-fields, volatile, ANSI-C
Folks,

This is a response to the discussion last week about bit-fields,
"volatile", ansi C, etc.  I didn't see all of the discussion because it
went to the exploder and I had dropped off the exploder because I thought
the exploder and comp.os.vxworks were interconnected.  But I guess not
because the discussion didn't show up on the newsgroup.

Anyway, the issue is a confusing one, but we *have* sorted it out fairly
thoroughly.  Fred Roeber brought it to our attention about a year ago
and we dealt with it then.  I wrote an excruciatingly detailed account
of the problem that I still have if anyone wants it, but I'll try to
summarize the results here.

The basic question is about the atomicity of modifying bit-fields.
The basic answer is you can't assume the atomicity of modifying bit-fields.

It turns out that, as Fred discovered, you can get away with it in some
cases on the 68k, but some compilers with some options may generate
non-atomic bit-field code.  And, as was pointed out by someone else,
on most RISC processors bit-fields operations are never atomic.

Someone wrote that "in a number of places, VxWorks is coded around the
concept that bit manipulation operations are safe" (meaning atomic
with respect to interrupts).  Well, in actuality there was only one
module in the kernel that made this assumption.  This was in tyLib
in which we kept a word of software status bits indicating the state
of the serial line.

It turns out that this worked in our 68k distribution because we didn't
use "-fvolatile" which as Fred pointed out causes gcc to generate
non-atomic bit-field code.  (We have also carefully verified that tyLib
does not need to be compiled with "-fvolatile".)

However, it was clear that it would be a problem for our RISC ports.  
The fix was quite simple: we changed all the bit-field flags to byte-wide
flags, the setting of which are atomic.  This is the way tyLib is
currently distributed in all our RISC ports, and will be in all ports
in future releases.

As a side note, you should be careful using "-fvolatile".  This flag says
"treat all pointers as volatile".  This is a very big club to hammer the
code with.  It doesn't say "treat the things pointed to by all pointers
as volatile".  It's even stronger than that, since it says the pointer
itself might change.  This is the crudest thing you can do to force just
about everything referenced indirectly to be treated as "volatile", and
is clearly a sledge-hammer fix until the code has been "ansi-fied" to use
the "volatile" construct correctly.

So this leads to the other part of the discussion: the use of ANSI C.
Yes, we too are big believers in ANSI C.  We've just completed a big
effort to ansi-fy most of our code.  It's been a big job.  We're still
working on removing all the warning messages.  But we're committed to
it, because we too believe that we will have "safer" code once it's
all ansi and warning free.

The biggest obstacles for us in going to ANSI C is that we had to
wait until all the other tools we have to work with supported it.
We compile VxWorks with lots of different compilers and until
they all supported full ANSI C, we were pretty stuck.  The fact
that SunOS compilers haven't supported ANSI C until recently has
been a big deterrent to use of ANSI C in the Unix world.  The support
of ANSI C was a big plus of switching to the GNU compiler for 68k
cross-development.  However, we are still compelled to use native
compilers for some of the RISC ports.  Sigh.

----
David Wilner
V.P. of Engineering
Wind River Systems
dave@wrs.com

From daemon@vxw.ee.lbl.gov  Tue Apr 21 04:00:27 1992
From: daemon@vxw.ee.lbl.gov
Date: Tue Apr 21 04:00:34 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Apr 21 04:00:21 PDT 1992

        Subject: VxWorks with gcc 1.39/2.1
        Subject: windEx Local Clients
        Subject: Re: accepted method of ld'ing many .o files

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: VxWorks with gcc 1.39/2.1
Date: Mon, 20 Apr 1992 20:23:56 GMT
From: ameres@sol.ral.rpi.edu (Eric Ameres)
Organization: Rensselaer Polytechnic Institute, Troy NY
Message-ID: <2x-vs!q@rpi.edu>

I have taken over as Software Engineer at the center for robotics and am
in the process of making sure all of our software is up to date.  To make 
a long story short it isn't.  We have been using VxWorks 5.0.1 with gcc 1.39 
and cc (SunOS 4.1.1) for quite a while (Sun hosts, 680X0 targets) and I have 
encountered a strange superstition amongst the other staff members and 
students.  Is it possible to use gcc (1.39 or better) to cross compile VxWorks
kernels (i.e. compile on a Sun 4 for a 680X0) ?  We have been keeping one Sun 3
around just to compile kernels. If anyone has done this could they send me the
makefile (I am updating gcc 1.39 to 2.1)?

I have seen some info on the GNU toolkit and am waiting on a return call from
WRS.  Any comments from users?  Is it necessary?  Does it come with GCC 2.1?
Can I make the modifications myself and save the $$$?

Mail responses to ameres@ral.rpi.edu

Thanks in advance

- -- 
Eric Ameres				ameres@ral.rpi.edu
Center for Intelligent Robotic Systems for Space Exploration	
Rensselaer Polytechnic Institute - CII 8313, Troy, NY 12180-3590

---------------------------

Newsgroups: comp.os.vxworks
Subject: windEx Local Clients
Date: 20 Apr 92 21:13:51 GMT
From: vapspcx@prism.gatech.EDU (S. Keith Graham)
Organization: BARCO Chromatics
Message-ID: <55176@hydra.gatech.EDU>

We are trying to figure out if there is a backdoor for
local Xwindows clients that doesn't go through the socket
handler?  

Since VxWorks doesn't appear to support AF_UNIX, we were wondering
if it supports some other connection path other than using
an internet socket with "localhost".

Keith Graham
vapspcx@cad.gatech.edu

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: accepted method of ld'ing many .o files
Date: 21 Apr 92 01:03:01 GMT
From: litwin@litwin.jpl.nasa.gov (Todd Litwin)
Organization: Jet Propulsion Laboratory
Message-ID: <1992Apr21.010301.4244@elroy.jpl.nasa.gov>
References: <RG.92Apr17081413@nymph.msel.unh.edu>
Sender: news@elroy.jpl.nasa.gov (Usenet)

In article <RG.92Apr17081413@nymph.msel.unh.edu> rg@msel.unh.edu (Roger Gonzalez) writes:
>
>Now that I'm getting moving beyond one or two object file test programs into a
>big project, I'm curious how people handle the need to load large numbers of
>object files.

We use the Unix ld command. When I create a Unix program, I usually use cc
to invoke ld by doing something like:

	cc -o progname prog1.o prog2.o prog3.o ...

To build the corresponding file for VxWorks, I do:

	ld -r -o progname prog1.o prog2.o prog3.o ...

Note the the "-r" is necessary to keep the output in relocatable object format.
You can combine any number of object files in this way into a single file
for downloading. Not only is downloading time greatly decreased, but you
no longer need to worry about the order of downloading the modules. In fact,
this method is the only way to deal with two different object files that make
references to functions in each other.

Hope this helps.
- --
		Todd Litwin
		Jet Propulsion Laboratory
		(818) 354-5028
		litwin@robotics.jpl.nasa.gov

---------------------------

End of New-News digest
**********************

From rayssd!pike.ssd.ray.com!fjr@uunet.uu.net  Tue Apr 21 06:17:35 1992
From: "Roeber" <fjr@pike.ssd.ray.com>
Date: Tue Apr 21 06:17:43 PDT 1992
Subject: Re:  cc vs gcc
Eric,  We are using gcc on a SUN4 to cross compile VxWorks for 680X0.
Everything works fine.  You need gas and gld too though.  We had been using
a copy of version 1.39 we got on our own with no problems.  When we got
VxWorks 5.0.2 though it came with a full set of GNU tools to use.  Its whats
called the stable version (1.37) vs the developer version.  We switched to it
just to avoid any potential problems.  The makefiles come with 5.0.2.  You
also get full source for the tools from WRS in case you want to change/fix
them.  Good luck.   Fred

From biocca@bevsun.bev.lbl.gov  Tue Apr 21 09:08:34 1992
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Date: Tue Apr 21 09:08:42 PDT 1992
Subject: Exploder - Newsgroup connection

It is nice to see comments from WRS on the newsgroup/exploder.  I would like to
address the problem Dave mentioned:

> Submitted-by dave@yuba.wrs.com  Mon Apr 20 23:26:31 1992 (David N. Wilner)
 
> This is a response to the discussion last week about bit-fields,
> "volatile", ansi C, etc.  I didn't see all of the discussion because it
> went to the exploder and I had dropped off the exploder because I thought
> the exploder and comp.os.vxworks were interconnected.  But I guess not
> because the discussion didn't show up on the newsgroup...

I did some searching and could not find any articles relating to this topic
that had not been posted to comp.os.vxworks in the past week or so.  It does
appear that some articles were not posted a bit earlier, but the verbose logs
that would indicate why don't last this long.  I did find one article
'stuck' in the posting process -- a request for a change in address or some
such -- something that should never have been sent to the exploder in the first
place.  I did find that a number of articles on this topic had been labeled
with a different subject.  My hypothesis as to why these articles were not
posted is that the news system rejected them due to too many lines of quoted
text.  Please remember to edit quotations down - lines added must comprise
50% or so of the total message to make it through the posting.filter!

Please use the addresses at the bottom of the exploder messages for subscription
changes!

The news system will reject articles for a number of reasons.  The only one
I've seen with any frequency is a lack of subject.  At the current time when
an article fails to post it will retry until it becomes too old and is deleted.
I'll setup a cron job that will let me know when an article is stuck,
but it doesn't happen very often.  Make sure you put subject lines on all
submissions!

Thanks again Dave, for the comments!

Alan K Biocca
Exploder Maintainer

From visicom!VisiCom.COM!trest@nosc.mil  Tue Apr 21 13:15:18 1992
From: Mike Trest <trest@visicom.com>
Date: Tue Apr 21 13:15:25 PDT 1992
Subject: Re:  comp.os.vxworks newsdigest
> rg@msel.unh.edu (Roger Gonzalez)
>
>Now that I'm getting moving beyond one or two object file test programs into a
>big project, I'm curious how people handle the need to load large numbers of
>object files.

Roger:

	We use gnu with the following makefile snippets:

               AR = ar68k cq
               LD = ld68k -r -d -X
           RANLIB = ranlib68k

OBJS = \
        ActionHook.o Alloc.o  ArgList.o  Callback.o \
        ClickTime.o Composite.o  .....

all:: libXt.a Xt.o

Xt.o: $(OBJS)
        $(RM) $@
        $(LD) -o Xt.o $(OBJS)

libXt.a: $(OBJS)
        $(RM) $@
        $(AR) $@ $(OBJS)
        $(RANLIB) $@

The first "Xt.o:" produces a single ".o" file from all of the
".o" files in the list defined by $(OBJS).

The second "libXt.a:" produces a linkable library from which
the user's link activity may selectively include only the modules
which are needed in the specific X application.

My point is that you can "Have It Your Way" and use GNU under
VxWorks to provide either (1) individual named ".o" files in
your makefile, (2) a large incrementally linked agregate ".o" file,
or (3) a collection of ".o" within the library structure.

For X and Motif clients we find that all three are used depending
on the application requirements.

..mike..

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 457 2111
Technology Group                Fax:   619 457 0888
VisiCom Laboratories            San Diego, CA 
====================================================

From kozubal@luke.atdiv.lanl.gov  Tue Apr 21 13:41:47 1992
From: kozubal@luke.atdiv.lanl.gov (Andy Kozubal)
Date: Tue Apr 21 13:41:55 PDT 1992
Subject: VxWork Users Group Meeting
My compliments and thanks to Steve King for chairing the
recent Users Group meeting.  The program ran very well,
and I thought it was well worth attending.  Also, thanks to
the WRS people who worked so hard on the logistics and
made some fine presentations.  Finally, thanks to all the users
who made the customer presentations.

------------------------------------------------------------------
Andy Kozubal			| Mail Stop H820		
Phone: (505) 667-6508		| Los Alamos National Laboratory
E-mail: kozubal@ATDiv.lanl.gov	| Los Alamos, New Mexico 87545
------------------------------------------------------------------

From daemon@vxw.ee.lbl.gov  Wed Apr 22 04:00:28 1992
From: daemon@vxw.ee.lbl.gov
Date: Wed Apr 22 04:00:35 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Apr 22 04:00:22 PDT 1992

        Subject: mathLib
        Subject: Re: mathLib

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: mathLib
Date: 21 Apr 92 15:53:03 GMT
From: hayes@ddemo3.aero.org (Brian Hayes 74-35 x65129)
Organization: Hughes Aircraft Company; El Segundo, CA
Message-ID: <21325@hacgate.UUCP>
References: <RG.92Apr17081413@nymph.msel.unh.edu> <1992Apr21.010301.4244@elroy.jpl.nasa.gov>
Followup-To: hayes@hac2arpa
Sender: news@hacgate.UUCP

We recently encountered this problem:  

	Undefined symbol _mathInit.

One of our programmers used the mathInit function in his code.  But, 
why do we get this error?  According to the documentation, the linker
is suppose to load the math library.

Using 5.0.1 (Sun) with GNU Toolkit 1.37.1.  Crosscompiling to TI 147 
platform.

Thanks.
- -- 
<<<<<<<<<< Brian Hayes hayes%bh_ddemo3@hac2arpa (310) 616-5129 >>>>>>>>>>>>

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: mathLib
Date: 22 Apr 92 00:38:33 GMT
From: kent@wrs.com (Kent Long)
Organization: Wind River Systems, Inc. Alameda, CA
Message-ID: <1992Apr22.003833.363@wrs.com>
References: <21325@hacgate.UUCP>
Sender: usenet@wrs.com (News Manager)

Hi, Folks -

In article <21325@hacgate.UUCP> hayes@ddemo3.aero.org (Brian Hayes) writes:
>
>We recently encountered this problem:  
>
>	Undefined symbol _mathInit.
>
>One of our programmers used the mathInit function in his code.  But, 
>why do we get this error?  According to the documentation, the linker
>is suppose to load the math library.
>
>Using 5.0.1 (Sun) with GNU Toolkit 1.37.1.  Crosscompiling to TI 147 
>platform.

The problem here is that the hardcopy documentation is not quite 
up-to-date with the latest releases.

The mathInit() function Brian mentions was used in VxWorks 5.0 and 
earlier releases to include and initialize the interface library which 
supports the 68881/68882 math coprocessor.

When we changed from using the Sun native compiler for the 68k to
the Gnu tools (beginning with VxWorks 5.0.1), it was necessary to 
include floating point emulation routines in addition to this hardware
library.  To avoid confusion, the old "mathLib" was renamed to
"mathHardLib," and the emulation library was named "mathSoftLib."
As a result, the mathInit() function was renamed to mathHardInit().

However, it is usually not necessary to call this routine from your
application code.  If you are using the standard VxWorks configuration
file, configAll.h, you simply define INCLUDE_MC68881 if the hardware you
are using has a math coprocessor (68881 or 68882).  The mathHardInit() 
function will then be called automatically when the system is initialized 
(in usrConfig.c).

The use of INCLUDE_MC68881 remained the same during the change from VxWorks 
5.0 to the later Gnu tools releases.  So, the renaming of mathInit() to 
mathHardInit() is usually not an issue.

To summarize, the mathInit() call is probably not required in your 
application code, since mathHardInit() should already be getting called 
when the system comes up.

I suspect that Brian's co-worker simply read the description of mathInit()
in the VxWorks Reference Manual and (rightly) decided that it was
appropriate.  This is an unfortunate effect of having only one manual
for the various 5.0[.x] releases.  In reality there are only a handful 
of differences; Brian just happened to get caught by one of them.

I hope this clears up the confusion.

Bye for now,

   Kent Long
   Wind River Systems
   kent@wrs.com

---------------------------

End of New-News digest
**********************

From jsnow@moons.sim.es.com  Wed Apr 22 08:38:29 1992
From: jsnow@moons.sim.es.com (John Snow)
Date: Wed Apr 22 08:38:38 PDT 1992
Subject: gcc compiler and 68040
We have identified an instruction sequence generated by the gcc
compiler when generating code targeted for the 68K family which runs
very slowly on the 68040.

When run with the optimize switch (maybe without it, but we've only
seen it happen with the optimizer on), the gcc compiler will generate
fmovecr instructions to move floating point constants from the 68881/2
constant ROM to floating point registers if the constant is available
in ROM. This is faster on the 68881/2 than doing a move of immediate
data to the floating point register. However, the 68040 FPU has no
constant ROM and a fmovecr instruction generates a trap to software
emulation which runs very slowly. With the 68040, it is far faster to
generate the immediate data move instruction which doesn't trap.

I generated a 68040 specific version of gcc which doesn't generate the
fmovecr instruction. It's quite easy to do. There is a function called
standard_68881_constant_p() in the file out-m68k.c which is called to
determine if a constant is available in the 68881 constant ROM. If
this function returns 0, the constant is not available in the ROM and
a fmovecr instruction will not be generated. If you hack this function
to always return 0, you won't get any fmovecr instructions.

Obviously, the real fix should be to add a -m switch indicating that
the target was a 68040 and that fmovecr instructions shouldn't be
issued. However, I didn't want to spend much time trying to figure out
gcc's switch mechanism. Maybe someone (WRS?  Cygnus?) out there will
do it.

-----------------------------------------------------------------------------
John F. Snow                         INET:           jsnow@moons.sim.es.com
Evans & Sutherland Computer Corp.    
Salt Lake City, Utah

From jody@rti.com  Wed Apr 22 23:15:14 1992
From: jody@rti.com (Jody G. Blank)
Date: Wed Apr 22 23:15:22 PDT 1992
Subject: RTI releases version 4.0 of StethoScope

*****************************************************************************
			Product Announcement
*****************************************************************************

            VERSION 4.0 OF STETHOSCOPE FOR VXWORKS RELEASED.

Real-Time Innovations, Inc. is pleased to announce that Version 4.0 of
StethoScope is now ready for customer shipment.

StethoScope is a real-time graphical monitoring and data collection tool.
StethoScope collects data from your program in real-time, buffers it, and
transmits it to your workstation for full-color graphical display.  The data
can then be saved, printed, or exported to analysis packages such as MATLAB and
MatrixX++.

StethoScope version 4.0 includes many new or enhanced features, including a
real-time execution profiler.

*****************************************************************************
SUMMARY OF MAJOR NEW FEATURES:

 * Pan and zoom - Focus on a specific region of a graphical display.

 * On-screen measurements - Measure the coordinates of any point or differences 
     between points.

 * Multiple buffers - Save many individual sets of collected data while you
     continue to collect more.  Re-load buffers from disk for further analysis.

 * X vs Y plot mode - Plot with respect to any signal, rather than just
     plotting time histories.

 * Presentation-quality PostScript output.

 * Derived signals - Create signals from combinations of other signals.

 * Much expanded on-line help and man pages - Become an expert user easily!

 * Repetitive store-to-disk - Automatically save data sets to disk.

 * Execution profiling - Monitor the execution flow of VxWorks programs on a
     procedure-by-procedure basis, and analyze exactly how a VxWorks program is
     utilizing the processor.

*****************************************************************************
AVAILABILITY:

StethoScope 4.0 is available immediately for the following environments:
    Host architecture:          Sun3 or Sun4
    SunOS:                      4.1 or better
    Windowing systems:          X11 or OpenWindows
    VxWorks targets:            680X0 or SPARC

The ScopeProfile execution profiler module is only available for 680x0 targets
at this time.

*****************************************************************************
FOR FURTHER INFORMATION:

StethoScope is a tool you won't know how to live without!  To get more
information, contact your sales representative:

In the United States and Canada:

     Wind River Systems
     ==== ===== =======
     Phone: (800) 545-WIND  [800 545-9463]
     Fax:   (510) 814-2011
     email:  sales@wrs.com

In Europe:

     Wind River Systems EC
     ==== ===== ======= ==
     Phone: 33.1.69.07.78.78
     Fax:   33.1.69.07.08.26
     email:  sales@wrsec.fr  

In Japan, Korea, and Taiwan:

     ASR Corporation
     === ===========
     Phone: 3-3502-5573
     Fax:   3-3502-5570

You may also contact your local WRS sales representative.

*****************************************************************************
++ MATLAB is a trademark of The MathWorks, Inc.  
   MatrixX is a trademark of Integrated Systems, Inc.

===============================================================================
=                                           =                                 =
=   Jody G. Blank			    =   email: jody@rti.com	      =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312         =
=   954 Aster, Sunnyvale, CA 94086          =   Fax:   (408) 720-8419         =
=                                           =                                 =
===============================================================================

From daemon@vxw.ee.lbl.gov  Thu Apr 23 04:00:26 1992
From: daemon@vxw.ee.lbl.gov
Date: Thu Apr 23 04:00:33 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Apr 23 04:00:20 PDT 1992

        Subject: Re: accepted method of ld'ing many .o files

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: accepted method of ld'ing many .o files
Date: 22 Apr 92 16:37:12 GMT
From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
Organization: Field Robotics Center, CMU
Message-ID: <HMP.92Apr22113712@squash.frc.ri.cmu.edu>
References: <RG.92Apr17081413@nymph.msel.unh.edu> <1992Apr21.010301.4244@elroy.jpl.nasa.gov>
Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)

In article <1992Apr21.010301.4244@elroy.jpl.nasa.gov> litwin@litwin.jpl.nasa.gov (Todd Litwin) writes:

>We use the Unix ld command. When I create a Unix program, I usually use cc
>to invoke ld by doing something like:

	   cc -o progname prog1.o prog2.o prog3.o ...

>To build the corresponding file for VxWorks, I do:

	   ld -r -o progname prog1.o prog2.o prog3.o ...

>Note the the "-r" is necessary to keep the output in relocatable object format.
>You can combine any number of object files in this way into a single file
>for downloading. Not only is downloading time greatly decreased, but you
>no longer need to worry about the order of downloading the modules. In fact,
>this method is the only way to deal with two different object files that make
>references to functions in each other.

I agree and use the same method. I'd just add that this way also
avoids a problem that can happen during the development cycle of
several modules: suppose you initially download modules A and B, then
recompile B and download it again. If module A references anything out
of B, it will still be using the *original* version, not the recompiled
one. This is usually not what you want.

- -Henning

- --
Henning Pangels    |hmp@frc2.frc.ri.cmu.edu        |     Field Robotics Center
Research Programmer|(412) 268-7088                 |Carnegie-Mellon University
- ------------------------------------------------------------------------------
      I know it's a non sequitur, but what does that have to do with it ?

---------------------------

End of New-News digest
**********************

From Enterprise!arete.com!reder@uu.psi.com  Thu Apr 23 13:49:37 1992
From: reder@arete.com (Leonard J. Reder)
Date: Thu Apr 23 13:49:48 PDT 1992
Subject: Re: RTI releases version 4.0 of StethoScope
> Submitted-by jody@rti.com  Wed Apr 22 23:15:14 1992
> Submitted-by: jody@rti.com (Jody G. Blank)
>  
> 
> 
> *****************************************************************************
> 			Product Announcement
> *****************************************************************************
> 
>             VERSION 4.0 OF STETHOSCOPE FOR VXWORKS RELEASED.
> 
Why is it that the price of these things is never given?
How much does this product cost?

From briggs@thalia.jpl.nasa.gov  Thu Apr 23 16:47:57 1992
From: briggs@thalia.jpl.nasa.gov (Clark Briggs)
Date: Thu Apr 23 16:48:12 PDT 1992
Subject: gcc compiler and 68040
John Snow pointed out how to get gcc to stop using fmovecr which generate
traps on the 68040.  His fix is quite nice but I agree with closing request
for someone to add specific capabilities to gcc for the 68040.  WRS included
the software lib to makeup for the missing fpu functions such as cos & sin.
Like fmovecr, there are several other simple functions that must be trapped to
this soft lib but could be avoided if gcc were modified to take advance of
68040 specific opcodes.  The ones that really make me crazy are the data
conversion from/to ints,floats, & doubles.  Prior architectures had lots of
op codes to the permutations, but the 040 only has one or a few.

Like John, I would like someone to change gcc to do these few things that are
in appropriate to do with soft libs.  I was told by my support engineer that
given the speed of the 040, these traps are no slower than the 030 in total
execution time. Ok so I'm not being killed by the situation, but I'm also
not getting the speed enhancement I paid for.  The seriousness of this clearly
depends on the number of times the soft lib is used, and I've been content
to date because this is not a big hit on my application performance.  Now it
looks like there are several simple things that could be improved by a 
knowledgable someone.  

Please upgrade gcc to incorporate these 040 peculiar features.

Clark Briggs				briggs@csi.jpl.nasa.gov
Jet Propulsion Laboratory
Pasadena, CA

From visicom!VisiCom.COM!trest@nosc.mil  Thu Apr 23 17:14:02 1992
From: Mike Trest <trest@visicom.com>
Date: Thu Apr 23 17:14:10 PDT 1992
Subject: Re: RTI releases version 4.0 of StethoScope

>> reder@arete.com (Leonard J. Reder)

>>Why is it that the price of these things is never given?
>>How much does this product cost?

I also would not mind seeing price stuff here.  However, several
years of network experience in a public formum like this have shown
that detail pricing data for a product with a lot of options is
hard to communicate correctly.   It is hard for the vendor because
they do not want to miss a sale for a lignt weight version of 
something by blasting a prospect with the heavy weight maximum
price version.  It is also a waste of time for those who do
not care.

As a seller of products and services in the VxWorks community,
VisiCom is sensitive to many network users who do not appreciate
the clutter of commercial literature on the public net.

In reality, the network is sustained by us users to foster exchange 
of technical ideas among a group of developers who use VxWorks. 
I truly appreciate the work involved and the community service
it renders.

Therefore, VisiCom does not announce product except in response
to specifc inquiry on the network.  We do send price data to the
exploder.  However, we use the EMAIL address of an individual and
will include price data since it is simple.

On the other hand, availability of products (Free/Share/Commercial)
is important to me as a technical developer.  Therefore I really
do want to see announcements.  So my personal desire for announcements
is greater than VisiCom's corporate position.

====================================================================
For those who may care to know about VisiCom Laboratories 
====================================================================

VisiCom Laboratories

	(1) sells turn-key products for Mil-ON-143(v)6/7/11,
	    UYK-20, UYK-44, and UYK-7 computer replacement
	(2) resells VxWorks 
        (3) specialty shop for VxWorks BSPs, Device Drivers
            for the OEM market or for custom board builders
	(4) application developer for real time
	(5) custom embedded hardware design/prototype house
            (especially if they need VxWorks real time kernels)

Collectively these activities are in the $10M revenue range.  We
have approximately 100 employees and more than 40 software developers
who work with VxWorks every day.  I would like to receive EMAIL with 
announcements of any products which anyone in the exploder community 
may think useful to someone like me or my company.

..mike..

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 457 2111
Technology Group                Fax:   619 457 0888
VisiCom Laboratories            San Diego, CA 
====================================================

From stan@rti.com  Thu Apr 23 20:27:57 1992
From: stan@rti.com (Stan Schneider)
Date: Thu Apr 23 20:28:04 PDT 1992
Subject: Re: RTI releases version 4.0 of StethoScope
>> >             VERSION 4.0 OF STETHOSCOPE FOR VXWORKS RELEASED.
>> > 
>> Why is it that the price of these things is never given?
>> How much does this product cost?
>> 

Sorry.  Our understanding was that net etiquette frowns on publishing prices.
Besides, a variety of licenses are available; pricing structures are not always
that simple to relate in a short email message.

We will send you a complete price list immediately.

        -- Stan

===============================================================================
=                                           =                                 =
=   Stan Schneider                          =   email: stan@rti.com           =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312         =
=   954 Aster, Sunnyvale, CA 94086          =   Fax:   (408) 720-8419         =
=                                           =                                 =
===============================================================================

From daemon@vxw.ee.lbl.gov  Fri Apr 24 04:00:24 1992
From: daemon@vxw.ee.lbl.gov
Date: Fri Apr 24 04:00:32 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Apr 24 04:00:17 PDT 1992

        Subject: X11 for VxWorks 5.0.3?
        Subject: GNU C and Sun's ld.so
        Subject: SCSI from multiple CPUs

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: X11 for VxWorks 5.0.3?
Date: 22 Apr 92 16:54:35 GMT
From: sharpster@hns.com (Stephen Harpster)
Organization: Hughes Network Systems
Keywords: X11, VxWorks
Message-ID: <1992Apr22.165435.26475@hns.com>
Sender: news@hns.com (USENET news system)

I looked at the X11 libraries in the VxWorks Software Archive only to
find that they are the R3 libraries for VxWorks 4.x. :-(  The work in
going from 4.x to 5.0.3 looks like it would be some doing.  Does anyone
have a 5.0.3 version, preferably X11R4?

---------------------------

Newsgroups: comp.os.vxworks
Subject: GNU C and Sun's ld.so
Date: 23 Apr 92 20:17:28 GMT
From: junel@bilbo.heurikon.com (June Liesch)
Organization: Heurikon Corporation, Madison, WI
Message-ID: <1431@heurikon.heurikon.com>
Reply-To: junel@heurikon.heurikon.com (June Liesch)
Sender: news@heurikon.heurikon.com

I have a customer with an HK68/V30XE running vxWorks 5.0.1 and a Sun 3/60
running 4.0.3_EXPORT. This customer is trying to compile ~vw/demo/1/demo.c
with the GNU C compiler, version 1.37.1.  I believe he has his environmental
variables set up properly. He compiles as follows:

cc68k -v -traditional -O -c -I/home/vw/h demo.c

and gets the error:

ld.so: warning: /usr/lib/libc.so.0.12 has older revision than expected 14
ld.so: call to undefined procedure _tolower from 0x20116

From what little I know about ld.so, I would guess this is a Sun problem,
although it appears he doesn't have problems other than compiling with GNU.
Has anyone seen this problem before? Does anyone know what to do about it?
Should I have him upgrade his SunOS?

Thanks,
June

- --------------------------------------------------------------------------------
June Liesch                |  "I don't think much of our profession, but con-
Software Customer Support  |  trasted with respectability, it's comparatively
Heurikon Corporation       |  honest."  - The Pirate King, from G&S's
junel@heurikon.com         |              "The Pirates of Penzance" 
- --------------------------------------------------------------------------------

---------------------------

Newsgroups: comp.os.vxworks
Subject: SCSI from multiple CPUs
Date: 24 Apr 92 02:56:57 GMT
From: flash@austin.lockheed.com (James W. Melton)
Organization: "Lockheed Austin Division, 6800 Burleson Rd, Austin, TX 78744
Keywords: SCSI, disk
Message-ID: <933@shrike.com>

To the vxWorks community:

I have a problem which, based on recent discussions in this newsgroup,
is not unique to me. I also expect it to become much more common in
the future.

I have a hardware suite consisting of multiple CPUs on a backplane
with a separate SCSI controller, attached to a hard disk. I would
like to have access, from any CPU, to the disk. I believe the controller
supports multiple hosts talking to it, but my concern is how vxWorks
would manage a filesystem accessed by several hosts.

There are really two issues here. The first is support for off-board
SCSI. My sales rep tells me that there is at least one SCSI board with
vxWorks support. Mine is not one of them; but porting/writing a device
driver is a fairly well bounded problem (if anyone has one they would
like to give me... :-) ).

The second, and more difficult problem is ensuring consistency of a
filesystem accessed from multiple hosts. This problem can be demonstrated
apart from the SCSI issue. Create a RAM disk in VME address space.
Make a filesystem on it. Create the same RAM disk on another CPU.
Initialize the filesystem to that CPU. What will happen? I am almost
positive that vxWorks will not support this configuration.

At issue is whether periphals (or even RAM disks) are resources for
the entire VME system, or only for one arbitralily selected CPU. While
only supporting on-board SCSI skirts the issue (the periphal is directly
connected to a CPU, so yes it is dedicated), the real-time world begs
for a more open solution.

Of course, one solution is server NFS support in vxWorks ;-)

I am interested in the discussion this will (hopefully) stimulate.
If anyone has any experience in this area, please email me.
- ----
Jim Melton  flash@austin.lockheed.com
in person:  (512) 386-4303            | "So far as we know, our
voice mail: (512) 386-4486            |  computer has never had
fax:        (512) 386-4223            |  an undetected error"

---------------------------

End of New-News digest
**********************

From biocca@bevsun.bev.lbl.gov  Fri Apr 24 08:45:14 1992
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Date: Fri Apr 24 08:45:45 PDT 1992
Subject: Re: Exploder - Newsgroup connection
In answer to a question regarding the exploder and the newsgroup:

The VxWorks Users Group Exploder:

The exploder is an email redistribution engine.  It preceded the newsgroup
and offers two kinds of service -- immediate and daily.  The immediate service
resends each article as soon as it arrives and compiles a digest that goes
to the daily list early the next morning.  Users can subscribe to either the
daily service, or the immediate service, or both.

Cross Coupling with comp.os.vxworks:

Articles from the exploder are spooled as they come in and a periodic daemon
posts them to comp.os.vxworks.  Articles from comp.os.vxworks are gathered
daily and filtered to remove posts from the exploder, compiled into a digest,
and emailed to immediate exploder users early in the morning as well as being
included into the regular digest targeted for digest users.

Theoretically articles in each medium appear in all other mediums.  Occasionally
the articles are rejected by the news system.  If I don't take action these
articles will be lost in five days or so.  I've set up a cron job to show me
these stuck posts, so I should be able to fix their problems.

Alan K Biocca
Exploder Maintainer
AKBiocca@lbl.gov

From visicom!VisiCom.COM!trest@nosc.mil  Fri Apr 24 09:14:26 1992
From: Mike Trest <trest@visicom.com>
Date: Fri Apr 24 09:14:34 PDT 1992
Subject: Re:  comp.os.vxworks newsdigest
>>From: sharpster@hns.com (Stephen Harpster)
>>Organization: Hughes Network Systems

>>I looked at the X11 libraries in the VxWorks Software Archive only to
>>find that they are the R3 libraries for VxWorks 4.x. :-(  The work in
>>going from 4.x to 5.0.3 looks like it would be some doing.  Does anyone
>>have a 5.0.3 version, preferably X11R4?

VisiCom Laboratories has X11R4 (client, server, and all MIT libraries,
and clients) and MOTIF 1.1 (mwm, all libraries, most clients) running
with VxWorks 5.0.x.  WRS WindX is also X11R4 (client and libraries).

Both are commercial products rather than ARCHIVE contributions.  
VisiCom Laboratories recommends and sells both products.  To use
VX-SERVER you need a hardware vidio card, either smart-card or
dumb-frame-buffer.  However, all X clients may talk to network
displays.  We have done applications for in which a MOTIF
based local interface was also capable of using multiple remote
control windows on network workstations (All clients on VxWorks
with a small workstation requestor task).  We have even done
a TOUCH SCREEN ONLY version of X-server and simulated KEYBOARD,
MOUSE, and BUTTONS on the screen.

For more details please contact me.

..mike..

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 457 2111
Technology Group                Fax:   619 457 0888
VisiCom Laboratories            San Diego, CA 
====================================================

From visicom!VisiCom.COM!trest@nosc.mil  Fri Apr 24 10:18:02 1992
From: Mike Trest <trest@visicom.com>
Date: Fri Apr 24 10:18:09 PDT 1992
Subject: Re:  comp.os.vxworks newsdigest
>>Subject: SCSI from multiple CPUs
>>From: flash@austin.lockheed.com (James W. Melton)

>>I have a hardware suite consisting of multiple CPUs on a backplane
>>with a separate SCSI controller, attached to a hard disk.

Alas, one of my favorite applications of scsi and VxWorks!

>>There are really two issues here. The first is support for off-board
>>SCSI. My sales rep tells me that there is at least one SCSI board with
>>vxWorks support. Mine is not one of them; but porting/writing a device
>>driver is a fairly well bounded problem (if anyone has one they would
>>like to give me... :-) ).

Another problem, neither WRS or my company allows us to give away the
store.  Privately, I have been thinking about posting a generic
SCSI block driver which interfaces to scsiLib (mabey some weekend
when I feel energetic).

>>At issue is whether periphals (or even RAM disks) are resources for
>>the entire VME system, or only for one arbitralily selected CPU. While
>>only supporting on-board SCSI skirts the issue (the periphal is directly
>>connected to a CPU, so yes it is dedicated), the real-time world begs
>>for a more open solution.

There is a more fundamental description of the problem in the real-time 
market place.  We are doing custom hardware with embedded VxWorks
where there are 7 processors on a single processor board (VME/9U)
which is designed to talk via backplane to 7 other boards.  With 56
processors all needing a piece of the SCSI disk pool the concerns
which you expressed are obviously multiplied.

Regardless of 1 or N, in the present VxWorks technology we must
either: 

	(1) Create a server or Pseudo-Server 
	(2) Allow Writing by only one CPU
	(3) Come up with a new file system
	(4) Encourage WRS in multi-processor architectural improvements

Creating a server or pseudo-server, means using IPC facilities between
processors to pass operations against file handles between the processors.
Such a scheme is actually rather simple to implement, but the problem
is that each file opened on one processor must have a matching file
opened on the processor actually running dosFs.  There are also
performance concerns which with any single CPU server (unless you have
the ability to dedicate a processor to this functionality).
 
Writing by only one CPU has been my most frequent solution.  If your
application is such that only one CPU is creating new files and updating
FATs, then all of the additional processors with their own copies
of dosFs will be quite happy.  However, you will, from time to time
have to cause the read-only CPUs to refresh their directory from time 
to time to discover the newly created files.

A new file system is not out of the question.  An associate here at
VisiCom has written a BSD-compatible file system.  I am trying to
convince her to let me bring it up to dosFs and rawFs VxWorks interface
standards.  But that takes time (and budget).

If we users will encourage WRS in multi-processor architectural 
improvements, perhaps we will see a natural solution to the
dosFs problem in a fully distributed VxWorks model.  In this approach
all processors in a cluster divide execution of system functions,
like file systems, in a reasonably seamless manner.  WRS is asking 
at user's group meetings "What do you want to see in the future?".  
Perhaps if we continue our suggestions, they will assign a budget and
make it happen.

..mike..

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 457 2111
Technology Group                Fax:   619 457 0888
VisiCom Laboratories            San Diego, CA 
====================================================

From comtec!orincon!robert@ucsd.edu  Fri Apr 24 12:30:48 1992
From: comtec!orincon!robert@ucsd.edu (Robert Redfield)
Date: Fri Apr 24 12:30:55 PDT 1992
Subject: Re:  RTI releases version 4.0 of StethoScope
I'm very interested in StethoScope. Unfortunately we run VxWorks on an i960 machine (Heurikon V960E). Put me on a mailing list or whatever so that I know when your product is available for me.

Thanks.
Robert Redfield
ORINCON Corp.
(619) 455-5530 x252

From daemon@vxw.ee.lbl.gov  Sat Apr 25 04:00:25 1992
From: daemon@vxw.ee.lbl.gov
Date: Sat Apr 25 04:00:33 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Apr 25 04:00:19 PDT 1992

        Subject: VxWorks 5.0.x and ifMaskSet() byte order
        Subject: FDDI
        Subject: How do you get task id when using taskInit()/taskActivate()?

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: VxWorks 5.0.x and ifMaskSet() byte order
Date: 23 Apr 92 14:00:32 GMT
From: rypma@hppad.waterloo.hp.com (Ted Rypma)
Organization: HP Panacom Div Waterloo ON Canada
Message-ID: <27550008@hppad.waterloo.hp.com>

It seems that one must be on the lookout for queer things when going from
VxWorks 4.0.2 to 5.0.x.

I made all the changes made necessary by header file changes and ANSI prototype 
definitions that were incompatible with current usage - not a pleasant job, I
might add.  Then I linked everything together and found that the network code
stopped working soon after downloading our code and starting it.

The eventual cause was a change in the byte order of the network mask parameter
to ifMaskSet().

Seems Wind River changed the required order from network to host without
warning us (at least I didn't see any reference to a change anywhere).
ifMaskSet() now does an htonl() before passing the mask to a socket ioctl.
Whether the previous behavior was correct or incorrect doesn't matter in the
least - it's the unannounced change that caused the grief.

All this occurred with the Heurikon hkv960 BSP - although the library causing
the problem would be the same for any BSP, I suppose.  There would be no
apparent effect on 68K based systems as network == host order.

Ted Rypma
HP Panacom Division

---------------------------

Newsgroups: comp.os.vxworks
Subject: FDDI
Date: 24 Apr 92 19:12:54 GMT
From: singer@ll.mit.edu (Matthew R. Singer)
Organization: MIT Lincoln Laboratory
Message-ID: <1992Apr24.191254.10270@ll.mit.edu>
Reply-To: singer@ll.mit.edu (Matthew R. Singer)
Sender: singer@ll.mit.edu (Matthew R. Singer)

- -
Anyone have a list (are there more than one) of FDDI vendors with VxWorks
support?

Thanks
 
- -----------------------------------------------------------------------------
Matthew R. Singer                                    MIT Lincoln Laboratory
(617) 981-3771                                       244 Wood Street
singer@ll.mit.edu                                    Lexington, MA 02173
- -----------------------------------------------------------------------------

---------------------------

Newsgroups: comp.os.vxworks
Subject: How do you get task id when using taskInit()/taskActivate()?
Date: 23 Apr 92 15:42:19 GMT
From: sharpster@hns.com (Stephen Harpster)
Organization: Hughes Network Systems
Message-ID: <1992Apr23.154219.18000@hns.com>
Sender: news@hns.com (USENET news system)

Okay, I give.  How do you get the task id when using taskInit()/taskActivate()?
Unlike taskSpawn(), taskInit() does not return the task id.  Instead it
returns OK or ERROR.

Now taskActivate() expects a task id in order to activate the task.
The only way I can see to get the task id is to name the task in taskInit()
and then 

	taskActivate(taskNameToId(name));

but this seems pretty silly.

Am I missing something??

P.S. I'm using Vx960 5.0.3.

---------------------------

End of New-News digest
**********************

From iphasew!hwajin@apple.com  Sat Apr 25 13:36:15 1992
From: hwajin@iphasew.com (Hwa-Jin Bae)
Date: Sat Apr 25 13:36:21 PDT 1992
Subject: Re: VxWorks 5.0.x and ifMaskSet() byte order
Ted Rypma justly points out...

Ted> Seems Wind River changed the required order from network to host
Ted> without warning us (at least I didn't see any reference to a
Ted> change anywhere).  ifMaskSet() now does an htonl() before passing
Ted> the mask to a socket ioctl.  Whether the previous behavior was
Ted> correct or incorrect doesn't matter in the least - it's the
Ted> unannounced change that caused the grief.

Last time I checked ifMaskSet() did not do any conversion (this was in
beta 5.0).  If ifMaskSet() indeed has been changed to do htonl(), this
is inconsistent with the rest of network code in VxWorks as well as
original UNIX "ifconfig" convention.  The reason is that the users may
want to do things like,

-> ifMaskSet("ln0", inet_addr("255.255.255.0"))

This is essentially functionally equivalent of what UNIX ifconfig
would do internally.  Since inet_addr() returns Internet address in
network order, doing htonl() inside ifMaskSet() would result in
incorrect value for the mask.  The confusion is partly due to
inconsitent function call interface provided by ifMaskSet(), which
requires an "int" whereas other "if" routines such as ifAddrSet(),
ifBroadcastSet(), etc.  require "char *" for the Internet address
argument.  The network mask is used in network order, and should have
been passed around as such.  I didn't think changing ifMaskSet() was a
good idea (although it would be more consistent with other "if"
routines) for historial reasons at the time.  Sigh...

~Hwajin

From iphasew!hwajin@apple.com  Sat Apr 25 15:31:52 1992
From: hwajin@iphasew.com (Hwa-Jin Bae)
Date: Sat Apr 25 15:31:58 PDT 1992
Subject: Re:  do you get task id when using taskInit()/taskActivate()?
The first arg to taskInit() (address of new task's TCB) can be used
as task id.

--
Hwa-Jin Bae
Interphase West
Santa Clara, CA

From cruise@cfht.hawaii.edu  Sat Apr 25 21:57:37 1992
From: Bill Cruise <cruise@cfht.hawaii.edu>
Date: Sat Apr 25 21:57:45 PDT 1992
Subject: Sparc 1e boot ROM's

I have 4 SparcEngine 1e boards -- 2 old, and 2 new.  

The old ones came with 2 boot ROM's from Sun.  I put the 2 vxWorks
boot ROM's on, and everything works quite well, version 4 or 5.

The new ones come with only 1 boot ROM from Sun, but there are still
two sockets, and everything else looks the same.  I received no
documentation with the boards.  I put the vxWorks ROM's on (version 4
only, so far) and nothing happens.  The boards appear to stay locked
up, and nothing appears on the console.

Am I, as I suspect, missing something very fundamental?  Or, is there
some trick that I haven't come across yet -- I'd feel better about that.
Of course I can't find anything in the vxWorks docs.

Any help will be gratefully appreciated.

Bill Cruise
Canada-France-Hawaii Telescope

From marc@sun-valley.stanford.edu  Sun Apr 26 01:25:33 1992
From: marc@sun-valley.stanford.edu (Marc Ullman)
Date: Sun Apr 26 01:25:41 PDT 1992
Subject: Re: Sparc 1e boot ROM's 

>Submitted-by cruise@cfht.hawaii.edu  Sat Apr 25 21:57:37 1992
>Submitted-by: Bill Cruise <cruise@cfht.hawaii.edu>
>Am I, as I suspect, missing something very fundamental?  Or, is there
>some trick that I haven't come across yet -- I'd feel better about that.
>Of course I can't find anything in the vxWorks docs.
>
>Any help will be gratefully appreciated.

I have never actually used one of the new Sparc boards, but noting that
you're working on this late on a Sat. evening, I figured I'd toss in my
2 cents.  My guess would be that Sun switched to a larger size EPROM
and that there is probably a little address jumper somewhere that configures
the board for one or two EPROMS.  Another possibility is that they were
using a 16 bit path to ROM and, in as much as you say it only came with
one),  are now using only an 8 bit path.  This could again require the
changing of a jumper or more radically, that you re program your prom in
an 8 bit wide fashion (e.g. no more odd/even).

Hope that helps,

--Marc Ullman
  Stanford University

From daemon@vxw.ee.lbl.gov  Sun Apr 26 04:00:24 1992
From: daemon@vxw.ee.lbl.gov
Date: Sun Apr 26 04:00:31 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Apr 26 04:00:18 PDT 1992

        Subject: Re: distributed vxWorks!

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: distributed vxWorks!
Date: 26 Apr 92 03:29:23 GMT
From: flash@austin.lockheed.com (James W. Melton)
Organization: "Lockheed Austin Division, 6800 Burleson Rd, Austin, TX 78744
Message-ID: <937@shrike.com>
References: <9204241512.AA22749@dtc163.VisiCom.COM>

In article <9204241512.AA22749@dtc163.VisiCom.COM> trest@visicom.com (Mike Trest) writes:
|>>Subject: SCSI from multiple CPUs
|>>From: flash@austin.lockheed.com (James W. Melton)
|
|>>I have a hardware suite consisting of multiple CPUs on a backplane
|>>with a separate SCSI controller, attached to a hard disk.
|
|Alas, one of my favorite applications of scsi and VxWorks!
|
|>>At issue is whether periphals (or even RAM disks) are resources for
|>>the entire VME system, or only for one arbitralily selected CPU. While
|>>only supporting on-board SCSI skirts the issue (the periphal is directly
|>>connected to a CPU, so yes it is dedicated), the real-time world begs
|>>for a more open solution.
|
|There is a more fundamental description of the problem in the real-time 
|market place.  We are doing custom hardware with embedded VxWorks
|where there are 7 processors on a single processor board (VME/9U)
|which is designed to talk via backplane to 7 other boards.  With 56
|processors all needing a piece of the SCSI disk pool the concerns
|which you expressed are obviously multiplied.
|
|Regardless of 1 or N, in the present VxWorks technology we must
|either: 
|
|	(1) Create a server or Pseudo-Server 
|	(2) Allow Writing by only one CPU
|	(3) Come up with a new file system
|	(4) Encourage WRS in multi-processor architectural improvements
|
|If we users will encourage WRS in multi-processor architectural 
|improvements, perhaps we will see a natural solution to the
|dosFs problem in a fully distributed VxWorks model.  In this approach
|all processors in a cluster divide execution of system functions,
|like file systems, in a reasonably seamless manner.  WRS is asking 
|at user's group meetings "What do you want to see in the future?".  
|Perhaps if we continue our suggestions, they will assign a budget and
|make it happen.

Wind River, if you are listening, my vote is for a truly distributed
real-time kernel. For now, it doesn't even have to be symmetric. In
the future we will all be doing more applications with multiple
processors (whether on the same card or merely on the same backplane).
In many respects, my current system (SCSI problem aside) would be
much simpler if the kernel could know about everything happening
inside the chassis, instead of having to carefully partition functions
to discrete processors and coordinate between autonomous kernels.

Case in point. (Disclaimer. The hardware was chosen before the software
was designed. It happens.) My application needs access to several
serial lines. The system contains an Ironics board with 16 serial lines.
Unfortunately, this is a _smart_ board, with a 68EC030 processor
running a vxWorks kernel. Current technology requires

	A. Write some sort of IPC interface to treat this card as
	   a "dumb" serial card and make it accessible the processor
	   pool.
	B. Isolate all parts of the application which require access
	   to serial lines and host them on the Ironics card.

A distributed vxWorks would allow features of all cards in the chassis
to be available to any processor. A symmetric vxWorks would not require
the a priori allocation of tasks to processors (of course, some
allowance must be made for software compiled for different processors)

Now that you've stimulated my wishful thinking...
- ---
Jim Melton, novice guru
in person:  (512) 386-4303            | "So far as we know, our
voice mail: (512) 386-4486            |  computer has never had
fax:        (512) 386-4223            |  an undetected error"
e-mail:     flash@austin.lockheed.com |

---------------------------

End of New-News digest
**********************

From rayssd!pike.ssd.ray.com!fjr@uunet.uu.net  Sun Apr 26 18:49:55 1992
From: "Roeber" <fjr@pike.ssd.ray.com>
Date: Sun Apr 26 18:50:02 PDT 1992
Subject: Re:  distributed vxWorks
>  
>  In article <9204241512.AA22749@dtc163.VisiCom.COM> trest@visicom.com (Mike Trest) writes:
>  |If we users will encourage WRS in multi-processor architectural 
>  |improvements, perhaps we will see a natural solution to the
>  |dosFs problem in a fully distributed VxWorks model.  In this approach
>  |all processors in a cluster divide execution of system functions,
>  |like file systems, in a reasonably seamless manner.  WRS is asking 
>  |at user's group meetings "What do you want to see in the future?".  
>  |Perhaps if we continue our suggestions, they will assign a budget and
>  |make it happen.
>  
>  
>  Wind River, if you are listening, my vote is for a truly distributed
>  real-time kernel. For now, it doesn't even have to be symmetric. In
>  the future we will all be doing more applications with multiple
>  processors (whether on the same card or merely on the same backplane).
>  In many respects, my current system (SCSI problem aside) would be
>  much simpler if the kernel could know about everything happening
>  inside the chassis, instead of having to carefully partition functions
>  to discrete processors and coordinate between autonomous kernels.

I beg to differ on the desire for trying to make VxWorks support symmetric
multiprocessing.  We are enhancing VxWorks to support a form of
multiprocessing that I'll call "snuggly coupled multiprocessing" to borrow
a term I first saw in Lynx OS literature.  This is a very restricted subset
of what would be required to really have standard multiprocessing.  Even so,
we are trading off some performance to make things work.  One of the main
points behind VxWorks is that it is fast.  If one really wanted multiprocessing
(and therefor things like virtual memory management that are almost certainly
required to support it) then one could always get something like Lynx OS.
We didn't do that because we couldn't stand to have things be a lot larger
and a lot slower than they are under VxWorks.  If WRS tries to go that way
things will definitely run slower.  Is that what everyone wants?

One of the biggest issues with multiprocessing is handling the fact that
shared data may be cached across multiple processors.  Since the VME bus
doesn't support the notion of cache coherency, getting this sort of shared
data to work involves tricky cache manipulation on every processor or requires
turning the cache off.  At the last East Coast user group meeting I asked a
question about this and got the impression that most people ran with cache
disabled for there multiprocessor applications.  On a 68030, this has a
moderate impact (perhaps a 30% performance reduction for data intensive
applications).  The problem is that for a 68040 the impact is much greater
(I have heard that things can run one third the speed).

There are some serious questions with getting multiprocessing to work in any
one particular environment.  To get it to work in the wide range of
heterogenous environments that VxWorks now supports would seem to be an
impossible feat in my mind (at least with any reasonable performance).

Just figured I would throw in my two cents.    Fred

    ______________________________________________________________
   |  Fred J Roeber,  Raytheon Submarine Signal Division          |
   |  1847 West Main Road,  Mail Stop 188                         |
   |  Portsmouth, RI  02871-1087  (401) 847-8000 (X4205)          |
   |                                                              |
   |      {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr             |
   |______________________________________________________________|

From @ada3.ca.boeing.com:crispen@efftoo.boeing.com  Mon Apr 27 05:58:30 1992
From: crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com>
Date: Mon Apr 27 05:58:38 PDT 1992
Subject: Re: distributed vxWorks!
Jim Melton, novice guru writes:

>Wind River, if you are listening, my vote is for a truly distributed
>real-time kernel.

Heck, I'll settle for multi-processor semaphores.  No, wait a minute,
I'll settle for multi-processor semaphores that only work on the most
popular CPU boards.  Or how about MPSs that work on one or two boards....

You know what I'm looking for -- not just a VME test and set, but a
VMETAS that will automatically pend my process and revive it (hell, even
through a VME interrupt).  I'm willing to live with the "only semTake at
task level" rule.

Doesn't SOMEBODY have a hack for this?  I'm willing to accept something
that isn't elegantly integrated with the Wind kernel, so long as it
doesn't actually crash VxWorks (and VADSWorks).

Hey, I know -- WRS can release it on the exploder as a kind of
"dangerous beta" item and get users' reactions to it.  Instead of waiting
for a full-blown elegant release, give us a little bitty tool we can use
to avoid the backplane and sockets.

What do some others think?

Bob Crispen
crispen@foxy.boeing.com

From prb@aplexus.jhuapl.edu  Mon Apr 27 06:00:39 1992
From: prb@aplexus.jhuapl.edu (Paul R. Bade)
Date: Mon Apr 27 06:00:47 PDT 1992
Subject: Re:  distributed vxWorks

Fred Roeber writes:

> One of the biggest issues with multiprocessing is handling the fact that
> shared data may be cached across multiple processors.  Since the VME bus
> doesn't support the notion of cache coherency, getting this sort of shared
> data to work involves tricky cache manipulation on every processor or requires
> turning the cache off.  At the last East Coast user group meeting I asked a
> question about this and got the impression that most people ran with cache
> disabled for there multiprocessor applications.  On a 68030, this has a
> moderate impact (perhaps a 30% performance reduction for data intensive
> applications).  The problem is that for a 68040 the impact is much greater
> (I have heard that things can run one third the speed).
>
>

Perhaps most people run with cache disabled but that can really give
you a big hit in processing power with the 68040.
VxWorks does provide the flexibility such that with a little MMU
work you don't have to turn the cache off.
We are using a MV167 (68040 board) and have specified that
the backplane memory pool be in upper memory
and is mapped as write-thru with bus snooping. 
Caching is definitely significant with TCPIP.
We also have an area in low memory for custom communications
which is cache disabled since we are always either doing one time
copies into/out of this area (no need to be cached) (no bus snooping)
Middle memory is not mapped to the VMEbus (not a shared resource) and can thus
be configured as cacheable copyback.
It may take a little work but it is well worth the trouble;
you may as well get the processing power you paid for in the 68040.

		Paul Bade
		Johns Hopkins University / Applied Physics Lab
		prb@aplexus.jhuapl.edu

From marc@sun-valley.stanford.edu  Mon Apr 27 10:09:56 1992
From: marc@sun-valley.stanford.edu (Marc Ullman)
Date: Mon Apr 27 10:10:03 PDT 1992
Subject: Re: distributed vxWorks 

>
>
>Submitted-by prb@aplexus.jhuapl.edu  Mon Apr 27 06:00:39 1992

>VxWorks does provide the flexibility such that with a little MMU
>work you don't have to turn the cache off.
>We are using a MV167 (68040 board) and have specified that
>the backplane memory pool be in upper memory
>and is mapped as write-thru with bus snooping. 

I think that both WRS and their user community would enjoy seeing the
necessary changes if you'd be will to post them.  We have been concerned
with this same issue (on a speculative level--no 167's in house yet) and
have surmised that what you have just described could be done.  If you're
willing to share it, it would eliminate the need to "re-invent the wheel."

Thanks,

--Marc Ullman
  Stanford University

From ROSS%SCFF.decnet@scfb.nwc.navy.mil  Mon Apr 27 10:52:23 1992
From: "SCFF::ROSS" <ROSS%SCFF.decnet@scfb.nwc.navy.mil>
Date: Mon Apr 27 10:52:31 PDT 1992
Subject: RE: Sparc 1e boot ROM's
We encountered your problem - here's what we found:

1) All new Sparc 1e boards come with the boot ROM daughter board configured
for two 2-megabit EPROMS instead of the two 1-megabit chips of the older
borads. You need to either use a 2-megabit EPROM or modify the daughter
board. We recommed that you burn the vxworks boot ROM file into a 2-megabit
chip.

2) After you get that far, it still won't work - you need to apply a patch
to get the new boards to work. Ask Wind River for the uninitialized variable
fix to kernel init() for the Sparc 1e.

And that should do it!!  RSVP if you have questions!

Pamela Ross
Naval Air Warfare Center - Weapons Division
China Lake, CA

From daemon@vxw.ee.lbl.gov  Tue Apr 28 04:00:27 1992
From: daemon@vxw.ee.lbl.gov
Date: Tue Apr 28 04:00:36 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Apr 28 04:00:20 PDT 1992

        Subject: Re: vme address questions
        Subject: chomped on by a compiler optimization
        Subject: Re: chomped on by a compiler optimization
        Subject: Re: vme address questions
        Subject: Re: Sparc 1e boot ROM's

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: vme address questions
Date: 27 Apr 92 18:47:37 GMT
From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
Organization: Field Robotics Center, CMU
Message-ID: <HMP.92Apr27134737@squash.frc.ri.cmu.edu>
References: <RG.92Apr27104805@nymph.msel.unh.edu>
Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)

In article <RG.92Apr27104805@nymph.msel.unh.edu> rg@msel.unh.edu (Roger Gonzalez) writes:

>How does one specify VME address modifier codes to VxWorks?  For example, if
>I want to access A24 address 0x80200, I guess I would use AMC 0x39, and in
>pSOS I would have tacked this onto the front end of the address, 0x3980200.
>At least I think this is the way I used to do it.  I've been using Sun's mmap
>since I last played with pSOS so I haven't had to think about AMCs for a while.

Typically, the CPU board generates the AM codes based on the
address specified. For example, most Motorola boards generate a short
IO access for addresses above 0xffff0000. Similarly, other AM
codes are generated for other ranges of physical addresses; the manual
usually contains a table with the pertinent info.

>Does the shell grok off board VME addresses?

Absolutely ;-) Actually, it doesn't really know about on- vs.
off-board; the CPU card does. In sysLib.c for your board, check out 
sysLocalToBusAdrs() and sysBusToLocalAdrs() -- that should give you
some insight.

>One big deficiency of the VxWorks shell that I had in pSOS is the ability to
>examine or modify exactly -one- byte of memory at a time.  This is important
>when you are playing with funky hardware where, for example, accessing the odd
>bytes will give you a bus error.

Agreed. I wouldn't be surprised if someone else out there has already
implemented such a function; I'd imagine it would be pretty simple to
modify the m() routine in usrLib.c to access memory as single bytes.

- -Henning

- --
Henning Pangels    |hmp@frc2.frc.ri.cmu.edu        |     Field Robotics Center
Research Programmer|(412) 268-7088                 |Carnegie-Mellon University
- ------------------------------------------------------------------------------
			  The Door is a Jar

---------------------------

Newsgroups: comp.os.vxworks
Subject: chomped on by a compiler optimization
Date: 27 Apr 92 20:27:32 GMT
From: rg@msel.unh.edu (Roger Gonzalez)
Organization: UNH Marine Systems Engineering Lab
Message-ID: <RG.92Apr27152732@nymph.msel.unh.edu>
Sender: news@nic.unh.edu (USENET News System)

A code snippet that worked on 6 systems, but failed on VxWorks:

    DG_REG *dg = (DG_REG *) max_io;  /* max_io is the addr of digimax regs */

    while(dg->dgTcsr & 0x80)         /* sit 'n spin till retrace */
		;  
    ...

Resulting code:

0c6504  2079 000d 0938           MOVEA .L    _max_io,A0
0c650a  1010                     MOVE  .B    (A0),D0
0c650c  0200 0080                ANDI  .B    #0x80,D0
0c6510  4a00                     TST   .B    D0
0c6512  66fc                     BNE         0x0c6510

Not quite what I wanted!  I've determined that a lot of my programming habits
are kind of sloppy.  :-)

I presume that notifying the compiler that dg->dgTcsr is volatile would help
some, but I haven't been able to get gcc to parse "volatile" as anything but a
syntax error.

Incidently, is there a better way to do this sort of thing than a busy wait on
the hardware register?  Has a nasty habit of burning cpu cycles...

- -Roger
- --
"The question of whether a computer can think is no more interesting
 than the question of whether a submarine can swim" - Edsger W. Dijkstra 

Roger Gonzalez   -  rg@msel.unh.edu
Division of Bit Banging and Reluctant Robotics
UNH Marine Systems Engineering Laboratory, Durham, NH  03824-3525
(603) 862-4600 -4399 (fax)

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: chomped on by a compiler optimization
Date: 27 Apr 92 22:10:56 GMT
From: hwajin@pogo.omni.com (Hwa-Jin Bae)
Organization: Interphase West, Santa Clara, CA
Message-ID: <HWAJIN.92Apr27151056@pogo.omni.com>
References: <RG.92Apr27152732@nymph.msel.unh.edu>
Sender: hwajin@iphasew.com

>>>>> On 27 Apr 92 20:27:32 GMT, rg@msel.unh.edu (Roger Gonzalez) said:

Roger> I presume that notifying the compiler that dg->dgTcsr is
Roger> volatile would help some, but I haven't been able to get gcc to
Roger> parse "volatile" as anything but a syntax error.

If this is due to "-traditional" mode gcc, you can use "__volatile__"
instead.

- --
Hwa-Jin Bae
Interphase West

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: vme address questions
Date: 27 Apr 92 22:34:39 GMT
From: hwajin@pogo.omni.com (Hwa-Jin Bae)
Organization: Interphase West, Santa Clara, CA
Message-ID: <HWAJIN.92Apr27153439@pogo.omni.com>
References: <RG.92Apr27104805@nymph.msel.unh.edu> <HMP.92Apr27134737@squash.frc.ri.cmu.edu>
Sender: hwajin@iphasew.com

>>>>> On 27 Apr 92 18:47:37 GMT, hmp@frc2.frc.ri.cmu.edu (Henning Pangels) said:
Henning> Nntp-Posting-Host: squash.frc.ri.cmu.edu

Henning> Agreed. I wouldn't be surprised if someone else out there has already
Henning> implemented such a function; I'd imagine it would be pretty simple to
Henning> modify the m() routine in usrLib.c to access memory as single bytes.

Modifying m() in usrLib.c is easy enough.  One of many ways to
accomplish the same thing inside VxWorks shell:

- -> junk='a'
- -> junk2='b'
- -> bcopy(&junk2,&junk,1)

- --
Hwa-Jin Bae
Interphase West

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Sparc 1e boot ROM's
Date: 27 Apr 92 23:18:04 GMT
From: bjh@healy2.Eng.Sun.COM (Brian Healy)
Organization: Sun Microsystems
Message-ID: <kvp2tcINN1hq@exodus.Eng.Sun.COM>
References: <9204260455.AA04740@uwila.cfht.hawaii.edu>
Reply-To: bjh@healy2.Eng.Sun.COM

The "New" SPARCengine 1E board uses bigger boot proms.   The three pins on the
daughter board (right between the proms) enables the user of the larger proms.  
What you need to do is to copy the two VxWorks proms onto a single large prom 
an AM27C020, or jumper the daugheter board to enable the use of the appropiate 
prom.

The small prom requires pins 1 & 2 jumpered, the large prom needs pins 2 & 3 
jumpered.

The following is a description on how to modify the daughter board to accept
the larger proms and enable the NextPROM feature.  It has the information you
need but is concerned with going form smaller to larger rather than
going form larger to smaller proms.  Hope it helps!

Brian

- ---------------

Use of the 1E CPU's "NextPROM" feature requires that the PROM daughter board
on the CPU be able to support the "Version 1.6" single, 256KB Boot PROM (in
CPU revisions -11 or earlier, the Sun Boot code was resident in *two* 128KB
PROMs).

CPUs with a dash number of -12 or higher are delivered from the factory with
NextPROM capability, and require no rework.  CPUs with a dash number of -11 or lower will require the modifications below.  The dash number of the CPU is
listed on the *BACK* of the barcode label affixed to the CPU's front panel.

Notes: These modifications are provided for your information only.  Be aware
       that customer modifications will void your Sun warranty, and may render
       your hardware "unserviceable" by Sun. 

       When handling your 1E hardware, be sure to follow the static electricity
       precautions outlined in the 1E CPU User's Manual.

       Refer to Chapter 8 of the current (March 27, 1991) 1E CPU User's Manual        for further information on the Boot PROM and the NextPROM feature.

Materials you will need:

1.  Two blank Intel 27C020 PROMs:

	* 256 Kbyte of ROM
	* 32-pin JEDEC DIP package
	* 200 nanoseconds or faster
	* Operating temperature 0 to 10 degrees C

    Note: Only Intel 27C020 PROMs have been qualified with the 1E CPU.
     	  Other, similiar devices have not been tested by Sun.

2.  A -11 or newer 1E CPU from which you can remove and copy the Boot PROM(s).     CPU versions -11 and -12 have identical PROM code.  Version -11 CPUs use
    a "Version 1.5" PROM *set* in which the boot code resides in two, 128KB
    PROMs (Intel 27C010).  Version -12 or higher CPUs use a "Version 1.6"
    PROM in which all boot code is contained in a single, 256KB PROM (Intel
    27C020).

    If you are not sure which Version of boot PROM is present, look at the
    "banner" on the monitor during boot-up.

Tools you will need:

1.  Electrostatic Discharge Prevention kit (ESD mat and wrist grounding strap).
2.  Basic electronic tools (soldering iron, hobby knife, wire, etc...).
3.  An appropriate PROM programming system. 

1.  Modify the PROM daughter board to accept 256KB PROM devices: 

	a) Remove PROM daughter board by removing the hex nut and washer
	   located between the two PROMs, the gently unplug the daughter
	   board.
	b) Cut trace on component side of daughter board
	   between pins 1 and 2 of J0101 (silk screen on back).
	c) Jumper pin 2 to pin 3 of J0101.
	d) Replace PROM daughter board, washer, and hex nut.

2.  Upgrade the PROMs:

	a) Remove the two existing Boot PROMs, devices U0101 and U0102, from
	   the PROM daughter board.

	b) Make a "Version 1.6" PROM.  If you are copying a 1.6 PROM, this
	   is a straightforward "copy" procedure.  If you are copying a 1.5
	   PROM	*set*, consult your PROM Programming Machine Instructions to
	   determine how to read the contents of the two 128KB PROMs and
	   program the combined code into the single 256KB PROM.  Read in the
	   U0101 PROM code first, then read in the U0102 PROM code.

	   Install your "new" Version 1.6 PROM at location U0101 on the PROM
	   daughter board.

	

---------------------------

End of New-News digest
**********************

From rayssd!pike.ssd.ray.com!fjr@uunet.uu.net  Tue Apr 28 06:58:55 1992
From: "Roeber" <fjr@pike.ssd.ray.com>
Date: Tue Apr 28 06:59:03 PDT 1992
Subject: Re: vme address questions
>  In article <RG.92Apr27104805@nymph.msel.unh.edu> rg@msel.unh.edu (Roger Gonzalez) writes:
>  
>  One big deficiency of the VxWorks shell that I had in pSOS is the ability to
>  examine or modify exactly -one- byte of memory at a time.  This is important
>  when you are playing with funky hardware where, for example, accessing the odd
>  bytes will give you a bus error.

One way I get around this problem is to use the set of bcopy routines to access
just the size you want.  There are bcopyBytes, bcopyWords, and bcopyLongs.
They all work like bcopy but use fixed access size.  You can malloc a chunk
of memory from the shell and then read the data into it.  If you have to, you
can do single bytes (e.g. bcopyBytes(src, dest, 1)).  This approach isn't
pretty since it involves a bit of typing but at least it works.  Fred

    ______________________________________________________________
   |  Fred J Roeber,  Raytheon Submarine Signal Division          |
   |  1847 West Main Road,  Mail Stop 188                         |
   |  Portsmouth, RI  02871-1087  (401) 847-8000 (X4205)          |
   |                                                              |
   |      {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr             |
   |______________________________________________________________|

From briggs@thalia.jpl.nasa.gov  Tue Apr 28 08:16:48 1992
From: briggs@thalia.jpl.nasa.gov (Clark Briggs)
Date: Tue Apr 28 08:16:58 PDT 1992
Subject: using mmus in realtime
Recent discussions about virtual memory and cache management reminded me
of a long standing question I have about the cost of using mmus vs the benefit
gained.  Back when 68020s came with 68451 mmus it was pretty clear how to
choose to use or not use them.  The mmu added one or two wait states for each
address cycle, a big hit.  Now that the mmu is integral to the CPU, its harder
to tell what the performance hit is, if any.  Besides, it seems that many of
the manufacturers are using the mmus to simplify the hardware.  For example,
I understand (but dont know where I got this info) that the mmu in the 68030
contributes to implementing the VMEbus memory map on HK68/V3Es.

If mmus are less expensive in that you get one naturally and they are always
on anyway, doesnt that make a few software features a lot cheaper to get?
Like protected logical address spaces for tasks.  The task would run at the
same speed but the context would be larger (a concern during switching,
depending on the mmu) and the system must be prepared to handle the exceptions.

Like shared data regions.  But a new system service would be required to
arrange the mapping.

Like virtual memory. But the system must handle the page faults and its not
clear how to do this reasonably in a real-time system.  (This is different, 
that is its more than, just logical address spaces for tasks.)

With all of these available, the user could choose which to use in building
a set of tasks.  Some might run like tasks do now, or some of the wilder
ones or the more important ones might get private logical spaces.  Maybe
even a noncritical task like a console keeper might be implemented using
virtual memory, and maybe on its own cpu.  But there could be a place for
each of these features.

I always liked the sound of Masscomp's rtu where the user could scale the Unix
features down to a kernel.  You could chose to memory lock your code, or not
use certain system functions.  I think you always got a private logical space.
I was told the minimal kernel would run in single digit multiples of real
kernels like VxWorks on such metrics as context switch times or semaphore
gives.  Plus they have had multiprocessing for a while and can put 2 or 4
68040s on a (9U?) board.  Yeah, I always thought that sounded nice.

So why cant we have some of these features?

Clark Briggs
briggs@csi.jpl.nasa.gov

From prb@aplexus.jhuapl.edu  Tue Apr 28 10:37:18 1992
From: prb@aplexus.jhuapl.edu (Paul R. Bade)
Date: Tue Apr 28 10:38:10 PDT 1992
Subject: Re: distributed vxWorks
----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Content-Lines: 30

For those of you that are interested in using the MMU with MV167 boards,
here is the heart of the MMU code.  Several other corresponding changes
were made to bootConfig.c, usrConfig.c, and most importantly to sysLib.c
to make the whole thing work. 

Briefly, we have low memory set up as
noncacheable and mapped to the VMEbus without snooping.
Then we have changed the start of the system memory pool to allow for
a fixed area to load our code and write protect it. This area and
the system memory pool is not visible
from the VMEbus and is cacheable copyback. 
We have also lowered the end of the system memory pool to allow for 
a the backplane memory pool (BP_MEM_ADRS & BP_MEM_SIZE).
This area is setup to be writethrough cacheable.  It is mapped 
to the VMEbus using the 2nd set of regs on the MV167, so it
can be mapped with bus snooping.
Our boards are mapped at addresses 0x10000000 (proc0),
0x11000000 (proc1), 0x12000000 (proc2), etc. so the BP anchor is 0x10000600.
VMEbus addresses 0x20000000 thru 0x3fffffff are transparently
translated as non-cacheable.
It has worked out well for us.

		Have fun,

		Paul Bade
		Johns Hopkins University / Applied Physics Lab
		prb@aplexus.jhuapl.edu

----------
X-Sun-Data-Type: c-file
X-Sun-Data-Description: c-file
X-Sun-Data-Name: mmu.c
X-Sun-Content-Lines: 1753

static char resid[] = "$Id: mmu.c,v 1.4 1992/04/08 12:09:46 prb Exp $";
/****************************************************************************
 *                                                                          *
 * MMU Initialization                                                       *
 *                                                                          *
 *--------------------------------------------------------------------------*
 *                                                                          *
 * Module:     mmu.c                                                        *
 *                                                                          *
 *--------------------------------------------------------------------------*
 *                                                                          *
 * Function:  This module intializes the mmu and creates the translation    *
 *            tables required for operation. To make the mmu work with      *
 *            VxWorks required modification to the location that VxWorks    *
 *            runs at as well as specification of where the application     *
 *            module would be loaded. The following addresses are noteworthy*
 *
 * Note: The vxWorks files were modified to load the applic at the locations
 *       shown below using loadModuleAt(). In the future the code will
 *       be loaded via load script and then write protected.
 *                                                                          *
 *            CEP ADDRESSES                                                 *
 *                                                                          *
 *            Processor Description Block      0x400                        *
 *	      ADP Input Data Pointer	       0x500
 *	      Backplane Anchor		       0x600
 *            Vmebus Global Mem Pool           0x01000                      *
 *            MMU translation tables           SYS_TTABLE
 *            VxWorks text start               VX_CODE_SPACE = 0x8000
 *            VxWorks data start               VX_DATA_SPACE = 0x100000
 *            Application text start           &end
 *            Application data                 dynamically computed by ldFile.c
 *            VMEbus Access                    0x1000000 thru 0x3ffffff     *
 *                                                                          *
 *                                                                          *
 * Note: The MV167 boards are mapped to the VMEbus at locations:            *
 *                                                                          *
 *           Proc 0 => 0x10000000                                           *
 *           Proc 1 => 0x11000000                                           *
 *           Proc 2 => 0x12000000                                           *
 *           Proc 3 => 0x13000000                                           *
 *                                                                          *
 *       For each processor, there is a window from the VMEbus at           *
 *       low memory and another window at high memory. For protection,      *
 *       middle memory is not visible from the VMEbus.                      *
 *                                                                          *
 *--------------------------------------------------------------------------*
 *                                                                          *
 * Resources:                                                               *
 *                                                                          *
 *       Hardware Resources:                                                *
 *        MMU                                                               *
 *                                                                          *
 *                                                                          *
 *       Communication Resources:                                           *
 *       - NONE -                                                           *
 *                                                                          *
 *                                                                          *
 *       Task Requirements:                                                 *
 *        Task Name             Priority                                    *
 *        ---------             --------                                    *
 *        PMMUTask               200      uses excessive CPU - must be LP   *
 *                                                                          *
 *                                                                          *
 *       Stack Requirements:                                                *
 *        Name                  Stack Size                                  *
 *        ---------             ----------                                  *
 *        PMMUTask               2048                                       *
 *                                                                          *
 *                                                                          *
 *       Interrupt Vectors:                                                 *
 *        Name                  Vector                                      *
 *        ---------             ------                                      *
 *        PMMU Config             56                                        *
 *        PMMU Operation          57                                        *
 *        PMMU Access Lvl Vio     58                                        *
 *        NOTE: Exception handlers have not been written for the MMU for    *
 *              following reasons:
 *                                                                          *
 *        PMMU Config: this is completed during usrRoot and my past         *
 *         experience tells me that you can't attach a signal handler to    *
 *         root.                                                            *
 *                                                                          *
 *        PMMU Oper: Because logical=physical in this application and all   *
 *        tasks run at the supervisor level, the only types of operating    *
 *        exceptions possible are bus errors resulting from access          *
 *        with the result being suspending the task and reporting the 'bad' *
 *        address - VxWorks already does this.                              *

 *        Future modifications to the memory map and translation tables may *
 *        benifit from an exception handler or two, but another way to check*
 *        the translation tables in this environment is to run 'map167Bd',  *
 *        see below, which will check all 4 gigabytes of address space and  *
 *        print the  results.                                               *
 *                                                                          *
 *                                                                          *
 *       Libraries Required:                                                *
 *        Library Name          Description                                 *
 *        ------------          -----------                                 *
 *        cmnd Library          logs Commands to Cmnd Processor             *
 *        error Library         Used to Report Errors that occur            *
 *                                                                          *
 *------------------------------------------------------------------------  */
/*    $Log: mmu.c,v $
 * Revision 1.4  1992/04/08  12:09:46  prb
 * CEC release 1.4
 *
 * Revision 1.3  1992/02/28  14:43:38  prb
 * Made Burst Pool Non-cacheable, fixed Wasp Program space so it is copyback
 *
 * Revision 1.2  1992/02/26  13:25:10  prb
 * Added MMU writeProtect() for code space
 *
 * Revision 1.1  1992/02/17  14:47:19  prb
 * Initial revision
 *
 * */
/*******************
 * Module Includes *
 *******************/

#include "vxWorks.h" 
#include "taskLib.h" 
#include "mv167.h" 
#include "pccchip2.h" 
#include "memc040.h" 
#include "config.h" 

#include "cmnd_.h"
#include "error_.h"

IMPORT char end;                /* automatically defined by the loader */
 
/*******************************
 * Module Defines              * 
 *******************************/

#define EIGHT_KBYTE	0x2000
#define PAGE_SIZE	EIGHT_KBYTE
 
#define MMU_SUPV     1              /* supervisor access */
#define MMU_USR      0              /* user/supervisor access */
#define MMU_RONL     1              /* WP = read only */
#define MMU_RDWR     0              /* WP = read/write   */
#define MMU_EN_WRITETHROUGH     0   /* Cachable, WriteThrough */
#define MMU_EN_COPYBACK         1   /* Cachable, CopyBack */
#define MMU_INHIB_SERIAL        2   /* NonCachable, Serialized */
#define MMU_INHIB_NONSERIAL     3   /* NonCachable, NonSerialized */

#define MMU_OUR_POOL	MMU_EN_WRITETHROUGH

#define MMU_UDT_RESIDENT	2   /* Upper descriptor resident */
#define	MMU_UDT_INVALID		0   /* Upper descriptor invalid */
#define MMU_PDT_RESIDENT	1   /* page resident */
#define	MMU_PDT_INVALID		0   /* page invalid */
#define	MMU_PDT_INDIRECT	2   /* page descriptor indirect */

#define MMU_GLOBAL	0
#define MMU_NON_GLOBAL	1

#ifdef CEP

#define A_TBL_LEN       128         /* 128 entries x 4 bytes/entry */
#define MAX_LVL_A_TBLS    1         /* 1 Level A Table */
#define B_TBL_LEN       128         /* 128 entries x 4 bytes/entry */
#define MAX_LVL_B_TBLS    5         /* 2 Level B Tables */
#define PAGE_TBL_LEN    32         /* 32 entries x 4 bytes/entry(8KByte pages)*/

#else

#define A_TBL_LEN       128         /* 128 entries x 4 bytes/entry */
#define MAX_LVL_A_TBLS    1         /* 1 Level A Table */
#define B_TBL_LEN       128         /* 128 entries x 4 bytes/entry */
#define MAX_LVL_B_TBLS    2         /* 2 Level B Tables */
#define PAGE_TBL_LEN    32         /* 32 entries x 4 bytes/entry(8KByte pages)*/

#endif

#define MMU_TASK_STACK 2048         /* stack size of task that prints table */
#define MMU_TASK_PRIOR 254          /* priority of task that prints table */

typedef  unsigned int  U_INT;

struct RP
{
    unsigned         addr     :23,
                     fixed    :9;
};

struct TC
{
    unsigned short   e        :1; /* enable translation */
    unsigned short   ps       :1; /* 1 => 8k page size, 0 => 4k page size */
    unsigned short   reserved :14;
};

typedef struct
{
    unsigned    address  :  8, /* logical address */
              	addrmask :  8, /* logical address mask */
                e        :  1, /* enable translation */
                sfield   :  2,   /* supervisor/user mode matching */
		zero     :  3,
		u1       :  1,
		u0       :  1,
		zero1    :  1,
                cm       :  2,   /* cache mode */
		zero2    :  2,
                wp       :  1, /* 1=write protect; 0=r/w */
		zero3    :  2;

} TTR; /* Transparent translation register */

typedef struct 
{
    unsigned    addr     : 20,
                b        : 1,   /* buss error indicator */
                g        : 1,   /* global */
                u1       : 1,   /* user page attribute 1 */
                u0       : 1,   /* user page attribute 0 */
                s        : 1,   /* supervisor privilage only */
                cm       : 2,   /* cache mode */
                m        : 1,   /* modified */
		zero     : 1,
                wp       : 1,   /* write protected */
                t        : 1,   /* located in transparent trans reg */
                r        : 1;   /* resident */
} MMU_SR;

typedef struct
{
    unsigned int   address  : 23; /* address of level B table (16 byte aligned) */
    unsigned int   reserved :  5;
    unsigned int   used     :  1;
    unsigned int   wp       :  1; /* 1=write protect; 0=r/w */
    unsigned int   udt      :  2; /* upper descriptor type */
                                    /* 0,1 = invalid
                                       2,3 = next descriptor resident 
                                             (2 is preferred)*/
} LVL_A_TBL_ENTRY; /* level A table descriptor */

typedef struct
{
    unsigned 	address  : 25, /* address of page table (16 byte aligned) */
		reserved :  3,
		used     :  1,
                wp       :  1, /* 1=write protect; 0=r/w */
                udt      :  2; /* upper descriptor type */
                                    /* 0,1 = invalid
                                       2,3 = next descriptor resident 
                                             (2 is preferred)*/
} LVL_B_TBL_ENTRY; /* level B table descriptor */

typedef struct
{
    unsigned 	address  : 19, /* address of page table (16 byte aligned) */
		ur       :  2,
		global   :  1,
		u1       :  1,
		u0       :  1,
                s        :  1,   /* supervisor privilage only */
                cm       :  2,   /* cache mode */
                m        :  1,   /* modified */
		u        :  1,   /* used */
                wp       :  1, /* 1=write protect; 0=r/w */
                pdt      :  2; /* page descriptor type */
                                    /* 0,3 = invalid
                                       1   = page resident 
                                       1   = indirect descriptor */

} PAGE_ENTRY; /* 8K page descriptor */

/*******************************
 * Required External Functions *
 *******************************/
 
/*******************************
 * Local Functions             * 
 *******************************/
LOCAL void createADesc(LVL_A_TBL_ENTRY *tableAEntry, int wp, int valid,
                      LVL_B_TBL_ENTRY *tableBEntry);
LOCAL void createBDesc(LVL_B_TBL_ENTRY *tableBEntry, int wp, int valid,
                      PAGE_ENTRY *tableCEntry);
LOCAL void createCDesc(PAGE_ENTRY *pageEntry, int global, int sup, int cm, 
                      int wp, int valid, unsigned int pageAddr);
LOCAL void printAttribs(char* firstAddr, char* lastAddr, MMU_SR attributes);

/*******************************
 * Global Functions            * 
 *******************************/
void  mmuInit();
void  mapAdrs(U_INT,U_INT);
void  testmmu();
void  map167Bd();
void  turnMmuOff();
void  showMmuRegs();
void  writeProtect();
void  unProtect();
 
/*******************************
 * Local Variables             * 
 *******************************/
LOCAL LVL_A_TBL_ENTRY    *pA000T;
LOCAL LVL_B_TBL_ENTRY    *pB000T;
LOCAL PAGE_ENTRY         *pC000T;

/* pointer to descriptors where vxWorks Code Starts */
LOCAL PAGE_ENTRY         *pCDescCodeStart = (PAGE_ENTRY*)0;

/* pointer to descriptors where application Code Starts */
LOCAL PAGE_ENTRY         *pCDescapplicCodeStart = (PAGE_ENTRY*)0;

LOCAL PAGE_ENTRY         *pCDescTransTableStart = (PAGE_ENTRY*)0;
 
LOCAL struct RP         cpuRootPtr;
LOCAL struct TC         transCntlReg;

LOCAL TTR        instruTransTransReg0;
LOCAL TTR        instruTransTransReg1;
LOCAL TTR        dataTransTransReg0;
LOCAL TTR        dataTransTransReg1;

LOCAL U_INT             *testAddrOld;
LOCAL U_INT             *testAddrNew;
LOCAL MMU_SR             copyOfSrNew;
LOCAL MMU_SR             copyOfSrOld;

LOCAL U_INT tempReg;  /* used to force the reg to be read as D32, when */
                       /*   setting up snoop control */

/*******************************
 * Global Variables            * 
 *******************************/

applicCodeStart = 0;
applicCodeSize = 0;

/*******************************
 * Module Routines             * 
 *******************************/
/***********************************************************************
* MMU Initialization                                                   *
*                                                                      *
* Routine:          mmuInit()                                          *
*                                                                      *
* Description:      initializes the mmu translation table, then calls  *
*                   then turns on the mmu.                             *
*                                                                      *
* Calling Seq:      mmuInit()                                          *
*                                                                      *
* Return param:     none                                               *
*                                                                      *
* Characteristics:  If after changing this routine to remap any        *
*                   sections of memory, the mmu causes a halt          *
*                   immediately after turning it on, check here. The   *
*                   tables must be correct to get anything to work     *
************************************************************************/

void mmuInit()
{
    short        i, j;
    unsigned int addr;    /* address counter for table construction */
    unsigned int *regPtr;
    static char *memTop;
    int		lockKey;
    
    memTop = (char *)((4 << (*MEMC_MCR & 0x07)) << 20);
    applicCodeStart = (int)(((int)&end + PAGE_SIZE - 1) & (~((int)PAGE_SIZE - 1)));

    /* the tables are set up as hardcoded offsets from the base location; 
       these values will need to change if the size of a table changes */
    pA000T = (LVL_A_TBL_ENTRY *)SYS_TTABLE;
    pB000T = (LVL_B_TBL_ENTRY *)(pA000T + (MAX_LVL_A_TBLS * A_TBL_LEN));
    pC000T = (PAGE_ENTRY *)(pB000T + (MAX_LVL_B_TBLS * B_TBL_LEN));

    /* set up root pointer register value */
    cpuRootPtr.addr   = ((unsigned int) pA000T) >> 9;	/* table addr >> 9 */
    cpuRootPtr.fixed  = 0;              	/* unused */

    /* set up instruction transparent translation reg 0 */
    instruTransTransReg0.address   = 0x00; /* from address 0x00000000 */
    instruTransTransReg0.addrmask  = 0xff; /*   to address 0xffffffff */
    instruTransTransReg0.e         = 1;       /* enable transparent transl */
    instruTransTransReg0.sfield    = 0x3;     /* ignore FC2 matching */
    instruTransTransReg0.zero      = 0;
    instruTransTransReg0.u1        = 0;
    instruTransTransReg0.u0        = 0;
    instruTransTransReg0.zero1     = 0;
    instruTransTransReg0.cm        = MMU_EN_WRITETHROUGH;
    instruTransTransReg0.zero2     = 0;
    instruTransTransReg0.wp        = MMU_RDWR;
    instruTransTransReg0.zero3     = 0;

    /* set up instruction transparent translation reg 1 */
    instruTransTransReg1.e         = 0;       /* disable transparent trans r1 */

    /* set up data transparent translation reg 0 */
    dataTransTransReg0.address   = 0x10;    /* from address 0x10000000 */
    dataTransTransReg0.addrmask  = 0x0f;    /*   to address 0x1fffffff */
    dataTransTransReg0.e         = 1;       /* enable transparent transl */
    dataTransTransReg0.sfield    = 0x3;     /* ignore FC2 matching */
    dataTransTransReg0.zero      = 0;
    dataTransTransReg0.u1        = 0;
    dataTransTransReg0.u0        = 0;
    dataTransTransReg0.zero1     = 0;
    dataTransTransReg0.cm        = MMU_INHIB_SERIAL;
    dataTransTransReg0.zero2     = 0;
    dataTransTransReg0.wp        = MMU_RDWR;
    dataTransTransReg0.zero3     = 0;

    /* set up data transparent translation reg 1 */
    dataTransTransReg1.address   = 0x20;    /* from address 0x20000000 */
    dataTransTransReg1.addrmask  = 0x1f;    /*   to address 0x3fffffff */
    dataTransTransReg1.e         = 1;       /* enable transparent transl */
    dataTransTransReg1.sfield    = 0x3;     /* ignore FC2 matching */
    dataTransTransReg1.zero      = 0;
    dataTransTransReg1.u1        = 0;
    dataTransTransReg1.u0        = 0;
    dataTransTransReg1.zero1     = 0;
    dataTransTransReg1.cm        = MMU_INHIB_SERIAL;
    dataTransTransReg1.zero2     = 0;
    dataTransTransReg1.wp        = MMU_RDWR;
    dataTransTransReg1.zero3     = 0;

    /* set up translation register value */
    transCntlReg.e         = 0x1;            /* enable translation */
    transCntlReg.ps        = 0x1;            /* 8kByte pages */
    transCntlReg.reserved  = 0;              /* reserved */

    /* creating the symbol table ... */
    printf ("Trans Table Addrs... \n");
    printf ("A  tables begin at %08x\n",pA000T);
    printf ("B  tables begin at %08x\n",pB000T);
    printf ("C  tables begin at %08x\n",pC000T);
    
    /* create tables... */

    /******************************************/
    /* create A table entry for lower 32MByte */
    /******************************************/
    createADesc(pA000T++,MMU_RDWR,MMU_UDT_RESIDENT,pB000T); 
#ifdef DEBUG_PRINT
    pA000T--;
    printf("A Desc at 0x%x = 0x%x\n", pA000T, *((unsigned int*)pA000T));
    pA000T++;
#endif

    /*************************************************/
    /* create B and C table entries for lower 1MByte */
    /*************************************************/
    for (addr = 0; addr < 0x100000; )
    {
      createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T); 

      for ( j = 0; j < 32; j++)
      {
        if (addr >= VX_CODE_SPACE)
        {
          /* Map Application Code As CopyBack */
          createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RDWR,MMU_PDT_RESIDENT,addr); 
        }
        else if (addr >= SYS_TTABLE)
        {
          /* Map Translation Tables As Read Only */
          createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RONL,MMU_PDT_RESIDENT,addr); 
        }
        else
        {
          /* Map BackPlane Anchor and CEP_POOL As Inhibited Serial */
          createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RDWR,MMU_PDT_RESIDENT,addr); 
        }

        addr += EIGHT_KBYTE;

        if(addr == VX_CODE_SPACE)
        {
          /**************************************************************/
          /* Save Pointers to the Descriptors where vxWorks code starts */
          /*  so we can write protect later                             */
          /**************************************************************/
          pCDescCodeStart = pC000T;

        }
        if(addr == applicCodeStart)
        {
          /*************************************************************/
          /* Save Pointers to the Descriptors where applic code starts */
          /*  so we can write protect later                            */
          /*************************************************************/
          pCDescapplicCodeStart = pC000T;
        }
      }
    }

    /* create B and C table entries for rest of on-board memory */
    for (addr = 0x100000; addr < memTop; )
    {
      createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T); 

      for ( j = 0; j < 32; j++)
      {
        if((sysProcNumGet() == 0) && (BP_MEM_ADRS != NONE))
        {
#ifdef INCLUDE_BURST_POOL

          if(addr< (memTop - BURST_POOL_SIZE - BP_MEM_SIZE))
            createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RDWR,MMU_PDT_RESIDENT,addr); 
          else 
            createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RDWR,MMU_PDT_RESIDENT,addr); 

#else

          if(addr< (memTop - ANTARES_POOL_SIZE - BP_MEM_SIZE))
            createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RDWR,MMU_PDT_RESIDENT,addr); 
          else 
            createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_WRITETHROUGH,MMU_RDWR,MMU_PDT_RESIDENT,addr); 

#endif
        }

        else
        {
#ifdef INCLUDE_BURST_POOL

          if(addr < (memTop - BURST_POOL_SIZE))
            createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RDWR,MMU_PDT_RESIDENT,addr); 
          else
            createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RDWR,MMU_PDT_RESIDENT,addr); 
#else

          if(addr < (memTop - ANTARES_POOL_SIZE))
            createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RDWR,MMU_PDT_RESIDENT,addr); 
          else
            createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_WRITETHROUGH,MMU_RDWR,MMU_PDT_RESIDENT,addr); 

#endif
        }

        addr += EIGHT_KBYTE;

        if(addr == applicCodeStart)
        {
          /*************************************************************/
          /* Save Pointers to the Descriptors where applic code starts */
          /*  so we can write protect later                            */
          /*************************************************************/
          pCDescapplicCodeStart = pC000T;

        }
      }

    }

#define TEMPORARY
#ifdef CEP

    
    /* Create none resident B table entries n lower 16 MB if needed */
    /* none resident (i.e. handled by transparent translation)   */
    for (addr = (unsigned int)memTop; addr < 0x1000000; )
    {
      createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T);

      for ( j = 0; j < 32; j++)
      {
        createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RDWR,MMU_PDT_RESIDENT,addr);

        addr += EIGHT_KBYTE;
      }
    }

    /* Create resident B table entries 16 thru 32 Mbytes (Main Cntlr VSB) */
    for (addr = 0x1000000; addr < 0x2000000; )
    {
      createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T);

      for ( j = 0; j < 32; j++)
      {
        createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RDWR,MMU_PDT_RESIDENT,addr);

        addr += EIGHT_KBYTE;
      }
    }  
    /*******************************************/
    /* create A table entry for second 32MByte */
    /*******************************************/
    createADesc(pA000T++,MMU_RDWR,MMU_UDT_RESIDENT,pB000T);

    /* Create resident B table entries 32 thru 64 Mbytes (IO & UG Cntlrs VSB) */
    for (addr = 0x2000000; addr < 0x4000000; )
    {
      createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T);

      for ( j = 0; j < 32; j++)
      {
        createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RDWR,MMU_PDT_RESIDENT,addr);

        addr += EIGHT_KBYTE;
      }
    }  

    /*******************************************/
    /* create A table entry for third 32MByte */
    /*******************************************/
    createADesc(pA000T++,MMU_RDWR,MMU_UDT_RESIDENT,pB000T);

    /* Create resident B table entries 32 thru 64 Mbytes (IO & UG Cntlrs VSB) */
    for (addr = 0x4000000; addr < 0x6000000; )
    {
      createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T);

      for ( j = 0; j < 32; j++)
      {
        createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RDWR,MMU_PDT_RESIDENT,addr);

        addr += EIGHT_KBYTE;
      }
    }  

    /*******************************************/
    /* create A table entry for fourth 32MByte */
    /*******************************************/
    createADesc(pA000T++,MMU_RDWR,MMU_UDT_RESIDENT,pB000T);

    /* Create resident B table entries 32 thru 64 Mbytes (IO & UG Cntlrs VSB) */
    for (addr = 0x6000000; addr < 0x8000000; )
    {
      createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T);

      for ( j = 0; j < 32; j++)
      {
        createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RDWR,MMU_PDT_RESIDENT,addr);

        addr += EIGHT_KBYTE;
      }
    }  

    /********************************************/
    /* create A table entries for middle memory */
    /********************************************/
    for (addr = 0x8000000; addr < 0xfe000000; )
    {
      createADesc(pA000T++,MMU_RDWR,MMU_UDT_INVALID,(LVL_B_TBL_ENTRY*)0); 
      addr += (128 * 32 * EIGHT_KBYTE);
    }

#else

    /* Create none resident B table entries for memTop thru 32 Mbytes */
    /* none resident (i.e. handled by transparent translation)   */
    for (addr = (unsigned int)memTop; addr < 0x2000000; )
    {
      createBDesc(pB000T++,MMU_RDWR,MMU_UDT_INVALID,(PAGE_ENTRY*)0); 
      addr += (32 * EIGHT_KBYTE);
    }

    /********************************************/
    /* create A table entries for middle memory */
    /********************************************/
    for (addr = 0x2000000; addr < 0xfe000000; )
    {
      createADesc(pA000T++,MMU_RDWR,MMU_UDT_INVALID,(LVL_B_TBL_ENTRY*)0); 
      addr += (128 * 32 * EIGHT_KBYTE);
    }
#endif

    /******************************************/
    /* create A table entry for upper 32MByte */
    /******************************************/
    createADesc(pA000T++,MMU_RDWR,MMU_UDT_RESIDENT,pB000T); 

    /* create B and C table entries for A24 area 0xffe00000 to 0xffbfffff */
    for (addr = 0xfe000000; addr < 0xfe040000; )
    {
      createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T); 

      for ( j = 0; j < 32; j++)
      {
        createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RDWR,MMU_PDT_RESIDENT,addr); 
        addr += EIGHT_KBYTE;
      }
    }

    /* Create none resident (96) B table entries for 0xfe000000 to 0xff7fffff */
    /* none resident (i.e. handled by transparent translation)   */
    for (addr = 0xfe040000; addr < 0xff800000; )
    {
      createBDesc(pB000T++,MMU_RDWR,MMU_UDT_INVALID,(PAGE_ENTRY*)0); 
      addr += (32 * EIGHT_KBYTE);
    }

    /* create B and C table entries for EPROM area 0xff800000 to 0xffbfffff */
    for (addr = 0xff800000; addr < 0xffc00000; )
    {
      createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T); 

      for ( j = 0; j < 32; j++)
      {
        createCDesc(pC000T++,MMU_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RONL,MMU_PDT_RESIDENT,addr); 

        addr += EIGHT_KBYTE;
      }
    }

    /* Reserved area */
    /* Create none resident (8) B table entries for 0xffc00000 to 0xffdfffff */
    for (addr = 0xffc00000; addr < 0xffe00000; )
    {
      createBDesc(pB000T++,MMU_RDWR,MMU_UDT_INVALID,(PAGE_ENTRY*)0); 
      addr += (32 * EIGHT_KBYTE);
    }

    /*Create (1) B and C table entries for SRAM area 0xffe00000 to 0xffe1ffff */
    for (addr = 0xffe00000; addr < 0xffe40000; )
    {
      createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T); 

      for ( j = 0; j < 16; j++) /* SRAM here */
      {
        createCDesc(pC000T++,MMU_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RDWR,MMU_PDT_RESIDENT,addr); 

        addr += EIGHT_KBYTE;
      }
      for ( j = 0; j < 16; j++) /* mirror of SRAM here */
      {
        createCDesc(pC000T++,MMU_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RDWR,MMU_PDT_INVALID,addr); 

        addr += EIGHT_KBYTE;
      }
    }

    /* More repeated SRAM area */
    /* Create none resident (3) B table entries for 0xffe40000 to 0xffefffff */
    for (addr = 0xffe40000; addr < 0xfff00000; )
    {
      createBDesc(pB000T++,MMU_RDWR,MMU_UDT_INVALID,(PAGE_ENTRY*)0); 
      addr += (32 * EIGHT_KBYTE);
    }

    /* create B and C table entrs for Local I/O and VMEbus Short I/O area */
    /*   (0xfff00000 to 0xfffeffff) and (0xffff0000 to 0xffffffff)        */
    for (addr = 0xfff00000; addr != 0x0; )
    {
      createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T); 

      for ( j = 0; j < 32; j++)
      {
        createCDesc(pC000T++,MMU_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RDWR,MMU_PDT_RESIDENT,addr); 

        addr += EIGHT_KBYTE;
      }
    }

    printf("Last table entry address = %x\n", ((unsigned int)pC000T) - 1);
    printf("Chip...");

    lockKey = intLock();

    /* Obtain VMEbus while changing translation stuff */
    tempReg = *VMECHIP2_DMACR1;   /* |= does not work properly on 32 bit regs */
    tempReg |= DMACR1_DWB;
    *VMECHIP2_DMACR1 = tempReg;

    tempReg = 0;
    while (!(tempReg & DMACR1_DHB)) /* wait til we have the bus */
      tempReg = *VMECHIP2_DMACR1;

#ifdef NEW_ASSEMBLER
    /* push and invalidate caches */
/*    asm ("cpusha bc"); */
    asm (".word 0xf4ff");

    /* Disable Cache */
    asm ("movel #0, a0");
    asm ("movec a0, cacr");

    /* Disable Translation */
    asm ("movel #0, a0");
    asm ("movec a0, tc");

    /* Set up Translation Tree Root Pointers */
    asm ("movel _cpuRootPtr, a0");
    asm ("movec a0, urp");
    asm (".word 0xf518");
    asm ("movec a0, srp");
    asm (".word 0xf518");

    /* flush address translation caches */
/*  asm("pflusha"); */
    asm (".word 0xf518");

    /* Enable Translation */
    asm ("movel #0, a0");
    asm ("movew _transCntlReg, a0");
    asm ("movec a0, tc");

    /* Set up Transparent Translation Registers */
    asm ("movel _instruTransTransReg0, a0");
    asm ("movec a0, itt0");
    asm (".word 0xf518");
    asm ("movel _instruTransTransReg1, a0");
    asm ("movec a0, itt1");
    asm (".word 0xf518");
    asm ("movel _dataTransTransReg0, a0");
    asm ("movec a0, dtt0");
    asm (".word 0xf518");
    asm ("movel _dataTransTransReg1, a0");
    asm ("movec a0, dtt1");
    asm (".word 0xf518");

#else
    /* push and invalidate caches */
    asm (".word 0xf4ff");	/* cpusha bc */

    /* Disable Cache */
    asm ("movel #0, a0");
    asm ("movec a0, cacr");

    /* Disable Translation */
    asm ("movel #0, a0");
    asm (".word 0x4e7b,0x8003");	/* movec a0, tc */

    /* Set up Translation Tree Root Pointers */
    asm ("movel _cpuRootPtr, a0");
    asm (".word 0x4e7b,0x8806");	/* movec a0, urp */
    asm (".word 0xf518");
    asm (".word 0x4e7b,0x8807");	/* movec a0, srp */
    asm (".word 0xf518");

    /* flush address translation caches */
    asm (".word 0xf518"); 		/* pflusha */

    /* Enable Translation */
    asm ("movel #0, a0");
    asm ("movew _transCntlReg, a0");
    asm (".word 0x4e7b,0x8003");	/* movec a0, tc */

    /* Set up Transparent Translation Registers */
    asm ("movel _instruTransTransReg0, a0");
    asm (".word 0x4e7b,0x8004");	/* movec a0, itt0 */
    asm (".word 0xf518");
    asm ("movel _instruTransTransReg1, a0");
    asm (".word 0x4e7b,0x8005");	/* movec a0, itt1 */
    asm (".word 0xf518");
    asm ("movel _dataTransTransReg0, a0");
    asm (".word 0x4e7b,0x8006");	/* movec a0, dtt0 */
    asm (".word 0xf518");
    asm ("movel _dataTransTransReg1, a0");
    asm (".word 0x4e7b,0x8007");	/* movec a0, dtt1 */
    asm (".word 0xf518");

#endif

    /* Turn On Snoop Control for PCC Chip2 Serial Port */
    /* snoop option -> update snooped cache                                */
    /* NOTE errata says that inval. cache does not work properly for reads */
    *PCC2_SCC_RICR |= SCC_RICR_SINK_DATA; /* |= works for 8 bit reg */

    /****************************************************/
    /****************************************************/
    /* Instead of using bus snooping for the sockets,   */
    /*  one could create a seperate memory pool         */
    /*  LN_POOL_ADRS and LN_POOL_SIZE are defined in    */
    /*  the config.h for the target.                    */
    /*  a LN_POO_ADRS == NONE (-1) means use the        */
    /*  global memory pool and malloc.                  */
    /*                                                  */
    /****************************************************/
    /****************************************************/
    /* Turn On Snoop Control for PCC Chip2 Lanc */
    /* snoop option -> update snooped cache                                */
    /* NOTE errata says that inval. cache does not work properly for reads */
    *PCC2_LANC_BEICR |= LANC_BEICR_SINK_DATA; /* |= works for 8 bit reg */

#if FALSE
#endif

    /* Check Rev of memc040 chip */
    /*  *MEMC_RCR |= MEMC_RCR_SWAIT;   Needed for errata when bus snooping */
    if(*MEMC_REVISION == 0x00) /* MEMC_REVISION can be read as a byte */
      *MEMC_RCR |= MEMC_RCR_SWAIT; /* |= works for 8 bit reg */

    /* Turn On Snoop Control when VME Slave */
    /* snoop option -> update snooped cache */
    /* NOTE errata says that inval. cache does not work properly for reads */

    tempReg = *VMECHIP2_VSAMSR;

/* prb */
#ifndef INCLUDE_BURST_POOL
    tempReg |= VSAMSR2_SNP_WSD;  /* snoop upperwindow for bp_network/antares*/
#endif

/* turn off snooping in this lower window since nonCacheable */
    tempReg &= ~(VSAMSR1_SNP_WSD | VSAMSR1_SNP_WI);
      *VMECHIP2_VSAMSR = tempReg;

    /* Turn On Snoop Control for VME DMA */
    /* snoop option -> update snooped cache */
    /* NOTE errata says that inval. cache does not work properly for reads */
    tempReg = *VMECHIP2_DMACR2;
    tempReg |= DMACR2_SINK_DATA;
    *VMECHIP2_DMACR2 = tempReg;

    /* WARNING SCSI Snoop Control not set up */

#ifdef NEW_ASSEMBLER
    /* Enable Cache */
    asm ("movel #0x80008000, a0");
    asm ("movec a0, cacr");
#else
    /* Enable Cache */
    asm ("movel #0x80008000, a0");
    asm (".word 0x4e7b,0x8002");	/* movec a0, cacr */
#endif

    tempReg = *VMECHIP2_DMACR1;   /* |= does not work properly on 32 bit regs */
    tempReg &= ~DMACR1_DWB;
    *VMECHIP2_DMACR1 = tempReg;

    intUnlock(lockKey);

    printf(" Done\n");

#ifdef INCLUDE_ANTARES
    printf(" ANTARES_POOL_ADRS = %x\n",ANTARES_POOL_ADRS );
    printf(" ANTARES_POOL_SIZE = %x\n",ANTARES_POOL_SIZE );
#else
    printf(" ANTARES_POOL Not_included\n");
#endif
#ifdef INCLUDE_BURST_POOL
    printf(" ADP BURST_POOL_ADRS = %x\n",BURST_POOL_ADRS );
    printf(" ADP BURST_POOL_SIZE = %x\n",BURST_POOL_SIZE );
#endif
    if (sysProcNumGet() == 0)
    {
      printf(" BP_MEM_ADRS =       %x\n",BP_MEM_ADRS );
      printf(" BP_MEM_SIZE =       %x\n",BP_MEM_SIZE );
    }
    else
      printf(" BP_MEM_OFF_BOARD\n");

    /* register mmu diagnostics to Cmnd Processor */
    Log_Cmnd(NO_PASSWORD, "map167Bd", "Display the MMU memory map",
                      map167Bd, 1);
}

int temp;
void showMmuRegs()
{
#ifdef NEW_ASSEMBLER
    asm ("movec tc, a0");
    asm ("movel a0,_temp");
    printf("tc = %x\n",temp);
    asm ("movec cacr, a0");
    asm ("movel a0,_temp");
    printf("cacr = %x\n",temp);
    asm ("movec urp, a0");
    asm ("movel a0,_temp");
    printf("urp = %x\n",temp);
    asm ("movec srp, a0");
    asm ("movel a0,_temp");
    printf("srp = %x\n",temp);
    asm ("movec itt0, a0");
    asm ("movel a0,_temp");
    printf("itt0 = %x\n",temp);
    asm ("movec itt1, a0");
    asm ("movel a0,_temp");
    printf("itt1 = %x\n",temp);
    asm ("movec dtt0, a0");
    asm ("movel a0,_temp");
    printf("dtt0 = %x\n",temp);
    asm ("movec dtt1, a0");
    asm ("movel a0,_temp");
    printf("dtt1 = %x\n",temp);
#else
    asm (".word 0x4e7a,0x8003");	/* movec tc,a0 */
    asm ("movel a0,_temp");
    printf("tc = %x\n",temp);
    asm (".word 0x4e7a,0x8002");	/* movec cacr,a0 */
    asm ("movel a0,_temp");
    printf("cacr = %x\n",temp);
    asm (".word 0x4e7a,0x8806");	/* movec urp,a0 */
    asm ("movel a0,_temp");
    printf("urp = %x\n",temp);
    asm (".word 0x4e7a,0x8807");	/* movec srp,a0 */
    asm ("movel a0,_temp");
    printf("srp = %x\n",temp);
    asm (".word 0x4e7a,0x8004");	/* movec itt0,a0 */
    asm ("movel a0,_temp");
    printf("itt0 = %x\n",temp);
    asm (".word 0x4e7a,0x8005");	/* movec itt1,a0 */
    asm ("movel a0,_temp");
    printf("itt1 = %x\n",temp);
    asm (".word 0x4e7a,0x8006");	/* movec dtt0,a0 */
    asm ("movel a0,_temp");
    printf("dtt0 = %x\n",temp);
    asm (".word 0x4e7a,0x8007");	/* movec dtt1,a0 */
    asm ("movel a0,_temp");
    printf("dtt1 = %x\n",temp);
#endif
}

/***********************************************************************
* Write Protect the Application and VxWorks Code Space                 *
*                                                                      *
* Routine:          writeProtect()                                     *
*                                                                      *
* Description:      Changes the page table descriptors to write        *
*                   protect the code space.                            *
*                                                                      *
* Calling Seq:      writeProtect()                                     *
*                                                                      *
* Return param:     none                                               *
*                                                                      *
************************************************************************/
int CACR;

void writeProtect()
{
    short        j;
    unsigned int addr;    /* address counter for table construction */

    /* Save Cache Control Reg */
#ifdef NEW_ASSEMBLER
    asm ("movec cacr, a0");
    asm ("movel a0,_CACR");
#else
    asm (".word 0x4e7a,0x8002");	/* movec cacr,a0 */
    asm ("movel a0,_CACR");
#endif

    turnCacheOff();

    /* We also need to disable page translation so we can write to tables */
    /* set up data transparent translation reg 0 to translate everything  */
    dataTransTransReg0.address   = 0x00;    /* from address 0x00000000 */
    dataTransTransReg0.addrmask  = 0xff;    /*   to address 0xffffffff */
    dataTransTransReg0.e         = 1;       /* enable transparent transl */
    dataTransTransReg0.sfield    = 0x3;     /* ignore FC2 matching */
    dataTransTransReg0.zero      = 0;
    dataTransTransReg0.u1        = 0;
    dataTransTransReg0.u0        = 0;
    dataTransTransReg0.zero1     = 0;
    dataTransTransReg0.cm        = MMU_INHIB_SERIAL;
    dataTransTransReg0.zero2     = 0;
    dataTransTransReg0.wp        = MMU_RDWR;
    dataTransTransReg0.zero3     = 0;

#ifdef NEW_ASSEMBLER
    /* Set up Transparent Translation Registers */
    asm ("movel _dataTransTransReg0, a0");
    asm ("movec a0, dtt0");
    asm (".word 0xf518");

    /* Disable Page Table Translation */
    asm ("movel #0, a0");
    asm ("movec a0, tc");
#else
    /* Set up Transparent Translation Registers */
    asm ("movel _dataTransTransReg0, a0");
    asm (".word 0x4e7b,0x8006");	/* movec a0, dtt0 */
    asm (".word 0xf518");

    /* Disable Page Table Translation */
    asm ("movel #0, a0");
    asm (".word 0x4e7b,0x8003");	/* movec a0, tc */
#endif

    /*****************************************/
    /* change C table entries for code space */
    /*****************************************/
    
    pC000T = pCDescCodeStart;
    for (addr = VX_CODE_SPACE; addr < VX_DATA_SPACE; )
    {
      createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RONL,MMU_PDT_RESIDENT,addr); 

      addr += EIGHT_KBYTE;
    }
    
    pC000T = pCDescapplicCodeStart;
    for (addr = applicCodeStart; addr < (applicCodeStart + applicCodeSize); )
    {
      createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RONL,MMU_PDT_RESIDENT,addr); 

      addr += EIGHT_KBYTE;
    }

    /* restore data transparent translation reg 0 */
    dataTransTransReg0.address   = 0x10;    /* from address 0x10000000 */
    dataTransTransReg0.addrmask  = 0x0f;    /*   to address 0x1fffffff */
    dataTransTransReg0.e         = 1;       /* enable transparent transl */
    dataTransTransReg0.sfield    = 0x3;     /* ignore FC2 matching */
    dataTransTransReg0.zero      = 0;
    dataTransTransReg0.u1        = 0;
    dataTransTransReg0.u0        = 0;
    dataTransTransReg0.zero1     = 0;
    dataTransTransReg0.cm        = MMU_INHIB_SERIAL;
    dataTransTransReg0.zero2     = 0;
    dataTransTransReg0.wp        = MMU_RDWR;
    dataTransTransReg0.zero3     = 0;

#ifdef NEW_ASSEMBLER

    /* Set up Transparent Translation Registers */
    asm ("movel _dataTransTransReg0, a0");
    asm ("movec a0, dtt0");
    asm (".word 0xf518");

    /* Enable Translation */
    asm ("movel #0, a0");
    asm ("movew _transCntlReg, a0");
    asm ("movec a0, tc");
#else

    /* Set up Transparent Translation Registers */
    asm ("movel _dataTransTransReg0, a0");
    asm (".word 0x4e7b,0x8006");	/* movec a0, dtt0 */
    asm (".word 0xf518");

    /* Enable Translation */
    asm ("movel #0, a0");
    asm ("movew _transCntlReg, a0");
    asm (".word 0x4e7b,0x8003");	/* movec a0, tc */
#endif

  
    /* Restore Cache Control Reg */
#ifdef NEW_ASSEMBLER
    asm ("movel _CACR, a0");
    asm ("movec a0, cacr");
#else
    asm ("movel _CACR, a0");
    asm (".word 0x4e7b,0x8002");	/* movec a0, cacr */
#endif
}

/***********************************************************************
* Don't Write Protect the Application and VxWorks Code Space           *
*                                                                      *
* Routine:          unProtect()                                        *
*                                                                      *
* Description:      Changes the page table descriptors to no longer    *
*                   write protect the code space.                      *
*                                                                      *
* Calling Seq:      unProtect()                                        *
*                                                                      *
* Return param:     none                                               *
*                                                                      *
************************************************************************/

void unProtect()
{
    short        j;
    unsigned int addr;    /* address counter for table construction */

    /* Save Cache Control Reg */
#ifdef NEW_ASSEMBLER
    asm ("movec cacr, a0");
    asm ("movel a0,_CACR");
#else
    asm (".word 0x4e7a,0x8002");	/* movec cacr,a0 */
    asm ("movel a0,_CACR");
#endif

    turnCacheOff();

    /* We also need to disable page translation so we can write to tables */
    /* set up data transparent translation reg 0 to translate everything  */
    dataTransTransReg0.address   = 0x00;    /* from address 0x00000000 */
    dataTransTransReg0.addrmask  = 0xff;    /*   to address 0xffffffff */
    dataTransTransReg0.e         = 1;       /* enable transparent transl */
    dataTransTransReg0.sfield    = 0x3;     /* ignore FC2 matching */
    dataTransTransReg0.zero      = 0;
    dataTransTransReg0.u1        = 0;
    dataTransTransReg0.u0        = 0;
    dataTransTransReg0.zero1     = 0;
    dataTransTransReg0.cm        = MMU_INHIB_SERIAL;
    dataTransTransReg0.zero2     = 0;
    dataTransTransReg0.wp        = MMU_RDWR;
    dataTransTransReg0.zero3     = 0;

#ifdef NEW_ASSEMBLER
    /* Set up Transparent Translation Registers */
    asm ("movel _dataTransTransReg0, a0");
    asm ("movec a0, dtt0");
    asm (".word 0xf518");

    /* Disable Page Table Translation */
    asm ("movel #0, a0");
    asm ("movec a0, tc");
#else
    /* Set up Transparent Translation Registers */
    asm ("movel _dataTransTransReg0, a0");
    asm (".word 0x4e7b,0x8006");	/* movec a0, dtt0 */
    asm (".word 0xf518");

    /* Disable Page Table Translation */
    asm ("movel #0, a0");
    asm (".word 0x4e7b,0x8003");	/* movec a0, tc */
#endif

    /***********************************************/
    /* change B and C table entries for code space */
    /***********************************************/
    
    pC000T = pCDescCodeStart;
    for (addr = VX_CODE_SPACE; addr < VX_DATA_SPACE; )
    {
      createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RDWR,MMU_PDT_RESIDENT,addr); 
      addr += EIGHT_KBYTE;
    }

    pC000T = pCDescapplicCodeStart;
    for (addr = applicCodeStart; addr < (applicCodeStart + applicCodeSize); )
    {
      createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RDWR,MMU_PDT_RESIDENT,addr); 

      addr += EIGHT_KBYTE;
    }

    /* restore data transparent translation reg 0 */
    dataTransTransReg0.address   = 0x10;    /* from address 0x10000000 */
    dataTransTransReg0.addrmask  = 0x0f;    /*   to address 0x1fffffff */
    dataTransTransReg0.e         = 1;       /* enable transparent transl */
    dataTransTransReg0.sfield    = 0x3;     /* ignore FC2 matching */

    /* restore data transparent translation reg 0 */
    dataTransTransReg0.address   = 0x10;    /* from address 0x10000000 */
    dataTransTransReg0.addrmask  = 0x0f;    /*   to address 0x1fffffff */
    dataTransTransReg0.e         = 1;       /* enable transparent transl */
    dataTransTransReg0.sfield    = 0x3;     /* ignore FC2 matching */
    dataTransTransReg0.zero      = 0;
    dataTransTransReg0.u1        = 0;
    dataTransTransReg0.u0        = 0;
    dataTransTransReg0.zero1     = 0;
    dataTransTransReg0.cm        = MMU_INHIB_SERIAL;
    dataTransTransReg0.zero2     = 0;
    dataTransTransReg0.wp        = MMU_RDWR;
    dataTransTransReg0.zero3     = 0;

#ifdef NEW_ASSEMBLER

    /* Set up Transparent Translation Registers */
    asm ("movel _dataTransTransReg0, a0");
    asm ("movec a0, dtt0");
    asm (".word 0xf518");

    /* Enable Translation */
    asm ("movel #0, a0");
    asm ("movew _transCntlReg, a0");
    asm ("movec a0, tc");
#else

    /* Set up Transparent Translation Registers */
    asm ("movel _dataTransTransReg0, a0");
    asm (".word 0x4e7b,0x8006");	/* movec a0, dtt0 */
    asm (".word 0xf518");

    /* Enable Translation */
    asm ("movel #0, a0");
    asm ("movew _transCntlReg, a0");
    asm (".word 0x4e7b,0x8003");	/* movec a0, tc */
#endif

  
    /* Restore Cache Control Reg */
#ifdef NEW_ASSEMBLER
    asm ("movel _CACR, a0");
    asm ("movec a0, cacr");
#else
    asm ("movel _CACR, a0");
    asm (".word 0x4e7b,0x8002");	/* movec a0, cacr */
#endif
}

/***********************************************************************
* TURN THE CACHE OFF FOR DEBUGGING                                     *
*                                                                      *
* Routine:          turnCacheOff()                                     *
*                                                                      *
* Description:      This routines turns the cache off                  *
*                                                                      *
* Calling Seq:      turnCacheOff()                                     *
*                                                                      *
* Return param:     none                                               *
*                                                                      *
* Characteristics:  
*                                                                      *
************************************************************************/
void turnCacheOff()
{

#ifdef NEW_ASSEMBLER
    /* push and invalidate caches */
    asm (".word 0xf4ff"); /*    asm ("cpusha bc"); */

    /* Disable Cache */
    asm ("movel #0, a0");
    asm ("movec a0, cacr");

#else
    /* push and invalidate caches */
    asm (".word 0xf4ff");
    /* Disable Cache */
    asm ("movel #0, a0");
    asm (".word 0x4e7b,0x8002");	/* movec a0, cacr */
#endif
}

/***********************************************************************
* TURN THE MMU OFF FOR REBOOT                                          *
*                                                                      *
* Routine:          turnMmuOff()                                       *
*                                                                      *
* Description:      This routines turns the mmu of by writing to the   *
*                   tc register and clearing the e bit                 *
*                                                                      *
* Calling Seq:      turnMmuOff()                                       *
*                                                                      *
* Return param:     none                                               *
*                                                                      *
* Characteristics:  
*                                                                      *
************************************************************************/
void turnMmuOff()
{

    /* push and invalidate caches */
    turnCacheOff();

    /* set up data transparent translation reg 0 */
    dataTransTransReg0.address   = 0x00;    /* from address 0x00000000 */
    dataTransTransReg0.addrmask  = 0xff;    /*   to address 0xffffffff */
    dataTransTransReg0.e         = 1;       /* enable transparent transl */
    dataTransTransReg0.sfield    = 0x3;     /* ignore FC2 matching */
    dataTransTransReg0.zero      = 0;
    dataTransTransReg0.u1        = 0;
    dataTransTransReg0.u0        = 0;
    dataTransTransReg0.zero1     = 0;
    dataTransTransReg0.cm        = MMU_INHIB_SERIAL;
    dataTransTransReg0.zero2     = 0;
    dataTransTransReg0.wp        = MMU_RDWR;
    dataTransTransReg0.zero3     = 0;

    /* set up instruction transparent translation reg 0 */
    instruTransTransReg0.address   = 0x00; /* from address 0x00000000 */
    instruTransTransReg0.addrmask  = 0xff; /*   to address 0xffffffff */
    instruTransTransReg0.e         = 1;       /* enable transparent transl */
    instruTransTransReg0.sfield    = 0x3;     /* ignore FC2 matching */
    instruTransTransReg0.zero      = 0;
    instruTransTransReg0.u1        = 0;
    instruTransTransReg0.u0        = 0;
    instruTransTransReg0.zero1     = 0;
    instruTransTransReg0.cm        = MMU_INHIB_SERIAL;
    instruTransTransReg0.zero2     = 0;
    instruTransTransReg0.wp        = MMU_RDWR;
    instruTransTransReg0.zero3     = 0;

#ifdef NEW_ASSEMBLER
    /* Set up Transparent Translation Registers */
    asm ("movel _dataTransTransReg0, a0");
    asm ("movec a0, dtt0");
    asm (".word 0xf518");
    asm ("movec a0, dtt1");
    asm (".word 0xf518");

    asm ("movel _instruTransTransReg0, a0");
    asm ("movec a0, itt0");
    asm (".word 0xf518");

    /* Disable Page Table Translation */
    asm ("movel #0, a0");
    asm ("movec a0, tc");
#else

    /* Set up Transparent Translation Registers */
    asm ("movel _dataTransTransReg0, a0");
    asm (".word 0x4e7b,0x8006");	/* movec a0, dtt0 */
    asm (".word 0xf518");
    asm (".word 0x4e7b,0x8007");	/* movec a0, dtt1 */
    asm (".word 0xf518");

    asm ("movel _instruTransTransReg0, a0");
    asm (".word 0x4e7b,0x8004");	/* movec a0, itt0 */
    asm (".word 0xf518");

    /* Disable Page Table Translation */
    asm ("movel #0, a0");
    asm (".word 0x4e7b,0x8003");	/* movec a0, tc */
#endif

#if FALSE
    /* Turn Off Snoop Control for PCC Chip2 Serial Port */
    *PCC2_SCC_RICR &= ~SCC_RICR_SINK_DATA;

    /* Turn Off Snoop Control for PCC Chip2 Lanc */
    *PCC2_LANC_BEICR &= ~LANC_BEICR_SINK_DATA;

    /* Turn Off Snoop Control when VME Slave */
    /* snoop option -> update snooped cache */
    /* NOTE errata says that inval. cache does not work properly for reads */

    /* Obtain VMEbus while changing snoop */
    tempReg = *VMECHIP2_DMACR1;   /* |= does not work properly on 32 bit regs */
    tempReg |= DMACR1_DWB;
    *VMECHIP2_DMACR1 = tempReg;

    tempReg = 0;
    while (!(tempReg & DMACR1_DHB)) /* wait til we have the bus */
      tempReg = *VMECHIP2_DMACR1;

    tempReg = *VMECHIP2_VSAMSR;
    tempReg &= ~VSAMSR2_SNP_WSD;
    tempReg &= ~VSAMSR1_SNP_WSD; 
    *VMECHIP2_VSAMSR = tempReg;

    *VMECHIP2_DMACR1 &= !DMACR1_DWB; /* Release VMEbus */

    /* Turn Off Snoop Control for VME DMA */
    /* snoop option -> update snooped cache */
    /* NOTE errata says that inval. cache does not work properly for reads */
    tempReg = *VMECHIP2_DMACR2;
    tempReg &= ~DMACR2_SINK_DATA;
    *VMECHIP2_DMACR2 = tempReg;
#endif
}
/***********************************************************************
* MAP ALL ADDRESS SPACE FOR 167 BOARD                                  *
*                                                                      *
* Routine:          map167Bd()                                         *
*                                                                      *
* Description:      This routines prints a map of the entire 4 Gig     *
                    address range as mapped in the mmu. A PTESTR       *
*                   instruction is executed on every location and the  *
*                   location attributes are determined in the          *
*                   translation table. This routine uses the routine   *
*                   mapAdrs.                                           *
*                                                                      *
* Calling Seq:      map167Bd()                                         *
*                                                                      *
* Return param:     none                                               *
*                                                                      *
* Characteristics:  A task is actually spawnded to generate the table  *
*                   so that the priority of the routine will be lower  *
*                   than the shell priority.                           *
*                                                                      *
*        Map format:                                                   *
*        XXXXXXXX->XXXXXXXX: Read-only       Enabled       User        * 
*                                                                      *
************************************************************************/
void map167Bd()
{
    taskSpawn("PMMUTask",MMU_TASK_PRIOR,VX_DEALLOC_STACK,MMU_TASK_STACK,
                                  (FUNCPTR) mapAdrs,0,0xFFFFFFFF);
}
    
void mapAdrs(U_INT start, U_INT stop)
{

    /* variable declaration */
    short    i;          /* loop variable */
    U_INT    addr;       /* address to be tested */
    U_INT    addrStep;   /* address increment */
    short    cacheStat,rdwrStat,accessStat,residentStat; /*Current attributes */

    addrStep = EIGHT_KBYTE;
    testAddrOld = testAddrNew = (U_INT *)0; 

    printf("\n");
    printf("This routine takes a short time to run - BE PATIENT\n\n");
    printf("ADDRESS RANGE           PERMISSIONS     CACHE           MODE\n");
    printf("-----------------------------------------------------------------\n");

    /* start loop with first address to be tested */
    for (addr=start; addr<stop; addr+=addrStep)
    { 
        testAddrNew = (U_INT*)addr;

#ifdef NEW_ASSEMBLER
        /* ptest on testAddr- returns MMU SR is copyOfSrNew and table 
           address in pTableAdrNew */
        asm ("movel #1,a0");
        asm ("movec a0, dfc");
        asm ("movel _testAddrNew, a0");
        asm ("ptestr a0"); 
        asm ("movec mmusr,a1");
        asm ("movel a1, _copyOfSrNew");

#else
        /* ptest on testAddr- returns MMU SR is copyOfSrNew and table 
           address in pTableAdrNew */
        asm ("movel #1,a0");
        asm ("movec a0, dfc");
        asm (".word 0x4e7b,0x8001");	/* movec a0,dfc */
        asm ("movel _testAddrNew, a0");
        asm (".word 0xf568");		/* ptestr a0 */
        asm (".word 0x4e7a,0x9805");	/* movec mmusr,a1 */
        asm ("movel a1, _copyOfSrNew");
#endif

        /* if there are errors, report them & break for each case */
        if(copyOfSrNew.b)
        {
            printf("              %08x: **** BUS ERROR DURING TABLE SEARCH ****\n",addr);
            break;
        }

        /* on 1st entry - save attributes */
        if(addr == start)
        {
            copyOfSrOld = copyOfSrNew;
        }

        else if(testAddrNew >= (U_INT *)(stop-addrStep))
        {
            printAttribs(testAddrOld, (char *)testAddrNew +addrStep -1, copyOfSrOld);
            break;
        }

        else
        {
            /* if transition point  and not 1st entry */
            if((copyOfSrOld.r != copyOfSrNew.r) || 
               ((copyOfSrOld.r == TRUE) && (copyOfSrOld.cm  != copyOfSrNew.cm ||
               copyOfSrOld.wp !=  copyOfSrNew.wp|| copyOfSrOld.s   !=  copyOfSrNew.s)))
            {
              
                /* print old attributes */
                printAttribs(testAddrOld, (char *)testAddrNew -1, copyOfSrOld);

                copyOfSrOld = copyOfSrNew;
                testAddrOld = testAddrNew;
            }
        }
    }
}
/***********************************************************************
* PRINT ATTRIBUTES
*                                                                      *
* Routine:          printAttribs()                                     *
*                                                                      *
* Description:      This routine decodes the translation table         *
*                   descriptor given by the address param. The encoding*
*                   is the same for page and early term descriptors    * 
*                                                                      *
* Calling Seq:      printAttribs(address, type of printout)            *
*                                                                      *
* Return param:     none                                               *
*                                                                      *
* Characteristics:  
************************************************************************/
LOCAL void printAttribs(char* firstAddr, char* lastAddr, MMU_SR attributes)
{

    unsigned int ttaddr1;
    unsigned int ttaddr2;
    unsigned int temp;

    if((attributes.r) && (!attributes.t))/* if resident */
    {
      printf("%08x->%08x ",firstAddr, lastAddr);
        if(attributes.wp)
            printf ("     Read-Only   ");
        else
            printf ("     Read-Write  ");
 
        if(attributes.cm == MMU_EN_WRITETHROUGH)
            printf ("    Writethrough ");
        else if(attributes.cm == MMU_EN_COPYBACK)
            printf ("    CopyBack     ");
        else if(attributes.cm == MMU_INHIB_SERIAL)
            printf ("    Off/Serial   ");
        else
            printf ("    Off/NotSerial");

        if(attributes.s)
            printf ("   Supv Only\n");
        else
            printf ("   User/Supv\n");
    }
    else if ((attributes.r) && (attributes.t))
    {
#ifdef NEW_ASSEMBLER
      asm ("movec dtt0, a0");
      asm ("movel a0, _dataTransTransReg0");
      asm ("movec dtt1, a0");
      asm ("movel a0, _dataTransTransReg1");
#else
      asm (".word 0x4e7a,0x8006");	/* movec dtt0,a0 */
      asm ("movel a0, _dataTransTransReg0");
      asm (".word 0x4e7a,0x8007");	/* movec dtt1,a0 */
      asm ("movel a0, _dataTransTransReg1");
#endif
      if(dataTransTransReg0.e)
      {
        ttaddr1 = (dataTransTransReg0.address & ~dataTransTransReg0.addrmask) <<24;

        ttaddr2 = ((dataTransTransReg0.address | dataTransTransReg0.addrmask) <<24) | 0xffffff;
        if((ttaddr1 >= firstAddr) && (ttaddr1 <= lastAddr))
        {
          printf("%08x->%08x ",ttaddr1, ttaddr2);
          if(dataTransTransReg0.wp)
              printf ("     Read-Only   ");
          else
              printf ("     Read-Write  ");
   
          if(dataTransTransReg0.cm == MMU_EN_WRITETHROUGH)
              printf ("    Writethrough ");
          else if(dataTransTransReg0.cm == MMU_EN_COPYBACK)
              printf ("    CopyBack     ");
          else if(dataTransTransReg0.cm == MMU_INHIB_SERIAL)
              printf ("    Off/Serial   ");
          else
              printf ("    Off/NotSerial");

          if(dataTransTransReg0.sfield == 00)
              printf ("   User Only\n");
          else if(dataTransTransReg0.sfield == 01)
              printf ("   Supv Only\n");
          else
              printf ("   User/Supv\n");

          for(temp = (dataTransTransReg0.addrmask & 0xff); (temp & 1); temp = temp >> 1);

          if(temp != 0)
            printf("WARNING: Above Transparent Translation has holes in it \n");
        }
      }

      if(dataTransTransReg1.e)
      {
        ttaddr1 = (dataTransTransReg1.address & ~dataTransTransReg1.addrmask) <<24;

        ttaddr2 = ((dataTransTransReg1.address | dataTransTransReg1.addrmask) <<24) | 0xffffff;
        if((ttaddr1 >= firstAddr) && (ttaddr1 <= lastAddr))
        {
          printf("%08x->%08x ",ttaddr1, ttaddr2);
          if(dataTransTransReg1.wp)
              printf ("     Read-Only   ");
          else
              printf ("     Read-Write  ");
   
          if(dataTransTransReg1.cm == MMU_EN_WRITETHROUGH)
              printf ("    Writethrough ");
          else if(dataTransTransReg1.cm == MMU_EN_COPYBACK)
              printf ("    CopyBack     ");
          else if(dataTransTransReg1.cm == MMU_INHIB_SERIAL)
              printf ("    Off/Serial   ");
          else
              printf ("    Off/NotSerial");

          if(dataTransTransReg1.sfield == 00)
              printf ("   User Only\n");
          else if(dataTransTransReg1.sfield == 01)
              printf ("   Supv Only\n");
          else
              printf ("   User/Supv\n");

          for(temp = (dataTransTransReg1.addrmask & 0xff); (temp & 1); temp = temp >> 1);

          if(temp != 0)
            printf("WARNING: Above Transparent Translation has holes in it \n");
        }
      }

    }
    else
    {
      printf("%08x->%08x ",firstAddr, lastAddr);
      printf ("   Not Resident\n");
    }
} 

/***********************************************************************
* CREATE DESCRIPTOR 
*                                                                      *
* Routine:          createDesc()                                       *
*                                                                      *
* Description:      This routine creates a generic translation table   *
*                   descriptor according to the format specified for   *
*                   a long format descriptor in the 68030 manual.      *
*                                                                      *
* Calling Seq:      createDesc(...)                                    *
*                                                                      *
* Return param:     none                                               *
*                                                                      *
* Characteristics:                                                     *
*                   Since this is a '1 routine fits all' routine, not  *
*                   all of the parameters are meaningful for every     *
*                   descriptor type.                                   *
*                                                                      *
************************************************************************/

int prin = 0;

LOCAL void createADesc(LVL_A_TBL_ENTRY *tableAEntry, int wp, int valid,
                      LVL_B_TBL_ENTRY *tableBEntry)
{
    tableAEntry ->address   = ((unsigned int)tableBEntry) >> 9;
    tableAEntry ->reserved  = 0;
    tableAEntry ->used      = 0;
    tableAEntry ->wp        = wp;          /* set write protect */
    tableAEntry ->udt       = valid;       /* set descriptor type */
    return;
}  

LOCAL void createBDesc(LVL_B_TBL_ENTRY *tableBEntry, int wp, int valid,
                      PAGE_ENTRY *tableCEntry)
{
    tableBEntry ->address   = ((unsigned int)tableCEntry) >> 7;
    tableBEntry ->reserved  = 0;
    tableBEntry ->used      = 0;
    tableBEntry ->wp        = wp;          /* set write protect */
    tableBEntry ->udt       = valid;       /* set descriptor type */
    return;
}  

LOCAL void createCDesc(PAGE_ENTRY *pageEntry, int global, int sup, int cm, 
                      int wp, int valid, unsigned int pageAddr)
{
    pageEntry ->address   = ((unsigned int)pageAddr) >> 13;
    pageEntry ->ur        = 0;
    pageEntry ->global    = global; 
    pageEntry ->u1        = 0;
    pageEntry ->u0        = 0;
    pageEntry ->s         = sup;         /* supervisor/user */
    pageEntry ->cm        = cm;          /* cache mode */
    pageEntry ->m         = 0;           /* set modified field */
    pageEntry ->u         = 0;           /* set used field */
    pageEntry ->wp        = wp;          /* set write protect */
    pageEntry ->pdt       = valid;       /* set descriptor type */

    return;
}  

From daemon@vxw.ee.lbl.gov  Wed Apr 29 04:00:29 1992
From: daemon@vxw.ee.lbl.gov
Date: Wed Apr 29 04:00:37 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Apr 29 04:00:22 PDT 1992

        Subject: Re: distributed vxWorks!
        Subject: Re: chomped on by a compiler optimization
        Subject: Modifying interrupt stack placement on VxWorks 5.0.3
        Subject: Re: chomped on by a compiler optimization

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: distributed vxWorks!
Date: 28 Apr 1992 13:47:33 GMT
From: lewis@bevsun.bev.lbl.gov (Steve Lewis)
Organization: Lawrence Berkeley Laboratory, California
Message-ID: <22995@dog.ee.lbl.gov>
References: <9204271255.AA03190@efftoo.boeing.com>

In article <9204271255.AA03190@efftoo.boeing.com> crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com> writes:
>...
>Heck, I'll settle for multi-processor semaphores.  No, wait a minute,
>I'll settle for multi-processor semaphores that only work on the most
>popular CPU boards.  Or how about MPSs that work on one or two boards....
>...

Bob, I agree whole-heartedly.  At every Users' group meeting I have attended,
I have spoken out for such a facility.  I have even pointed out that a
competitor, SCG, with their pSOS+m product, has offered this functionality
(and more) since about 1986--they really offer a good multi-processor
environment.  (They were always weak in TCP/IP support, however.)

WRS has insisted that sockets across the backplane are sufficient...not clear
on the concept!

- -- 
	Steve Lewis, Group Leader		SALewis@LBL.gov
	Computer Controls			Mail Stop 64-121
	Lawrence Berkeley Laboratory		Tel: 510/486-7702
	Berkeley, CA 94720			Fax: 510/486-5788

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: chomped on by a compiler optimization
Date: Tue, 28 Apr 1992 14:49:43 GMT
From: rg@msel.unh.edu (Roger Gonzalez)
Organization: UNH Marine Systems Engineering Lab
Message-ID: <RG.92Apr28094943@nymph.msel.unh.edu>
References: <RG.92Apr27152732@nymph.msel.unh.edu>
Sender: news@nic.unh.edu (USENET News System)

Wow, neat.  When I figured out how to declare the register as volatile, (the
- -traditional option had been getting in my way) the code was optimized to
something pretty slick!

It noticed that I was and-ing a byte with 0x80 to see if the top bit was set;
so it changed the code to just check to see if the byte was negative.

That's a pretty obscure optimization!

Here is another place where I need to have a keyword like "volatile", but I
don't think it exists:

On this hardware I am using, there is an 8 bit index register i that you vary to
change which slot three other registers (r, g, and b) point to.  In other
words, to set g[123], you first set i to 123, and then write to the g
register.

Am I mistaken, or would the optimizer notice that I'm writing to the same spot
repeatedly in a loop, nuke the loop, and reduce it to the last values
assigned?

What would be the appropriate way to protect this from happening, without
completely turning the optimizer off?

Thanks,
Roger

- --
"The question of whether a computer can think is no more interesting
 than the question of whether a submarine can swim" - Edsger W. Dijkstra 

Roger Gonzalez   -  rg@msel.unh.edu
Division of Bit Banging and Reluctant Robotics
UNH Marine Systems Engineering Laboratory, Durham, NH  03824-3525
(603) 862-4600 -4399 (fax)

---------------------------

Newsgroups: comp.os.vxworks
Subject: Modifying interrupt stack placement on VxWorks 5.0.3
Date: Tue, 28 Apr 1992 15:14:51 GMT
From: srangachar@hns.com (Suresh Rangachar)
Organization: Hughes Network Systems Inc.
Message-ID: <1992Apr28.151451.12131@hns.com>
Sender: news@hns.com (USENET news system)

Hi,
      We need to locate the interrupt stack into a different static RAM area after initialization. (the OS gets interrupt stack location from system memory pool). I tried to post a software interrupt and modify sp in the interrupt handler and  that did not seem to fix it. ANy suggestions ?

suresh rangachar
Hughes Network systems
srangachar@hns.com (301-601-4083)

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: chomped on by a compiler optimization
Date: Wed, 29 Apr 92 06:31:18 GMT
From: marcu@leland.Stanford.EDU (Marc Albert Ullman)
Organization: DSG, Stanford University, CA 94305, USA
Message-ID: <1992Apr29.063118.736@leland.Stanford.EDU>
References: <RG.92Apr27152732@nymph.msel.unh.edu> <RG.92Apr28094943@nymph.msel.unh.edu>
Sender: news@leland.Stanford.EDU (Mr News)

In article <RG.92Apr28094943@nymph.msel.unh.edu> rg@msel.unh.edu (Roger Gonzalez) writes:
>
>Here is another place where I need to have a keyword like "volatile", but I
>don't think it exists:
>
>On this hardware I am using, there is an 8 bit index register i that you vary to
>change which slot three other registers (r, g, and b) point to.  In other
>words, to set g[123], you first set i to 123, and then write to the g
>register.
>
>Am I mistaken, or would the optimizer notice that I'm writing to the same spot
>repeatedly in a loop, nuke the loop, and reduce it to the last values
>assigned?

Not if that location was declared "volatile".

>What would be the appropriate way to protect this from happening, without
>completely turning the optimizer off?

"volatile" is exactly what you need here as well.  Declaring something to be
volatile tells the compiler that "something else" is looking at that memory
location asychronously to the compiler generated accesses, and thus no
programmatic access can be left out (e.g. your writes).

- --Marc Ullman
  Stanford University

---------------------------

End of New-News digest
**********************

From rayssd!pike.ssd.ray.com!fjr@uunet.uu.net  Wed Apr 29 08:28:55 1992
From: "Roeber" <fjr@pike.ssd.ray.com>
Date: Wed Apr 29 08:29:02 PDT 1992
Subject: Re:  using mmus in realtime
>  Submitted-by briggs@thalia.jpl.nasa.gov  Tue Apr 28 08:16:48 1992
>  Submitted-by: briggs@thalia.jpl.nasa.gov (Clark Briggs)

>  If mmus are less expensive in that you get one naturally and they are always
>  on anyway, doesnt that make a few software features a lot cheaper to get?
>  Like protected logical address spaces for tasks.  The task would run at the
>  same speed but the context would be larger (a concern during switching,
>  depending on the mmu) and the system must be prepared to handle the
> exceptions.

I feel that getting VxWorks to use all these features supported by a MMU is
a mistake since it will make it look more like a incomplete UNIX than the
fast kernel it is now.  The amount of context required to do task level
memory mapping is quite large on most systems (you need lots of page tables).
The bigger issues revolve around the fact that VxWorks is designed to be a
fully shared memory architecture and everything runs in the same mode
(supervisor).  With normal mapped systems, things like shared data and
shared code (libraries) are a real bear to set up.  VxWorks would likely have
to be restructured to use separate kernel and and user modes.  I could see
some simple support like maybe just allowing text areas to be protected as
execute only but anything much more would require a boatload of rework.

>  I always liked the sound of Masscomp's rtu where the user could scale the Unix
>  features down to a kernel.  You could chose to memory lock your code, or not
>  use certain system functions.  I think you always got a private logical space.
>  I was told the minimal kernel would run in single digit multiples of real
>  kernels like VxWorks on such metrics as context switch times or semaphore
>  gives.  Plus they have had multiprocessing for a while and can put 2 or 4
>  68040s on a (9U?) board.  Yeah, I always thought that sounded nice.

Some of these UNIX versions with good real time multiprocessor features (my
favorite is SGI IRIX) are really nice to use from a development perspective.
They make errors a lot easier to find than in a shared everything environment
like VxWorks but it all boils down to that several times slower value you
mention.  In a large multitasking system on those UNIX versions, executive
overhead can easily start approaching 30% or more of your CPU.  Things do run
a lot slower than on VxWorks with the same hardware platform.  I think it is
instructive to look at the new POSIX standards.  The 1003.13 (Realtime
profiles) group, that us and WRS have people on, is looking at different
"flavors" of POSIX to satisfy different target needs.  There are 4 profiles
covering everything from embedded controllers up to full blown multiprocessors.
The key point is that the different profiles support different levels of
capabilities so you can get the desired execution speed and program size.  My
feeling is that one kernel won't cover all four domains (well).  Trying to
make one piece of software do too many jobs makes it handle all of them in
a mediocre fashion.   Fred

    ______________________________________________________________
   |  Fred J Roeber,  Raytheon Submarine Signal Division          |
   |  1847 West Main Road,  Mail Stop 188                         |
   |  Portsmouth, RI  02871-1087  (401) 847-8000 (X4205)          |
   |                                                              |
   |      {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr             |
   |______________________________________________________________|

From interf!zeus!brackett@uunet.uu.net  Wed Apr 29 08:47:20 1992
From: interf!zeus!brackett@uunet.uu.net (Todd Brackett)
Date: Wed Apr 29 08:47:31 PDT 1992
Subject: Re: distributed vxWorks
Hi!!

For everybody's reference, Dave Wilner of WRS announced at the West Coast user
group meeting (10 April 92) that WRS will release a new version (5.x ?) of 
vxWorks which does contain multiprocessor connection on the backplane.  

(Yes they have seen the light).  

This connection is not TCP/IP driven and so will
supply the yearned for "tight coupling" that we all have been whining about
for years.  As usual he was very vague about dates for release but was willing
to give away a "sometime late this year".  The system will include the
semaphore and message queue IPC functions.

With respect to questions I have heard about releasing beta copies on the
net. I think this is something that WRS, a company with a real support
department, that costs money, will never do.  

You have to consider the fact that unlike the GNU world they are in business 
to make money. Let's face it, "support" is a necessary money sink in any 
company. I don't think they would want to be associated with anything as half
baked as a netwide "beta".  I am sure that if one was really interested in that 
you could make a one on one beta site arrangement with them.  

If there are "extensions" that we want as users and we as users are willing 
to become more GNU-like in our handling of this (eg. the UG archives) then we 
can become very influential with WRS.  I encourage any of you, especially those
in or associated with government projects, to let us know about your 
"extensions" so they can be added to the public domain. 

I doubt that WRS would have responed at all on this and other topics 
if it weren't for the efforts of this exploder/newsgroup and the user
group meetings.  Let's consider this our first victory.

Regards,

PS See you all at the UG in Boston in September

-------------------------------------------------------
|Todd S. Brackett                 |Voice:703 790 8500 |
|Interferometrics, Inc.           |FAX:  703 848 2492 |
|8150 Leesburg Pike               |                   |
|Vienna, VA 22182                 |                   |
|-----------------------------------------------------|
|Internet:brackett@interf.com                         |
|Uunet:   uunet!interf!brackett                       |
-------------------------------------------------------

From tlusco@inquisitor.gsfc.nasa.gov  Wed Apr 29 09:40:57 1992
From: tlusco@inquisitor.gsfc.nasa.gov (C. Tom Lusco)
Date: Wed Apr 29 09:41:04 PDT 1992
Subject: FDDI

Does anyone out there have experience with FDDI in a VxWorks system?  Any
information you can give would be greatly appreciated.

Tom Lusco

tlusco@kraken.gsfc.nasa.gov

From symborski@hns.com  Wed Apr 29 11:33:17 1992
From: symborski@hns.com (Carl Symborski)
Date: Wed Apr 29 11:33:25 PDT 1992
Subject: RE: bit-fields, volatile, ANSI-C

> On Mon Apr 20 23:26:31 1992 (David N. Wilner) wrote:
> 
> ....  Well, in actuality there was only one
> module in the kernel that made this assumption.  This was in tyLib
> in which we kept a word of software status bits indicating the state
> of the serial line.
> . . . 
> However, it was clear that it would be a problem for our RISC ports.  
> The fix was quite simple: we changed all the bit-field flags to byte-wide
> flags, the setting of which are atomic.  This is the way tyLib is
> currently distributed in all our RISC ports, and will be in all ports
> in future releases.

Folks,

Been catching up on my EMail post vacation and noticed the thread concerning
what assumptions can be made with atomic "C" functions, and alledged VxWorks
latent bugs on RISC based processors.  Had to comment on this one :-) ....

We certainly ran into this problem in the i960 implementation of Vx!!!
Yup, the problem was in the tylib and was discovered after *much* effort
during the development of one of our board support package.  Anyway we 
reported our results back to Intel and indirectly WR.  I know that there
is now a patch for this in the current 5.0.3 commercial release.  Glad to see
that the problem is resolved from now on.

Good discussion thread!

Carl Symborski
symborski@hns.com

From visicom!VisiCom.COM!trest@nosc.mil  Wed Apr 29 20:02:59 1992
From: Mike Trest <trest@visicom.com>
Date: Wed Apr 29 20:03:06 PDT 1992
Subject: Re:  using mmus in realtime
>  |  Fred J Roeber,  Raytheon Submarine Signal Division          |

> I think it is
>instructive to look at the new POSIX standards.  The 1003.13 (Realtime
>profiles) group, that us and WRS have people on, is looking at different
>"flavors" of POSIX to satisfy different target needs.  There are 4 profiles
>covering everything from embedded controllers up to full blown multiprocessors.
>The key point is that the different profiles support different levels of
>capabilities so you can get the desired execution speed and program size.  My
>feeling is that one kernel won't cover all four domains (well).  Trying to
>make one piece of software do too many jobs makes it handle all of them in
>a mediocre fashion.   Fred

I agree!  There is no single solution.  Lets keep the granular approach
where we can build a kernel with the facilities desired.  If we want
the features we pay the performance price.  BUT lets all keep the
inputs here and to WRS to define and clarify what we want.  We are,
after all, the market place that WRS is trying to satisfy.

..mike..

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 457 2111
Technology Group                Fax:   619 457 0888
VisiCom Laboratories            San Diego, CA 
====================================================

From daemon@vxw.ee.lbl.gov  Thu Apr 30 04:00:26 1992
From: daemon@vxw.ee.lbl.gov
Date: Thu Apr 30 04:00:35 PDT 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Apr 30 04:00:19 PDT 1992

        Subject: gcc et al
        Subject: Re: gcc et al
        Subject: Re: vme address questions
        Subject: Re: gcc et al

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: gcc et al
Date: 29 Apr 92 15:04:48 GMT
From: rg@msel.unh.edu (Roger Gonzalez)
Organization: UNH Marine Systems Engineering Lab
Message-ID: <RG.92Apr29100448@nymph.msel.unh.edu>
Sender: news@nic.unh.edu (USENET News System)

What are the changes to the build procedure in building gcc to make it into
the cross compiler that comes with vxworks?  I'd like to be able to build new
versions of it when they are released from gnu.  I'd like to do the same with
gas.

- -Roger

- --
"The question of whether a computer can think is no more interesting
 than the question of whether a submarine can swim" - Edsger W. Dijkstra 

Roger Gonzalez   -  rg@msel.unh.edu
Division of Bit Banging and Reluctant Robotics
UNH Marine Systems Engineering Laboratory, Durham, NH  03824-3525
(603) 862-4600 -4399 (fax)

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: gcc et al
Date: Wed, 29 Apr 92 18:16:41 GMT
From: marcu@leland.Stanford.EDU (Marc Albert Ullman)
Organization: DSG, Stanford University, CA 94305, USA
Message-ID: <1992Apr29.181641.28646@leland.Stanford.EDU>
References: <RG.92Apr29100448@nymph.msel.unh.edu>
Sender: news@leland.Stanford.EDU (Mr News)

In article <RG.92Apr29100448@nymph.msel.unh.edu> rg@msel.unh.edu (Roger Gonzalez) writes:
>
>What are the changes to the build procedure in building gcc to make it into
>the cross compiler that comes with vxworks?  I'd like to be able to build new
>versions of it when they are released from gnu.  I'd like to do the same with
>gas.

I don't know if the following comments are of any help but we have gotten
GCC V2.1 to work as a cross compiler for both C and C++ (with libg++ 2.0
and streams) from SPARC to 68K for VxWorks 5.0.2.  There are a number of 
subtleties that have to be addressed in order to get it all to work, and
immediate time constraints prevent me from providing more details here.
Suffice it to say, it can be make to work and work well.

- --Marc Ullman
  Stanford University

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: vme address questions
Date: 30 Apr 92 03:13:16 GMT
From: flash@austin.lockheed.com (James W. Melton)
Organization: "Lockheed Austin Division, 6800 Burleson Rd, Austin, TX 78744
Message-ID: <963@shrike.com>
References: <RG.92Apr27104805@nymph.msel.unh.edu> <HMP.92Apr27134737@squash.frc.ri.cmu.edu>

In article <HMP.92Apr27134737@squash.frc.ri.cmu.edu> hmp@frc2.frc.ri.cmu.edu (Henning Pangels) writes:
>
>In article <RG.92Apr27104805@nymph.msel.unh.edu> rg@msel.unh.edu (Roger Gonzalez) writes:
>
>>How does one specify VME address modifier codes to VxWorks?

[ stuff deleted ]

>Typically, the CPU board generates the AM codes based on the
>address specified. For example, most Motorola boards generate a short
>IO access for addresses above 0xffff0000.

[ stuff deleted ]

>In sysLib.c for your board, check out 
>sysLocalToBusAdrs() and sysBusToLocalAdrs() -- that should give you
>some insight.

Adress modes for non-Motorola boards may be a little hairier. I
spent a few hours one day wrestling with the Tadpole TP-41
addressing scheme. In the process I found a bug in
sysBusToLocalAdrs(). If anyone else has one of these beasties and
is interested in my experience, I will be happy to respond via
email.

LET ME EMPHASIZE: This was a TP-41 BSP specific problem. The other
boards (and BSPs) that I have used have worked just fine. The problem
has been reported to WRS and (presumably) will be fixed in the next
release.

The point is, if you have any interest in writing portable code,
you should use sysBusToLocalAdrs() and sysLocalToBusAdrs() rather
than assuming that 0xffff.... will generate a short address.
- ----
Jim Melton, novice guru
in person:  (512) 386-4303            | "So far as we know, our
voice mail: (512) 386-4486            |  computer has never had
fax:        (512) 386-4223            |  an undetected error"
e-mail:     flash@austin.lockheed.com |

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: gcc et al
Date: 30 Apr 92 05:08:38 GMT
From: hwajin@mondo.iphasew.com (Hwa-Jin Bae)
Organization: Interphase West, Santa Clara, CA
Message-ID: <HWAJIN.92Apr29220838@mondo.iphasew.com>
References: <RG.92Apr29100448@nymph.msel.unh.edu>
	<1992Apr29.181641.28646@leland.Stanford.EDU>
Sender: hwajin@iphasew.com

I'm running GCC 1.40 which is a production level compiler and is
mostly as good as the latest version as far as m68k code generation
goes (so I'm told by my contacts at Cygnus).

The compiler is setup to allow compilation on either sun3 or sun4
architecture machines to generate code for mc68020 type machines.
Actually the full setup I have here includes C & C++ compilers that
run on either architecture and generates code for mc68020, mc68000,
sparc, sun3, sun3x.  Setting up a complex configuration such as this
takes a bit of time.

In my experience (this was before the days of very useful Cygnus
"configure" script provided now with recent releases), the following
things need to be done to have a complex cross development environment
setup (that is, in addition to reading installation doc's and
doing/learning the standard stuff):

1. config.gcc may need modification; you may need to add special
   entries for your setup.

2. The default Makefile might not do the proper thing when creating
   a cross compiler.  I resolved this by using GNU make's 
   "include" directive which allows a configuration file to be
   included.  Inside the configuration file, MACH is defined to
   be the machine architecture for running the compiler, XMACH is
   defined to be machine architecture for target code.  The Makefile
   is then modified to set correct values for such things as:
	XCFLAGS, CC, AR, bindir, libdir, STANDARD_EXEC_PREFIX,
	and rules for the install: target
   This helps in keeping track of correct compilers for various
   combinations of host/target pairs.  The convention I use is:
   binaries reside in bin-`mach` directory and libraries reside
   in lib-`mach` directory.  For each type of compiler, correct
   versions of libraries much be provided.  For example,

	bin-sparc/mc68000-gcc (a compiler running on sparc but generates
				mc68000 code)

   needs lib-sparc/mc68000-gnulib et. al.  You can figure out the
   a whole list of combinations that can occur (there are a lot)
   to support a flexible environment.  My lib-sparc directory contains,
   for example the following files:

g++-include gcc-as gcc-cc1plus gcc-ccrt0.o gcc-cpp gcc-gccrt0.o
gcc-gnulib gcc-include gcc-ld icombine libg++.a mc68000-as mc68000-cc1
mc68000-cc1plus mc68000-ccrt0.o mc68000-cpp mc68000-g++-include
mc68000-gccrt0.o mc68000-gnulib mc68000-gnulib.old mc68000-include
mc68000-ld mc68000-lib mc68020-as mc68020-cc1 mc68020-cpp
mc68020-gnulib mc68020-gnulib.old mc68020-include mc68020-ld sparc-as
sparc-cc1 sparc-cpp sparc-gnulib sparc-include sparc-ld sun3-Fcrt1.o
sun3-Mcrt1.o sun3-as sun3-cc1 sun3-cpp sun3-crt0.o sun3-gnulib
sun3-include sun3-ld sun3-libc.a sun3-libc_p.a sun3-libg.a
sun3x-Fcrt1.o sun3x-Mcrt1.o sun3x-as sun3x-cc1 sun3x-cpp sun3x-crt0.o
sun3x-gnulib sun3x-include sun3x-ld sun3x-libc.a sun3x-libc_p.a
sun3x-libg.a

   and bin-sparc contains:

g++ g++dep gcc gdb gdb-old mc68000-g++ mc68000-gcc mc68020-gcc
mc68020-gcc-old ranlib sparc-gcc sparc-gdb sun3-gcc sun3x-gcc

3. When you're compiling for VxWorks, it's a good idea to do away with
   UNIX library routines.  GCC uses native compiler to generate many of
   gnulib routines (numeric conversion, etc.) which means that you'll
   get SunOS versions of these routines.  You can instead build
   SunOS independent equivalent routines using Kai-Uwe Bloem's 
   collection of numeric routines, available from various sources
   for free.

4. You'll also need GNU "binutils" for things such as ranlib, nm, and
   especially gas.

- --
Hwa-Jin Bae
Interphase West

---------------------------

End of New-News digest
**********************

From jjohnson@hns.com  Thu Apr 30 08:08:27 1992
From: jjohnson@hns.com (Jayne Johnson)
Date: Thu Apr 30 08:08:48 PDT 1992
Subject: RPC problem ?
We are using Vx960 5.0.3 (production ) GNU 1.3 (Intel release) and are 
experiencing a problem for initializing gdb960 over our T1 link. We are
not experiencing gdb960 problems when we initialize rdb task over the
ethernet. My question to the user community is : Can we use RPC clnt_control()
primitive to extend the timeout period for RPC before we execute rdbInit() or
is there something else we must configure in RPC for T1 communications 
to be allowed between the client and server debuggers? What host is the 
RDB trying to reach? In the GNU source can anyone direct me to the source
that does this registration?

At the workstation dcn7 we have gdb960 up and running:
 
At the target card ( over the T1 ) the Host table :

-> hostShow
hostname         inet address       aliases
--------         ------------       -------
localhost        127.0.0.1
dcn7             139.85.200.53
value = 0 = 0x0

At the target ( the other side of the T1 ) we execute :

-> rdbInit
value = 0 = 0x0
-> Cannot register service: RPC: Unable to send; errno = 65
rdbTask: couldn't register RDB service

At the target this is the Routing table entries:

-> routeShow

ROUTE NET TABLE
destination      gateway          flags  Refcnt  Use           Interface
------------------------------------------------------------------------
18.1.1.0         18.1.1.41        1      0       0             ei0
18.1.0.0         18.1.1.253       3      1       5             ti0
------------------------------------------------------------------------
ROUTE HOST TABLE
destination      gateway          flags  Refcnt  Use           Interface
------------------------------------------------------------------------
127.0.0.1        127.0.0.1        5      0       0             lo0
18.0.2.2         18.1.1.253       7      1       6             ti0
139.85.200.53    18.1.1.253       7      1       59            ti0
18.1.1.253       18.1.1.254       5      0       8             ti0
------------------------------------------------------------------------
value = 73 = 0x49 = 'I'

From thor@thor.atd.ucar.edu  Thu Apr 30 23:02:04 1992
From: thor@thor.atd.ucar.edu (Richard Neitzel)
Date: Thu Apr 30 23:02:17 PDT 1992
Subject: Monthly VxWorks archive posting
This is the monthly posting showing the current holdings in the VxWorks
Software Archive. To get more detailed infomation send email to:

vxworks_archive@ncar.ucar.edu

The message body must read:

send index
send index from vx
send index from unix
------------------------------------------------
VxWorks sources:

total 1629
-rw-r--r--  1 thor          238 Apr  1 08:02 MANIFEST
-rw-r--r--  1 thor        22132 Jun 18  1990 ansi.p1
-rw-r--r--  1 thor        22717 Jun 18  1990 ansi.p2
-rw-r--r--  1 thor        24174 Jun 18  1990 ansi.p3
-rw-r--r--  1 thor         8108 Jun 18  1990 ansi.patch1
-rw-r--r--  1 thor         2671 Jan  2  1990 benchmarks
-rw-r--r--  1 thor         7168 Jul 13  1989 bitcnt
-rw-r--r--  1 thor        11437 Feb 15  1991 c++builtin.shar
-rw-r--r--  1 thor        22330 Apr  4  1990 c++headers.p1
-rw-r--r--  1 thor        22775 Apr  4  1990 c++headers.p2
-rw-r--r--  1 thor        29052 Dec  6  1989 camaclib1
-rw-r--r--  1 thor        25095 Dec  6  1989 camaclib2
-rw-r--r--  1 thor        31005 Dec  6  1989 camaclib3
-rw-r--r--  1 thor        37770 Dec 21  1989 cbench.shar
-rw-r--r--  1 thor         7371 Jun 15  1990 cntsem_class.shar
-rw-r--r--  1 thor         5853 May 31  1989 crc.shar
-rw-r--r--  1 thor         8917 Oct  9  1990 deadman.shar
-rw-r--r--  1 thor        41669 Dec  6 14:07 dhrystones01
-rw-r--r--  1 thor        25681 Aug 29  1989 dt1451
-rw-r--r--  1 thor         5944 Apr 26  1989 fcompress.shar
-rw-r--r--  1 thor        11561 Nov  1  1991 flags_class.shar
-rw-r--r--  1 thor        44762 Jul 18  1990 force.p1
-rw-r--r--  1 thor        40154 Jul 18  1990 force.p2
-rw-r--r--  1 thor        80491 May  8  1989 force.shar
-rw-r--r--  1 thor         6106 Oct 10  1989 getdate
-rw-r--r--  1 thor         9774 Nov  2  1990 hkv30extintutil.shar
-rw-r--r--  1 thor         9206 Apr  1 08:07 index
-rw-r--r--  1 thor         2694 Oct  9  1990 ivecalloc.shar
-rw-r--r--  1 thor        27824 May 30  1989 jobCondLib
-rw-r--r--  1 thor        25014 May 30  1989 jobLib
lrwxrwxrwx  1 root           10 Aug 14  1991 jobcondlib -> jobCondLib
lrwxrwxrwx  1 root            6 Aug 14  1991 joblib -> jobLib
-rw-r--r--  1 thor        35245 Oct  9  1990 joblib2.p1
-rw-r--r--  1 thor        18110 Oct  9  1990 joblib2.p2
-rw-r--r--  1 thor         9079 Apr  2  1990 lclflag.shar
drwxr-xr-x  2 thor          512 Oct 31  1990 libX11
lrwxrwxrwx  1 root            6 Aug 14  1991 libx11 -> libX11
-rw-r--r--  1 thor        25077 Oct  9  1990 loadmeter.shar
-rw-r--r--  1 thor        10399 May  4  1989 math.shar
-rw-r--r--  1 thor        11950 May 30  1989 math2
-rw-r--r--  1 ftp         26655 Nov 15  1990 monitor.shar
-rw-r--r--  1 thor        18733 Jun 14  1990 msgque_class.shar
-rw-r--r--  1 thor        41667 Feb  5 11:39 ntpvx01
-rw-r--r--  1 thor        38524 Feb  5 11:39 ntpvx02
-rw-r--r--  1 thor        41997 Feb  5 11:39 ntpvx03
-rw-r--r--  1 thor        39218 Feb  5 11:39 ntpvx04
-rw-r--r--  1 thor        39625 Feb  5 11:39 ntpvx05
-rw-r--r--  1 thor        28741 Feb  5 11:39 ntpvx06
-rw-r--r--  1 thor        32516 Feb  5 11:39 ntpvx07
-rw-r--r--  1 thor        37119 Feb  5 11:39 ntpvx08
-rw-r--r--  1 thor        41643 Feb  5 11:39 ntpvx09
-rw-r--r--  1 thor        20494 Oct 31  1991 pipe.shar
-rw-r--r--  1 thor        15418 May 30  1989 poolLib
lrwxrwxrwx  1 root            7 Aug 14  1991 poollib -> poolLib
-rw-r--r--  1 thor        13204 Oct 31  1991 ring.shar
-rw-r--r--  1 thor         6614 May 31  1989 semCnt
lrwxrwxrwx  1 root            6 Aug 14  1991 semcnt -> semCnt
-rw-r--r--  1 thor         2308 Jan  2  1990 ss1.bnch
-rw-r--r--  1 thor        16225 Oct 10  1989 string.shar
-rw-r--r--  1 thor         8424 Apr  1 08:02 syslog.shar
-rw-r--r--  1 thor        15096 Oct  2  1991 task_class.shar
-rw-r--r--  1 thor        16171 Oct  9  1990 taskmon.shar
-rw-r--r--  1 thor        10523 May 31  1989 tod.shar
-rw-r--r--  1 thor        11747 Feb  4 09:49 tp41.shar
-rw-r--r--  1 thor        25790 Nov  8  1990 ty335.shar
-rw-r--r--  1 thor        25814 Apr 26  1989 vtape.shar
-rw-r--r--  1 thor        43671 Nov 22 14:05 vwcurses01
-rw-r--r--  1 thor        40180 Nov 22 14:05 vwcurses02
-rw-r--r--  1 thor        38308 Nov 22 14:05 vwcurses03
-rw-r--r--  1 thor        31181 Nov 22 14:05 vwcurses04
-rw-r--r--  1 thor        31798 Nov 22 14:05 vwcurses05
-rw-r--r--  1 thor        31459 Nov 22 14:05 vwcurses06
-rw-r--r--  1 thor        24279 Nov 22 14:05 vwcurses07
-rw-r--r--  1 thor         4636 Feb  4 11:50 vx_cplusplus
-rw-r--r--  1 thor        29720 Aug 28  1991 vxrsh.p1
-rw-r--r--  1 thor        26002 Aug 28  1991 vxrsh.p2
-rw-r--r--  1 thor        13713 Aug 28  1991 vxrsh.p3
-rw-r--r--  1 thor         4702 Jan 16 13:28 wdog_class
Unix sources:

total 82
-rw-r--r--  1 thor         1192 Mar 13  1990 index
drwxr-xr-x  2 thor          512 Mar 17 07:33 patch
-r--r--r--  1 thor        11744 Apr 11  1989 shar.shar
-rw-r--r--  1 thor        19698 Nov 15  1989 vxtool
-rw-r--r--  1 thor        21934 Jan 31  1990 vxview
-rw-r--r--  1 thor        14151 Feb  9  1990 vxview.patch
-r--r--r--  1 thor         9869 Feb  1  1989 xc.shar
drwxr-xr-x  2 thor          512 Feb 11  1990 xdbx

Richard Neitzel thor@thor.atd.ucar.edu          Torren med sitt skjegg
National Center For Atmospheric Research        lokkar borni under sole-vegg
Box 3000 Boulder, CO 80307-3000	                Gjo'i med sitt shinn
303-497-2057                                    jagar borni inn.