HDTenEightyP/NetNews huggingface dataset:
From: dfox@quack.sac.ca.us (David Fox)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'.
Date: 23 Dec 1992 16:44:55 UTC

In article <1992Dec21.194657.759@qb.rhein-main.de> vhs@rhein-main.de writes:
>In article <1992Dec20.164501.291@rlgsc.com> gezelter@rlgsc.com writes:
>[discussion about file formats on VMS vs. UNIX flat file deleted]
>> Incorrect. The reason that you cannot read it with C is that C 
>> has consistently ignored the standardization of IO interfaces.
>
>#include <stdio.h>
>
>(The first line in the first example code in the K&R C book)
>
>Honestly it's the definition of IO that's missing here. C/UNIX
>have standardized on NOT sequential but flat direct-access files
>for the filesystem and sequential access for pipes, some devices,
>input format for most system commands, etc.

That's an interesting point.  I am not an expert in Unix file access
but I'd guess that Unix has standardized on both sequential
and flat direct-access files, and that sequential access is just a
special case of direct access: read so many bytes sequentially from
a randomly-accessible point in a file.  Or, it has standardized on
sequential file access, and that direct access is a special case, using
the fseek() library call.

>I would hazard to say that using non-flat files just isn't as open
>as flat files, simply because the lowest common denominator is
>exceeded.

If you mean 'flat' as not being sequentially accessed, then some
sequentially-accessed files can be not open either in the sense
that the file formats are difficult to figure out.
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: VMS vs "Unix"
Date: 23 Dec 92 19:56:40 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Dec23.015329.8249@brt.deakin.edu.au>, dougcc@brt.deakin.edu.au (Douglas Miller) writes:

| > 	transparent networking
| > 	network file sharing
| no, no, take your pick of VMScluster, DNS, NFS, DECnet/OSI, TCP/IP

  I tried to stay out, but VMS isn't even transparent across it's local
devices. A name like

  joesvax::a$physical_disk$name_here_like_dra0:[dir.dir.dir]filename

may work from anywhere on the net, but you need to know the node name,
physical device name, and lots of syntax with variable numbers of
colons, and [names] as well.

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Keyboard controller has been disabled, press F1 to continue.
From: ram@shukra.Eng.Sun.COM (Renu Raman)
Newsgroups: comp.arch
Subject: Re: No Last Call Optimization on Sparc and DECstation
Date: 3 Jan 1993 06:51:30 GMT
Organization: Sun
NNTP-Posting-Host: shukra

In article <1992Dec30.094352.4243@cucs5.cs.cuhk.hk> bmtong@cs.cuhk.hk (Tong Bo-Ming) writes:
>In the field of Logic Programming, we have a kind of optimization
>technique called the Last Call Optimization.  The idea is simple.

 The proper term - even in the field of logic programming is
 "tail recursion elimination". Yes, its supported in all versions
 of SPARcompilers 1.X and above (I think -O3 or -O4 will get you).

 Most compilers do support this - very easily seen the benefits of this
 in compiling li - one of the SPEC benchmark integer benchmarks.

 Many times inlining routines would expose more oppurtunities for
 tail recursion elimination as well and some compilers do exploit that
 as well.

>	p(a,b,c)
>	{	x(a);
>		y(b);
>		z(c);
>	}
--
--------------------------------
   Renukanthan Raman				Internet:renu.raman@Eng.Sun.COM
   M/S 16-11, 2500 Garcia Avenue,               Tel :415-336-1813
   Sun Microsystems, Mt. View,  CA 94043
Newsgroups: comp.arch
Subject: Re: IBM AS/400 is the worlds slowest computer
From: rmk@rmkhome.UUCP (Rick Kelly)
Organization: The Man With Ten Cats
Date: Sun, 27 Dec 1992 22:13:06 GMT
Reply-To: rmk@rmkhome.UUCP (Rick Kelly)

In article <1992Dec26.003022.25532@bilver.uucp> wbeebe@bilver.uucp (Bill Beebe) writes:
>In article <id.HD1W.X03@ferranti.com> peter@ferranti.com (peter da silva) writes:
>
>>I'd hope it'd run pretty damn well, since we've had up to 10 users on a 286
>>doing software development... which is about 30 times slower than the 486,
>>with more demanding users.
>>
>>Now I won't say I was happy with the performance on the 286, but the current
>>systems with moderately old 386es are adequate, and our 486 box screams.
>
>Maybe I *really* am dumber than a box of dirt, but why, in this day of
>networking, would anyone do team development on a single box when it would
>appear that team development on networked single-user boxes would be a lot
>more efficient? Why do we still need multi-user boxes except to support
>obsolete business practices?

What's obsolete about hanging terminals on a system that is running a
multiuser, multitasking operating system?  A 50 mhz 486 with 32 megs
of memory should easily handle 10 users doing the compile-edit-debug
cycle.  Terminals are dirt cheap.  Workstations are a little more
expensive.

-- 

Rick Kelly	rmk@rmkhome.UUCP	merk!rmkhome!rmk	rmk@frog.UUCP
From: peter@ferranti.com (peter da silva)
Newsgroups: comp.arch
Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
Date: 21 Dec 92 21:42:13 GMT
Organization: Xenix Support, FICC

In article <BzIx0C.C6G@dscomsa.desy.de> Hallam@zeus02.desy.de writes:
> zow07> man dd
> Warning: couldn't stat file /zow/userb/hallam/man!
> WARNING: terminal cannot clear to end of line
> WARNING: terminal cannot clear screen
> WARNING: terminal cannot home cursor
> WARNING: terminal cannot move cursor to lower left of screen
> WARNING: terminal cannot scroll backwards
> -  (press RETURN)

Sure as hell a better disgnostic than having the screen hash up, or the
output go to the screen *despite* your redirect, which are the usual results
on DOS. On NT, of course, you'll have an RTF hypermedia file for your manual
and you wouldn't consider even trying to pull in a man page unless it was
going to someone on your LAN.

> Note the warnings caused by sysop hackery since my last login.

That's not a UNIX problem. I take it you've never used a multiuser CP/M
system and had your user area disappear overnight.

> Like the stupidity of ftp which assumes ascii conversion mode as default.

You mean like every OTHER program of this type, from Kermit on through every
terminal program I've ever used?

> Back to the question of "Open" systems. An open system to me is a system
> that an uninformed but intelligent user can simply be given a password
> for an acccount and a primner and told to get on with their stuff.

Buddy, that's nothing to do with open systems. That's user friendliness... which
is another desirable quality that I'd like to see more of, but it's orthogonal
to openness...

Brief history of recent buzzwords:

	1986: everyone came out with "User Friendly" systems, usually by
		stamping "User Friendly" on the box.
	1989: everyone was coming out with "Object Oriented" systems,
		usually by stamping "Object Oriented" on the box.
	1992: now it's "Open" systems, usually produced by stamping "Open"
		on the box.

In 1995 it's going to be either multimedia, virtual reality, or distributed
systems. Buy your rubber stamps early.

In general, user friendliness requires detailed control over every aspect of
the user interface (as any Apple developer about that!). Open systems require
conformance to externally defined standards and interoperability with software
you've never had a chance to spec. It's VERY hard to get the two together,
which is why so many people are excited about the NeXT.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: IBM AS/400 is the world's slowest computer
Date: 25 Dec 92 19:56:37 GMT
Organization: Auspex Systems, Santa Clara

>(I've often wondered exactly what C
>ended up looking like on that machine, as pointers and ints are definitely not
>the same, and casting an int to a pointer makes no sense).

I suspect it looks like a C that punishes people who think pointers are
the same as "int"s; I wish there were *more* C implementations like
that, in order to break some C programmers' bad habits.  I've heard a
claim that pointers are 128 bits long; that may have been done so that
pointers to elements of arrays contain, in effect, the bounds of the
array, so that pointer arithmetic on those pointers can be checked to
make sure it results in a pointer that points into the same array as the
original pointer.

(And yes, such a C implementation *can* be a valid ANSI C
implementation, even though it doesn't allow the kind of fast-and-loose
glop that some C programmers think is key to the C language....)
Newsgroups: comp.arch
From: vhs@rhein-main.de (Volker Herminghaus-Shirai)
Subject: Re: Any new instructions in a i486?
Reply-To: vhs@rhein-main.de
Date: Mon, 21 Dec 92 19:03:05 GMT

In article <WAYNE.92Dec20171036@backbone.uucp> wayne@backbone.uucp (Wayne Schlitt)  
writes:
> In article <9212200017.12@rmkhome.UUCP> rmk@rmkhome.UUCP (Rick Kelly) writes:
> 
> < >(somebody)> NeXTStep is said to not run on the Cyrix 486 chips because
> < >(somebody)> "they are not real 486's".  No one has come up with a
> < >(somebody)> reliable reason _why_ NeXT doesn't think they are "real
> < >(somebody)> 486's" or why NeXTStep won't run on them.
> < >
> < >FUD, FUD. Ah Intel, Intel. :-)
> < 
> < 
> < I don't see where this has anything to do with Intel.  Cyrix decided that
> < they could make some money by cloning a best selling CPU chip.  Obviously,
> < they have missed something.  
> 
> 
> Well, from the info that has been posted so far, it looks more and
> more like it is NeXT that screwed something up and doesn't care about
> fixing it.  Chances are NeXTStep won't run on the Pentium either if it
> is that fragile.

Wrong. NeXT says it will run on 486SX, 486DX, and follow-ups to
the '86 line. Support for Pentium is for sure. Since NeXT has worked
together with intel on the port (from what I heard) I'd guess NeXT had
to sign a contract banning support for Cyrix's part.

--
Volker Herminghaus-Shirai (vhs@qb.rhein-main.de)

Looks good on the outside, but -
	intel inside
Newsgroups: comp.arch
From: pjdm@chmeee.enet.dec.com (Peter Mayne)
Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
Reply-To: Peter.Mayne@cao.mts.dec.com
Organization: Digital Equipment Corporation
Date: Tue, 29 Dec 1992 00:37:28 GMT


In article <id.SQ3W.IB6@ferranti.com>, peter@ferranti.com (peter da silva) writes:
>> OK, try this. VMS has something called an AST (Asynchronous System Trap) which
>> is similar to a user-mode interrupt.
>
>Yes, I'm familiar with it from RMX.  There, at least, unless you're working
>in assembler it's something to be used with extreme care lest you trash the
>language runtime.

RMX? No extra care required in VMS, from assembler or HLL. (Apart from the
usual synchronisation techniques, of course.)

>> This may occur at any time: for instance,
>> an asynchronous I/O can call an AST routine when the I/O completes. When the
>> AST routine completes, control returns to the code that was executing at the
>> time the AST occurred. (The analogy in NT is the APC, or Asynchronous
>> Procedure Call.)
>
>And in UNIX the analog is a "signal". Now, a signal is a little "safer" than
>an AST (at least as under RMX), in that it's guaranteed to run in your task
>context.

So is an AST in VMS, and an APC in NT. Nothing "unsafe" about it.

They aren't exactly analagous. An AST also carries a (program-provided)
value, a signal is one of a particular set of values. A signal can come
from another process, an AST can only occur from (or on behalf of) the current
process.

>> how can I use these non-reentrant routines safely in an AST
>> routine without screwing things up?
>
>You can't. Can you really do
>
>	WRITE (*,10) AA
> 10	FORMAT (1X,80A1)
>
>in an AST under VMS?

Don't know about FORTRAN, but I've done I/O in BASIC, BLISS, and Pascal from
ASTs with no hassles.

>> >But the UNIX operating system interface is centered on the file system.
>
>> But that doesn't mean that I can put an ACL on a UNIX operating system object.
>
>A UNIX "operating system object" *is* a file. If the file system supports ACLs
>you certainly can. What "operating system objects" are you trying to put an
>ACL on?

NT (for example) supports at least two file systems, DOS and NTFS. NTFS has
ACLs, DOS doesn't. If an operating system object is a file, which filing
system does it use?  If I only use DOS, does that mean that NT suddenly loses
the ability to use ACLs?

>Go read the Plan 9 papers, or get an Amiga. It's not new technology by
>any means: AmigaDOS was shipped in 1985, and based on an older operating
>system from Cambridge called Tripos (note, not all interesting O/S
>design is from the US).

I know, I've been to the restaurant that the operating system was named after.
:-)

>-- 
>Peter da Silva                                            `-_-'
>Ferranti International Controls Corporation                'U` 
>Sugar Land, TX  77487-5012 USA
>+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"

PJDM
--
Peter Mayne                     | My statements, not Digital's.
Digital Equipment Corporation   |
Canberra, ACT, Australia        | "AXP!": Bill the Cat

Newsgroups: comp.arch
From: zrepachol@cc.curtin.edu.au
Subject: Re: Any use for Branch if Even/Odd ?
Organization: Curtin University of Technology
Date: Mon, 28 Dec 1992 12:11:05 GMT

In article <Bz2wnL.HGL@apollo.hp.com>, gardner_c@apollo.hp.com (Cal Gardner) writes:
> In article <endecotp.723992157@cs.man.ac.uk> endecotp@cs.man.ac.uk (Phil Endecott) writes:
>>Can anyone think of a use for the branch if even and branch if odd
>>instructions on the Alpha?  I'm completely baffled.
>>

Get a BLISS manual and read the bit about TRUE/FALSE.

~Paul

Newsgroups: comp.arch,comp.sys.dec,comp.sys.hp,comp.sys.sgi
From: vulture@imperial.ac.uk (Thomas Sippel - Dau)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Reply-To: cmaae47@imperial.ac.uk
Organization: Imperial College of Science, Technology and Medicine
Date: Tue, 22 Dec 92 13:45:02 GMT

In article <1992Dec19.012355.26665@ll.mit.edu>, ejon@ll.mit.edu (Eric Jones) writes:

- |>(Snore) Try "man fseek".

- But isn't that exactly his point?  Sure you can write an ISAM file 
- structure using fseek (and if you're REALLY smart, you might even
- write an efficient one), but then how's anyone else going to use
- your files?

Well, on IRIX from Silicon Graphics (not exactly a company known for its 
database prowess ..) there is an ISAM library that comes with the fortran
compiler. Admittedly you have to look for it, the first I noticed of it
was the recommendation to add -noisam to the fortran compile statement
to reduce the size of compiled programs - shows you the vast market for
isam.
                                   Thomas

-- 
*** This is the operative statement, all previous statements are inoperative.
*   email: cmaae47 @ ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic on Janet)
*   voice: +44 71 589 5111 x4937 or 4934 (day), or +44 71 823 9497 (fax)
*   snail: Imperial College of Science, Technology and Medicine
*   The Center for Computing Services, Kensington SW7 2BX, Great Britain
Newsgroups: comp.arch
From: pchris@dcc.uchile.cl (Chris Perleberg)
Subject: Alpha and Super-pipelining
Originator: pchris@pehuen
Date: Wed, 30 Dec 1992 17:57:17 GMT
Reply-To: pchris@dcc.uchile.cl
Organization: Universidad de Chile, Depto. de Ciencias de la Computacion


After reading the material available about the Alpha, I noticed that it was
mentioned a few times that the first implementation of the Alpha, the 21064,
is *super-pipelined* as well as superscalar.  For example, in "infosheet.txt"
that is available on gatekeeper.dec.com the following is stated:

>    Digital's 21064 Microprocessor
>    ....
>    The 21064 is a super-scalar, super-pipelined implementation of the
>    Alpha architecture. Super-pipelined means that an instruction is issued
>    to the functional units at every clock tick and the results are
>    pipelined. Being super-scalar, the architecture allows the instruction
>    unit to issue two instructions per clock tick, resulting in
>    significantly higher throughput and performance.

After reading the Data Sheet of the 21064, I find nothing that seems to
indicate the 21064 is super-pipelined, at least in terms of the common
definition of super-pipelined.  Is DEC redefining the word "super-pipeline"?
Anybody out there that can explain?

	Chris Perleberg
	pchris@dcc.uchile.cl
Newsgroups: comp.arch
From: peter@ferranti.com (peter da silva)
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Keywords: I/O, Point-to-Point, High Performance, Low Cost, Bus
Organization: Xenix Support, FICC
Date: Mon, 21 Dec 1992 23:35:06 GMT

In article <1992Dec20.212105.13649@ksmith.uucp> keith@ksmith.uucp (Keith Smith) writes:
> My Idea of *IDEAL* for *ANY* machine would be a system of snap-together
> lego (tm) style blocks with an arbitrary length bus.  Blocks would have
> a defined size (Say 6" square?) one block being a "mother-block"
> Each block could be snapped on or off the "bus" at will with all the
> neccessary connection pins / controls on the front or back edges of the
> block.  Blocks should/could be stackable, with larger blocks obviously
> on the bottom of a stack.

I've seen two versions of this: one successful, one less so. The Convergent
Technology bookshelf unit is a very nice design, with a positive mechanical
lock and no arbitrary limits to the bus length. The Amiga expansion port is
less successful, because it has no lock and the signal definition was never
designed for multiple piggybacks. The original Amiga design would have been
much better: basically stacked units with a bus running vertically up the
back of the stack, using gravity for locking. It was abandoned because it
would have added a several dollars to the cost of manufacturing a $1500 PC.

I'd like to see the bus specifics decoupled from the software, so you had
some sort of interface that you told "go to unit so-and-so and send this
control/read this data". Then you could use a low-cost hookup with ethernet
type cables, or a high-speed bus type option, without impacting the software.
You could even plug a low-speed adaptor into a high speed bus to hook up
your laptop when you get home.

If course this would logically be a LAN (um, CAN: Computer Area Network?).

> <SIGH>  not in my lifetime I suppose.

Go get a Burroughs/CT bookcase unit. UHaul uses them here in Houston, or
call your local Unisys rep.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
From: firth@sei.cmu.edu (Robert Firth)
Subject: Re: reentrant
Organization: Software Engineering Institute
Date: Sat, 2 Jan 1993 12:25:44 EST

In article <C04zn2.A95.2@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:

>The OS world is moving towards multithreading...

It is with some trepidation that I amend one of Don Lindsay's comments,
but in my experience it is only the C/Unix world that is moving towards
multithreading.  The rest of the world has been there for a very long time.
From: mcdonald@aries.scs.uiuc.edu (J. D. McDonald)
Newsgroups: comp.arch
Subject: Re: UNIX fseek time (was Re: Comparison of Alpha, MIPS and PA-RISC-II wanted)
Date: 30 Dec 92 01:05:33 GMT
Organization: UIUC SCS

In article <1992Dec29.212344.20899@qb.rhein-main.de> vhs@rhein-main.de (Volker Herminghaus-Shirai) writes:


>Or did he mix it up with M$-DOS fseek on files opened in "text mode".
>This is indeed incredibly slow because the file is searched for CR/LFs
>since CR/LFs count as only one byte (a logical linefeed) in that case.

This is just plain wrong. 

A seek to a location in a text file is no slower than in a binary file.

This is because the location ... the number that the fseek is to ...
can be to a number of bytes in the file ... one does **not** need to
take into account the CRLF pairs. An fseek can **only** be to one of three
places:

1) the beginning

2) the end

3) the value returned by a previous ftell. 

The first two are trivial.

The third is also trivial ... as the ftell will never be in the middle of
the crlf pair. Ftell will normally return not **the number characters 
read by single getc's up to the given location** but rather the
**number of bytes physically returned from the file on disk**.

EXAMPLE:

the following program:

#include <stdio.h>
main()
{
int i,k;
long j;
for(i = 0; i < 7; i++) {
  k = getchar();
  j = ftell(stdin);
  printf("%d %d %ld\n",i,k,j);
}
}

When fed the following input file as stdin:

1
2
3
456

produces the following output:

0 49 1
1 10 3
2 50 4
3 10 6
4 51 7
5 10 9
6 52 10

Note that the crlf pairs increment the ftell results by two for one
read by getchar.


Doug McDonald
From: haynes@cats.ucsc.edu (Jim Haynes)
Newsgroups: comp.arch
Subject: Re: branch-and-link
Date: 28 Dec 1992 04:38:49 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: hobbes.ucsc.edu


I recall in working on maintainability for the GE635 (it didn't have much
of it) one thing the software people thought would do a lot of good was
saving a branch history - so I believe something like this was planned and
maybe implemented in later models in the line.
-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Ya can talk all ya wanna, but it's dif'rent than it was!"
"No it aint!  But ya gotta know the territory!"
        Meredith Willson: "The Music Man"
From: peter@ferranti.com (peter da silva)
Newsgroups: comp.arch
Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
Date: 21 Dec 92 20:51:39 GMT
Organization: Xenix Support, FICC

In article <BzGL07.2wK@dscomsa.desy.de> Hallam@zeus02.desy.de writes:
> I would guess that W/NTs single user functionality should outstrip that of
> UNIX fairly easily.

You seem to have a strong opinion about this, so could you explain to me
precisely how the UNIX API is lacking, and what specific features of NT
would be impossible under a UNIX API. Why did Microsoft have to create
a completely new API from scratch, and implement it in such a way that
programs using it are entirely insulated from their UNIX API environment
(POSIX shell)?

> Security in a multiuser  environment is provided in the main by the
> filestore.

Well for UNIX, where access to virtually all system resources is provided
through the filestore, I would agree. But NT has half a dozen different
mechanisms for interacting with the system... how can multiuser security
be managed if it only protects a minor part of the system?

> system which can run existing apps for starters and move up to better systems
> than have the initial OS/2 "throw it all away approach."

Since OS/2 and NT have virtually the same level of backwards-compatibility
with DOS, how do you make out that the OS/2 approach is any way diferent?

I'm sorry, but you seem to be discussing a completely different set of
software packages than I'm familiar with or have been discussed in the
media.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
Xref: sparky comp.arch:11955 comp.sys.intel:2842