HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.arch
Subject: Re: Any use for Branch if Even/Odd ?
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 15 Dec 92 07:18:40 GMT
Distribution: world
Organization: The Wolery

andy@SAIL.Stanford.EDU (Andy Freeman) writes:
> In article <id.08RV.WYB@ferranti.com> peter@ferranti.com (peter da silva) writes:
> >Close. As I recall, DEC is very fond of using even/odd for true/false values,
> >and the VMS interface definition has a lot of even/odd status returns, so it's
> >likely these instructions are to make it run VMS real good.
> 
> Does anyone know why they preferred even/odd to >=0/<0?  Sometimes one
> has to test the sign bit, so why not use it whenever one can use any
> bit to split things into two classes?

VMS's error codes allow the severity to be encoded into the bottom three
bits of the code; 0=warning, 1=success, 2=error, 3=informational & 4=fatal.
(5,6 & 7 are unused).  In general, the low bit indicates whether something
worked or didn't.  This contrasts to other systems where you have one code
that means it worked, and umpteen which say it didn't.

The VAX architecture includes a couple of instructions that make the low
bit test.  These are:

	BLBC <src>, <branch-displacement>	Branch on low bit clear
	BLBS <src>, <branch-displacement>	Branch on low bit set

They're rather attractive to use, since the test and branch are in the 
same instruction.  Typical usage is:

	calls #0, routine
	blbc r0, error
or:
	calls #0, routine
	blbs 1$
	pushl R0
	calls #1, SYS$EXIT
    1$:

The latter is common due to the byte sized byte-relative branch
displacements that the VAX architecture is cursed with.  Shades of 6502...
(and the 6502 had smaller instructions to jump over).

--
Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand              +64-4-495-5052
From: leichter@zodiac.rutgers.edu
Newsgroups: comp.arch
Subject: Re: Any use for Branch if Even/Odd ?
Date: 15 Dec 92 19:47:52 GMT
Organization: Rutgers University Department of Computer Science

In article <1992Dec14.203631.16388@CSD-NewsHost.Stanford.EDU>,
andy@SAIL.Stanford.EDU (Andy Freeman) writes:
| In article <id.08RV.WYB@ferranti.com> peter@ferranti.com (peter da silva)
| writes:
|>Close. As I recall, DEC is very fond of using even/odd for true/false
|>values, and the VMS interface definition has a lot of even/odd status
|>returns, so it's likely these instructions are to make it run VMS real good.
| 
| Does anyone know why they preferred even/odd to >=0/<0?  Sometimes one
| has to test the sign bit, so why not use it whenever one can use any
| bit to split things into two classes?

It's tough to reconstruct that kind of decision years after the fact.  I can
suggest two ways in which using the bottom bit works better:

	- Both TRUE=1 and TRUE=-1 are reasonably common representations in
		existing languages.  Using the bottom bit works for both;
		using the top doesn't.

	- The actual representation of a VMS condition value is more complex
		than has been described so far.  Reading from the least signi-
		ficant bit, we have:

			Severity:  3 bits.  Bottom bit set indicates some kind
				of successful completion (but it could be an
				"alternate success" status); bottom bit clear
				is some kind of failure, in which case the
				other two bits indicate how severe a failure.
			Message number:  13 bits.
			Facility number:  12 bits.  Globally assigned value
				that identifies the particular subsystem;
				most significant of these is 0 for DEC
				facilities, 1 for customer-defined facilities.
			Control:  4 bits.

		The "SYS" facility is facility 0; status values returned by
		this facility (which includes all values returned as a direct
		result of system calls, in particular) always have the top
		word of the condition value longword clear.  In some contexts,
		the condition value is stored as a (16-bit) word, with an
		implied zero-extension to a full longword condition value.

		This last is a hack that seems to have some connection to
		VMS's RSX heritage; it also saved space in a day when VMS
		ran on 128K systems.  But it means that you can't use the
		top bit of a condition longword to encode success information,
		since that bit may not be representable in some contexts.

							-- Jerry
From: MICHAEL.WILLETT@OFFICE.WANG.COM ("Michael Willett")
Subject: Re: Raid 7 Versus Earlier Raid 4
Organization: Mail to News Gateway at Wang Labs
Date: Tue, 15 Dec 1992 14:52:33 GMT

Regarding availability of RAID 7, Dave Goldblatt at Clarkson University
writes:

>I wonder if Wang resells them?

No, these RAID 7 disk array platforms are not available from us here
at the new Wang Labs.  You would have to get them directly from Storage
Computer in Nashua, New Hampshire, or via their European headquarters
in Frankfurt, or their European/Asia/Pacific distributors.  Here at the
new Wang Labs we are reselling a RAID 3 from another major vendor, because
the architecture more closely matches that of our VS minicomputers
(both those already installed and the new VS high-end models that have
been coming out recently.)   I'll be happy to find some technical RAID
reports on the Wang VS RAIDs for those people interested.

>Other than one article in a trade rag somewhere, I've never seen
anything else on it in the press.

Actually they've published a number of technical articles in the
literature.  They seem to prefer to publish more technical material,
rather than marketing blurbs.  There have been some recent, favorable
reviews of their products in Corporate Technology Review, Open Systems
Today, and iX magazine from Germany.  People interested could probably
get copies by calling them at 603-880-3005.

In general, they seem to prefer demoing their products at user group
meetings, rather than sending out press releases.  They have recently
had booths at the Banyan, Wang, and Sun users groups meetings, among
others.

Michael.Willett@OFFICE.Wang.com
From: gjr@zurich.ai.mit.edu (Guillermo J. Rozas)
Newsgroups: comp.arch
Subject: Re: Any use for Branch if Even/Odd ?
Date: 11 Dec 92 23:07:51
Organization: M.I.T. Artificial Intelligence Lab.
	<GJR.92Dec10233620@chamarti.ai.mit.edu> <lihth9INNbpo@spim.mti.sgi.com>
Reply-To: gjr@zurich.ai.mit.edu
NNTP-Posting-Host: chamartin.ai.mit.edu
In-reply-to: jackc@vermont.mti.sgi.com's message of 11 Dec 92 20:12:25 GMT

In article <lihth9INNbpo@spim.mti.sgi.com> jackc@vermont.mti.sgi.com (Jack Choquette) writes:

|   |> Isn't this in fact how booleans are represented in BLISS, the language
|   |> in which a lot of VMS was/is written?
|
|
|   Since many programs use boolean variables for control flow but use integers
|   as the boolean variable, I could see how this could be useful.  However,
|   if a int value is being used as a single boolean variable it would make
|   more sense to use/have an instruction like branch on zero.  It's more general
|   purpose and useful.  You can use it to test boolean values as well as
|   count down (to zero) loops.

The alpha has those too, but that is not the issue.  If I remember
correctly, all odd integer values were considered true in BLISS, and
all even values false.  Using test-for-zero for boolean tests only
works if zero is the unique representation for one of the boolean
values (as in C), but this is neither inherent nor clearly superior.
From: tim@Apple.COM (Tim Olson)
Newsgroups: comp.arch
Subject: Re: RISC assemblers question
Date: 18 Dec 92 21:51:57 GMT
Organization: Apple Computer Inc, Cupertino, CA

In article <Dec.17.10.16.36.1992.17493@cadenza.rutgers.edu> masticol@cadenza.rutgers.edu (Steve Masticola) writes:

|I've met a couple of people who have attempted to write assemblers for
|RISC machines, who say that it's a difficult job. Can someone give me
|an inkling as to why?

From my experience, it's just the opposite.  RISC processors tend to
have a few simple instruction formats, fixed fields, etc.  Also, with
the limited number of addressing modes in RISC processors, parsing
becomes almost trivial.




-- 
	-- Tim Olson
	Apple Computer Inc. / Somerset
	(tim@apple.com)
Newsgroups: comp.arch
From: belkacem@pop.ibp.fr (Zerrouk BELKACEM)
Subject: Interval Routing
Organization: Laboratoire MASI, Paris, France
Date: Wed, 16 Dec 1992 12:10:15 GMT

Hi, 

I'm working on a VLSI implementation of a message router using interval
 labeling like in the INMOS C104.

I would like to have some contacts with persons working in this field.
And, welcome for informations on the recent advances concerning
 this domain.

 The only refences i have are the following:  

J.Leeuwen and R.B Tan, "Interval labeling", the computer journal vol30 1987.

N.Santoro and R.Khatib, "Labeling and implicit routing in networks", the
computer journal vol 28 1985. 

If you have e-mails of these authors please send them to me.

Thanks in advance.

Belk.
-- 
......................................
Belkacem ZERROUK                        
CAO_VLSI/MASI UPMC PARIS VI            
e-mail: zerrouk@masi.ibp.fr
From: scvalentine@hou.amoco.com (Steve Valentine)
Newsgroups: comp.arch
Subject: Re: Logic Minimization Algorithms
Date: 15 Dec 1992 16:53:10 GMT
Organization: Amoco
Distribution: world
Reply-To: scvalentine@hou.amoco.com
NNTP-Posting-Host: usasun47.hou.amoco.com

In article 22554@amd.com, roberts@angelo.amd.com (Dave Roberts) writes:
>
>I couldn't think of a more appropriate news group to post this in, so
>here goze:
>[Lots deleted]

Try comp.lsi.cad

>So I guess my question is, how are these problems overcome?  Do people
>use other algorithms than Quine-McClusky instead that don't suffer
>these problems?  If so, what are they?
>
>Does someone have references of articles that describe this stuff?
>Articles themselves?
>
>What about publicly available source code that implements the various
>algorithms?
>
>Thanks for any help people can give to satisfy my curiousity.
>
>Dave Roberts
>roberts@brahms.amd.com

Again comp.lsi.cad - they recently posted their FAQ which should answer these
questions.

---
| Steve Valentine             | My opinions are my own and not those of my  |
| Amoco Production Co         | employer.                                   |
| 501 Westlake Park Boulevard |                             __o             |
| Houston, TX  77079          |                             \  >            |
| scvalentine@hou.amoco.com   |                          (*)/ (*)           |
From: preston@dawn.cs.rice.edu (Preston Briggs)
Newsgroups: comp.arch
Subject: Re: How to list software as reference
Date: 20 Dec 92 00:54:22 GMT
Organization: Rice University, Houston

jtien@verdi.eng.uci.edu (Joe Tien) writes:

>How should I list software packages/programs I used in my research as
>references?  They are even more significant than the papers I read in
>terms of getting actual results and stuff.

Usually, you describe your experiments (and stuff) in a section called
something like "Experiments" or "Emperical Results".  As part of the
description of the experiments, you mention all the relevant software.

For example, if you're collecting SPECmarks, you should describe the
machines, the compilers, the compiler flags, and the exact verion of
the SPEC programs -- enough so others could reproduce your results.

Some tools, e.g., gprof, are described in papers or technical reports.
Try and cite the papers if possible, since not every reader (or
referee!) will be familiar with all the tools available on your
system.

You don't bother mentioning that you used gnu to type up shell scripts
run on bash or that you typeset the paper using LaTeX; those details
just aren't relevant.

Preston Briggs
Newsgroups: comp.arch
From: peter@ferranti.com (Peter da Silva)
Subject: Re: "Open Systems" (was Re: Comparison of Alpha, MIPS and PA-RISC-II wanted)
Organization: Xenix Support, FICC
Date: Sun, 13 Dec 1992 21:55:05 GMT

In article <jdd.724102048@cdf.toronto.edu> jdd@cdf.toronto.edu (John DiMarco) writes:
> "Openness" is relative.

Of course it is. It's also relative to what your application is. It has nothing
to do with whether the software is proprietary, but rather whether the
interfaces you need for your application are available in a form compatible
with the system in question.

> Ultrix on a VAX is more "open" than VMS on a VAX,
> since you can replace the Ultrix/VAX combination with some other 
> UNIX-type OS/workstation combination with less pain than you can the VMS/VAX
> combination.

Yes.

> SunOS on a SPARC-2 is more open than these, because you can 
> replace SunOS with stock SVR4 (eg. from ICL), and the SS2 with a SS2 clone, 
> with even less pain. 

What do you do when your application depends on NeWS, or Display Postscript?

> This leads to the following definition: "Openness" is essentially a measure of
> the minimum migration cost of replacing a system with another from a different
> manufacturer.

That's far too simple. I can replace a network of VAXen running Ultrix on
DECnet more easily than I can replace a network of Suns running SunOS if my
application is using DPS or NeWS (respectively), since DPS is available from
more sources, but I can integrate an RS6000 in the Sun network a lot more
easily than I can integrate it in the Ultrix network.

> Note that calling Suns running SunOS "open" is a misleading thing, because in 
> comparison to a 386 running DOS (where you can change OS from MS-DOS to
> DR-DOS and system units from one manufacturer to another without recompiling 
> your apps or retraining your users), suns are not really that open.

If I have a network of DOS machines running Novell it's going to be really
painful to provide Usenet news to these seats, and moderately painful just
to give them file-level access to my VMS based VAXen, but if I'm running
OpenNET it'll be quite easy... but OpenNET is only available from one vendor.

> >Any system is only open where it exposes standard interfaces to applications,
> >users, and other systems.

> Standards are the means, "open" is the result.

I agree, but not in the way you mean.
-- 
%Peter da Silva/77487-5012 USA/+1 713 274 5180/Have you hugged your wolf today?
/L{lineto}def/C{curveto}def/F{0 562 moveto 180 576 324 648 396 736 C 432 736 L
482 670 518 634 612 612 C}def/G{setgray}def .75 G F 612 792 L 0 792 L fill 1 G
324 720 24 0 360 arc fill 0 G 3 setlinewidth F stroke showpage % "Peerless"
Xref: sparky comp.arch:11768 comp.sys.dec:6539 comp.sys.sgi:18199 comp.sys.hp:14236
From: tim@computer.bri.hp.com (Tim Phipps)
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Followup-To: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
Date: 18 Dec 1992 17:16:17 GMT
Organization: Hewlett-Packard, Computer Peripherals Division, Bristol, UK
Reply-To: tim%hpcpbla.bri.hp.com@hplb.hpl.hp.com
NNTP-Posting-Host: computer.bri.hp.com
X-Newsreader: TIN [version 1.1 PL8]

Phill Hallam-Baker (hallam@zeus02.desy.de) wrote:
: 	1) Online manual still designed with aim of minimizing disk space rather than
: providing information.
Not if your sys-admin runs catman 8-)

: 	2) No help facility.
Since I read this in  comp.sys.hp try vuehelp or the help button in a Motif
window.

: 	3) No standardized user firendly shell.
Got me there, I don't recall Posix doing a freindly shell standard.

: 	4) Command qualifiers hard coded into applications making multilanguage
: customization impossible.
Since when is "ps -dfla" or "cpio -paduvmx" language dependent?

: 	5) Requires expensive expert to have a chance of any security.
Security is expensive.  It starts with physical security ie big blokes
who don't smile, then you can have an expensive OS with good security or
Unix with an expensive security guru or DOS and take the disk home.

: 	6) File system limited to sequential file, forcing applications to create their
: own file system on top of the UNIX one, thus preventing any standardization or
: application independent optimization.
(Snore) Try "man fseek".

: |> Like most modern languages, Unix has survived because it is
: |>...
: I disagree. It passed it's sell by date years ago. 
So have I.

Phippo the Hippo.
Newsgroups: comp.arch
From: cchung@sneezy.phy.duke.edu (Charles Chung)
Newsgroups: comp.arch
Subject: GaAs -- Don't Laugh
Date: 17 Dec 92 05:20:14 GMT

Anybody know what's up with Gallium Arsenide these days?  I know  
we're still getting plenty of performance out of silicon, but I'm  
just curious.  Last time I read up on the stuff (about a year ago)  
Convex had come out with a GaAs computer.  Knowing how things work  
their way down from the top, I wanted to know if there are any plans  
for GaAs uP's anytime soon.  Anyone know what sort of transistor  
densities are on GaAs now?  Wafer sizes?  Yields?

-Chuck
---
*******************************************************************

	Chuck Chung				(919) 660-2539 (O)
	Duke University Dept. of Physics	(919) 684-1517 (H)
	Durham, N.C.      27706			cchung@phy.duke.edu
	
	"If pro is the opposite of con, 
		then what is the opposite of progress?"

*******************************************************************
Newsgroups: comp.arch.bus.vmebus
From: markm@ee.ubc.ca (mark milligan)
Subject: Re: Looking for high-res timer board
Organization: University of BC, Electrical Engineering
Date: Fri, 18 Dec 1992 16:52:48 GMT

In article <9212171639.AA21526@stork.cs.rochester.edu>, bukys@cs.rochester.edu writes:
> We're looking for a high-res VME timer board.
> It will be stuck in a multiprocessor and will get frequent memory-mapped
> reads from heavily instrumented code.  Therefore, the ideal candidate
> would be something like:
> 	32-bit counter, accessed D32.
> 	No state to maintain between accesses (so I don't have to
> 	make the multiple processors do mutual exclusion just to
> 	look at the timer).
> 
> Alternatively, can anyone recommend a D32 VME prototype board
> onto which we could paste our own counter circuit?
> 
> Liudvikas Bukys
> bukys@cs.rochester.edu

We are using the XYCOM-085 VME prototype board. I only allows 16 bit 
data accesses (A16/D16 and A24/D16) but is easy to use.

Contact Xycom at

750 North Maple Road
Saline, Michigan 448176
(313) 429-4971
From: ebg@hoshi.hip.atr.co.jp (Ed Gamble)
Newsgroups: comp.arch.bus.vmebus
Subject: VSB A/D boards
Date: 19 Dec 92 03:55:43 GMT
Organization: ATR Human Information Processing Research Labs., Japan


Can anybody provide a pointer to A/D boards with a sizeable memory buffer,
16bit resolution, clocking at >50KHz/channel and access via the VSB bus?  

-- Ed
From: ssrhines@csug3.cs.reading.ac.uk (Chris D. R. Hines)
Newsgroups: comp.arch.bus.vmebus
Subject: Sun 3/160 VME backplane
Summary: VME Bugs
Keywords: Sun VME Bugs
Date: 19 Dec 92 20:52:13 GMT
Organization: University of Reading

I have the chance to use a Sun 3/160 for a VME project, the 3/160 is fully
working execpt the processor board. This project involes the development of
a multi--processor Realtime Microkernel. It is planned to use Eltec E16,
Eltec IPC, GreenSpring SBC-5 and various other boards.

Am I likly to meet any problems using this backplane, after adding card
guides for 6U? Does this backplane suffer from the BBSY* glitch or any other
problems.

Thanks for your help.


Chris.



-- 
      ssrhines@uk.ac.rdg.cs.csug,  ssrhines@uk.ac.rdg.susssys1
---------------------------------------------------------------------------
DOS ... is still a real mode only non-reentrant interrupt handler,
	and always will be.                -Russell Williams
Xref: sparky comp.arch.bus.vmebus:95 comp.lang.ada:3746
From: stephens@litsun27.epfl.ch (Dan Stephens)
Newsgroups: comp.arch.bus.vmebus,comp.lang.ada
Subject: FORCE 40B/16 configuration
Date: 17 Dec 92 12:20:30 GMT
Reply-To: stephens@litsun.epfl.ch
Followup-To: comp.arch.bus.vmebus
Distribution: comp
Organization: Ecole Polytechnique Federale de Lausanne

We are attempt to configure the VERDIX ADA cross compiler, version 6.0.5, 
for use on a 68040-based FORCE 40B/16.  We are having a few difficulties 
configuring the TDM and the Kernel for use with the card.  We were wondering 
if anyone out there has had any success doing this for the FORCE card or 
if anyone had any success with some other 68040-based card (Note that 
this card is used on a VME bus).

Dan Stephens                                           
Laboratoire d'informatique Technique                   
Department Informatique
Ecole Polytechnique Federale Lausanne
email : stephens@litsun.epfl.ch
From: miket@frog.CRDS.COM (Michael C Tiernan)
Newsgroups: comp.arch.bus.vmebus
Subject: Intel based VME boards.
Summary: Providing info on VME based Intel boards.
Date: 15 Dec 92 18:35:47 GMT
Organization: Charles River Data Systems


	Someone out there was looking for info on VME boards using the
	Intel 80K series chips.  Here's two possibles for you:
		Xycom Europe Ltd
		21 Tenter Road, Moulton Park
		Nothampton  NN3 1AX, England
		P: +44 604 790767
		F: +44 604 790722

	And:
		Arcom Control Systems, Inc
		13510 South Oak Street
		Kansas City, MO  64145
		P: +1 (816) 941-7025
		F: +1 (816) 941-0343

	I gave the UK address for the first one 'cause the magazine I
	got it from is European.

	Good luck.
-- 
<< MCT >>  Michael C Tiernan. - GEnie:M.Tiernan - AOL:M Tiernan/BCS Mike 
UUCP = alfalfa!pro-angmar!m.tiernan OR miket@frog.UUCP
      It's too bad that it takes almost half of our life
	to realize that it was a "Do-It-Yourself" project.
From: jfrench@cs.tamu.edu (Jeff French)
Newsgroups: comp.arch.bus.vmebus
Subject: VME parts, for sale
Date: 16 Dec 1992 01:17:44 GMT
Organization: Computer Science Department, Texas A&M University
Distribution: usa
NNTP-Posting-Host: solar.tamu.edu

Recently I inherited a bunch of Motorola stuff that came from some sort
of robotics lab. I don't know its value, but intend to divest myself of
all of it, regardless of the price. Best offer takes all or part. These
components are untested, but presumed good, except as noted. 

Quan.	Description
1	MVM910-3 powersupply and rack
6	MVME400
1	MVME435A
3	MVME410
8	MVME110 with rack
1	VME/10 68010 & 68451 & hard disk

The VME/10 has, I think, a bad keyboard.  The system will boot, then ask
	for user name, but not read the keyboard. Hence it stays at this
	prompt. I know nothing about VME systems and have no idea of the
	size of the hard disk, RAM, etc. Email specific questions, along
	with directions on what to do, and I will try my best. I will be
	willing to part it out, should someone not need the entire unit.
	It has a 14" mono monitor, 5.25" floppy, 3 MVME201 boards, and a
	controller to connect external devices.      

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
    SCO Xenix 80386 2.3 ==> An elegant, 32-bit OS from Northern California     
    jfrench@cs.tamu.edu ==> A homely, 2-bit SOB from East Texas           
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Newsgroups: comp.arch.bus.vmebus
From: markm@ee.ubc.ca (mark milligan)
Subject: VME sources - VME Buyers Guide
Organization: University of BC, Electrical Engineering
Date: Fri, 18 Dec 1992 17:28:07 GMT

A lot of people are asking where to find VME hardware for their specific needs.

A good source of information is the VMEbus Buyers Guide, I have been using this
for a while now and found it very helpful.

The guide is published twice a year and has all the latest products and
manufacturers. If it's not in the guide then it probably dosent exist.

You can contact:

Cahners Publishing
The Microcomputer Interface Group
1350 E. Touhy
P.O. Box 5080
Des Plaines, IL
60017-5080

Phone:
 800 992-4447
(708) 635-8800


P.S. Anybody intrested in starting an FAQ for this group? I have a lot of info
that can go into it.