HDTenEightyP/NetNews huggingface dataset:
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.arch
Subject: Re: UNIX fseek time (was Re: Comparison of Alpha, MIPS and PA-RISC-II wanted)
Date: 29 Dec 1992 22:33:15 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.15

In article <1hnqdeINN15a@duca.hi.com> wright@duca.hi.com (David Wright) writes:
>In addition, fseek() is generally moronic about checking whether the
>new file pointer is within the current buffer.  That is to say, it
>doesn't check.  So if you, say, try to read a file backwards, one byte
>at a time, you'll do as many reads as there are bytes in the file.

Speak for yourself. :-)

I wrote most of the 4.4BSD stdio (bugs and all---so far we have found
and fixed three or four).  My fseek() can read a file backwards fairly
quickly.  You will do better if you read() directly---no general
subroutine can be perfectly optimal for all tasks---but there is no
longer an order of magnitude slowdown for short backwards seeks when
reading.

(Note that, when writing, fseek must perform an fflush(), which translates
into a write and thus may involve block allocation and other very slow
tasks.  The code for reading is largely separate.)

None of this has anything to do with UNIX: fseek()'s operation is
defined by ANSI standard X3.159-1989 and its various equivalents.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
Newsgroups: comp.arch
From: stripes@pix.com (Josh Osborne)
Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
Organization: Pix Technologies -- The company with no adult supervision
Date: Tue, 29 Dec 1992 15:34:34 GMT

In article <1992Dec29.012215.10632@ryn.mro4.dec.com> Peter.Mayne@cao.mts.dec.com writes:
[...]
>** I believe that you can also run into problems if you have
>** a signal handler that gets invoked, and resets errno in the period
>** between your successful system call and your test for success. It's
[...]
>Fixing this kind of problem would involve changing the model of "returning
>an error flag and a static errno". You could:
>
>- return an error status rather than an error flag
>- signal on errors
>- call a "callback" routine on errors
>- fill in a program-provided "status block" (non-static "errno" equivalent)
>
>Any one of these would probably be considered incompatible by a large number
>of UNIX style programmers (including DOS programmers and a lot of VMS
>programmers).

Yes, this is a big problem with the way Unix does error reporting.  However
you can kludge around it like this:

sighandler(...)
{
	int old_errno = errno;
	/* do stuff */
	errno = old_errno;
}

Note: you need to do this even if you exit()/abort() after any syscall failure.
I beleve that syscalls are allowed to alter errno even on a succesful return.

(also this doesn't magicly make all of libc rentrent, but it does mean that
if someone has a rentrent libc you can use it and not stomp errno...)
-- 
           stripes@pix.com              "Security for Unix is like
      Josh_Osborne@Real_World,The          Multitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
We all agree on the necessity of compromise.  We just can't agree on
when it's necessary to compromise.       - Larry Wall
Newsgroups: comp.arch
From: dhd@exnet.co.uk (Damon)
Subject: Re: Date request
Organization: ExNet Systems Ltd Public Access News, London, UK
Date: Tue, 22 Dec 1992 17:35:40 GMT

In article <DANIEL.92Dec18155809@algol.clsi.COM> daniel@clsi.COM (Daniel S. Barclay) writes:
>I thought I heard that there is an ISO date format of YY/MM/DD.  I like that
>and YYMMDD; they sort (lexicographically and mathematically) into 
>chronological order.  (Which is consistent with times as HHMMSS.)

I like YYMMDD and YY/MM/DD and use these formats in invoices, file
names, etc because they sort lex/num correctly.  But we *should* be
using YYYYMMDD for when the clock turns over or we're going to be in
big trouble on 00/01/01 00:00:00.

Damon
-- 
Damon Hart-Davis                          Internet: dhd@exnet.co.uk, d@hd.org

Public-access UNIX (Suns), news and mail for UK#5 per month.  FIRST MONTH FREE.
[1.35] Cheap Sun eqpt.  UUCP news/mail feeds.  Tel/Fax: +44 81 755 0077.
Newsgroups: comp.arch
From: wang@pdx122 (Wen-Hann Wang)
Subject: CFP: Special Issue on Computer Architecture Simulations, IJCS
Followup-To: wang@ichips.intel.com (Wen-Hann Wang)
Organization: Workgroup Computing Division
Date: Wed, 23 Dec 1992 01:04:56 GMT


                   **** CALL FOR PAPER ****

	INTERNATIONAL JOURNAL OF COMPUTER SIMULATION

			is announcing a 
			 SPECIAL ISSUE
		     scheduled for early 1994
			      on

	   	COMPUTER ARCHITECTURE SIMULATION 

Since the beginning of electronic computers, computer architecture 
simulation technology has been the most critical(and often invisible) 
engine that moves the whole computer industry forward, generations 
after generations. 

Computer Architects rely on simulation tools to explore different architectural 
alternatives and design tradeoffs. Computer System Vendors need to 
access architecture simulation tools 9 to 12 months before the arrival of 
the real processor samples, so that they can ship out system products when 
the processor is generally available. Computer architecture simulation tools 
are also valuable to university students and professors for their research and 
instruction activities. 

The purpose of this special issue is to provide a common place for reporting 
the advance of the state of the art in the computer architecture
simulation technology. Specific topics of interest include, but are not
limited to:

	o.   Computer architecture  simulation techniques

	     *   Efficient methods for fast architecture simulation
	     *   Cycle-by-cycle-accurate architecture simulation
	     *   Techniques for fast retargeting architecture simulation
	     *   Efficient I/O system simulation techniques
	     *   Efficient TLB/cache/memory system simulation techniques
	     *   Efficient graphic system simulation techniques

	o.   Program trace collection and processing techniques

             *   Hardware-based techniques
             *   Software-based techniques
	     *   Architecture support for tracing 
	     *   Trace reduction/compression techniques
	     *   Trace selection and validation techniques.

	o.   Applications using computer architecture simulators

	     *   Program execution profilers/monitors
	     *   Computer system simulation
	     *   Multiprocessor system simulation

	o.   Update on building projects in industry and academia.


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

Prospective authors are invited to submit five copies of complete 
manuscript of high quality research contributions by June 30, 1993
to either of the Guest Editors:

Dr. Kimming So				Wen-Hann Wang
IBM Advanced Workstation Division	Intel Corporation, JF1-19
11400 Burnet Road, Zip 4305		5200 NE Elam Young Parkway
Austin, TX 71758			Hillsboro, OR 97124-6497

phone: (512) 838-6023			phone: (503) 696-4681
email: sok@watson.ibm.com		email: wang@ichips.intel.com
FAX: (512) 823-2829			FAX  : (503) 681-9017

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

Publisher:
Ablex Publishing Company
355 Chestnut Street
Norwood, NJ 07648
Xref: sparky comp.arch:11887 comp.sys.dec:6608 comp.sys.sgi:18295 comp.sys.hp:14329
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 23 Dec 92 05:25:37 GMT
Distribution: world
Organization: The Wolery

mdchaney@fractal.ucs.indiana.edu (M Darrin Chaney) writes:
> Actually, I've seen alot of people here call RMS "the file system."  For those
> of you who still think that RMS is the file system, I'll clue you in: RMS
> is not the file system.

Perhaps you'd like to explain why the back of the RMS manual looks like:

		V M S
		_________________
		
		*Volume 6B*

		*File System*

		Record Management
		Services (RMS)

Seriously, RMS is all-pervasive in VMS.  Sure, you can do QIOs to the 
XQP yourself, and RMS even provides an interface to make this a little
easier.  But 99.999% of the time, there is no reason to do so.  This is
what differentiates the VMS approach from the Unix universe.  Files on
VMS can (almost) always be read and written using RMS, often this means
that you can use tools intended for sequential files on indexed or 
relative files.  Compare the Unix approach, where if you use anything 
other than a sequential file, other utilities can't do anything useful
with it.  It's a standardisation issue more than anything else -- provide
a standard, easy way to do something and it will be used.  If you don't
you get a plethora of non-standard wheel re-inventions.  Providing an
ISAM package with the *FORTRAN* compiler (of all things) as one poster
commented on, just doesn't cut it in this regard.

> For stream-lf files, just buffer those blocks, and keep track of where the
> lf is.  It's not difficult, and you can easily get around the 65534 limit
> that RMS places on files.  Have fun...

This is what VAX C does.  It still succeeds in being dreadfully slow,
although it wouldn't take much effort by someone who knew something about
file handling to write a VAXCRTL that does block I/O and goes like a
scalded cat.  VAXCRTL is completely braindamaged in nearly every respect,
and seriously needs to be thrown away and started again.  

--
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
Newsgroups: comp.arch
From: daniel@clsi.COM (Daniel S. Barclay)
Subject: Re: big + little endian (was: Comparison of Alpha, MIPS ..)
Organization: CAD Language Systems Inc.
	<28164@dog.ee.lbl.gov> <1hquujINNmov@fido.asd.sgi.com>
Date: 30 Dec 92 12:45:12

pj@sam.wpd.sgi.com (Paul Jackson) writes>
> In article <28164@dog.ee.lbl.gov>, torek@horse.ee.lbl.gov (Chris Torek) writes:
> |> 01101001 may mean `105' (big-endian) or `150' (little-endian)
> 
> Big and little endian refer to the order of bytes within words,
> not to the order of bits within bytes.

Don't those terms also refer to the _numbering_ of bits within bytes or words?

--
------------------------------------------------------------------------------
Daniel S. Barclay                    --who's still searching for a good 
CAD Language Systems, Inc.           signature, not liking any of his recent
Suite 101, 5457 Twin Knolls Rd.      feeble attempts to improve on the whiny:
Columbia, MD  21045  USA             Why can't _I_ think of a good signature?

Newsgroups: comp.arch
From: solman@athena.mit.edu (Jason W Solinsky)
Subject: Re: Superscalar vs. multiple CPUs ?
Organization: Massachusetts Institute of Technology
Date: Mon, 21 Dec 1992 13:45:31 GMT

In article <PCG.92Dec11162630@aberdb.aber.ac.uk>, pcg@aber.ac.uk (Piercarlo Grandi) writes:
|> On 10 Dec 92 03:17:36 GMT, bradc@ferris.cray.com (Bradley R. Carlile) said:
|> 
|> pcg> as far as I can see, 6 instruction issue per cycle is virtually
|> pcg> pointless. The *limit* of superscalarity present in general purpose						 ^^^^^^^^^^^^^^^
|> 
|> Note the "general purpose"; if the codes exhibit high regularity in data
|> access patterns then they are no longer "general purpose" codes, at
|> least in my understanding of that term, which encompasses things like
|> editors, databases, compilers, word processors, spreadsheets, ...

In how many of these examples are we actually concerned with processor
performance? In editors and word processors we certainly aren't. When
running those we are also likely running several background tasks which
allows parallelization. In the case of a database, I would not expect
it to be processor limited. I would think that its performance would
be dependent on the bandwidth and latency between processor and memory.
The same goes for spreadsheets. In the case of compilers, I have only
seen the very simple compilers that you might find in a college textbook,
so I don't know what is actually used in real life, but they look very
parallelizable.

At any rate, I would claim that improvements in processor performance should
only be concerned with apps which are presently processor limited, and many
of these general purpose codes just aren't.


Jason W. Solinsky
Newsgroups: comp.arch
From: jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen)
Subject: Re: question about DMA devices
Followup-To: comp.arch
Organization: Inst. f. Neuroinformatik, Ruhr-Universitaet Bochum, FRG
Date: 22 Dec 92 18:33:54

   In article <1992Dec18.175402.27841@hubcap.clemson.edu>
   dfk@wildcat.dartmouth.edu (David Kotz) writes:

   I have a question about DMA devices, specifically for networks and disks.

   Do you know if it is possible (and if so, common) for a DMA device to
   support scatter/gather? In particular, I'm trying to model a multiprocessor
   interconnect network interface, and it would be very helpful if I could
   avoid packetization by specifying the addresses and lengths of my message
   header and message body, for the network DMA to pick up. I'm guessing that
   this is not usually an option.

   Also, in a disk interface, can it read in a whole track but scatter the
   blocks to different locations in memory? I'm guessing that this kind of
   thing is more common.

Well, as a historical perpective on this subject, consider what the I/O
adapters of the Vax11/780 (ca. 1978?) did/do: They (Unibus and Massbus
adapters) had a set of socalled mapping registers. These mapped an offset in
an I/O transaction into the appropriate _physical_ address. A set of system
routines was provided for drivers to load the mapping registers from the page
table of a process (or system space) with the required data.  (I think there
are seperate routines to make sure the page tables contain valid entries in
the relevant page range, which is especially important for I/O directly
to/from user space. I do know there was an optimization for reads which didn't
bother to page in pages from backing store which were going to be overwritten
shortly by a read  it just substituted a page from the free list and marked
the page table entry as dirty.)

A number of smaller Vaxen (only the uVaxI? or also the 725/730?) didn't have
these and in general had to do I/O a page at a time...probably still slightly
faster than a PC/XT :).

A later adapter, the one for the CI (computer interconnect, four cables
running at 70Mbit/s each) went even further: It reads I/O request packets from
system virtual memory, containing pointers to buffers in virtual memory (I
think user space buffers are double mapped into system space), and reads the
page tables itself in order to determine physical addresses.  Sort of like a
closely coupled multiprocessor with one processor dedicated to I/O. (The
rumour was that for the 750, the CI adapter was actually the faster CPU...)

So this is quite an old trick, and not really that difficult to do.  I would
assume that current Unix/workstation systems do something similar.

	Jan
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
From: peter@ferranti.com (peter da silva)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Organization: Xenix Support, FICC
Date: Tue, 22 Dec 1992 00:01:16 GMT

In article <1992Dec19.012355.26665@ll.mit.edu> ejon@ll.mit.edu (Eric Jones) writes:
> 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, you have two choices:

	1. You bind the ISAM interface into your application and
	   ship binaries. You don't document it, and hope that you
	   sell enough packages that you have a cpative market for
	   the next 10 years.

	2. You document the ISAM interface, ship libraries or source
	   to the library, and provide shell commands to hook your
	   package into the rest of UNIX.

When Oracle does all three parts of (2) I'll quit badmouthing them.
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
Newsgroups: comp.arch
From: keith@ksmith.uucp (Keith Smith)
Subject: Re: IBM AS/400 is the world's slowest computer
Organization: Keith's Computer, Hope Mills, NC
Date: Mon, 28 Dec 92 03:43:01 GMT

In article <BzsIFK.EMF.2@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:
>kolding@cs.washington.edu (Eric Koldinger) writes:
>>The AS/400 uses a tagged memory-system and tagged registers to
>>protect capabilities (or pointers, as they call them).  There are
>>also a number of operations that only take place on capabilities.
>>This makes it rather unlikely that they'd use a stock micro-processor
>>from the workstation group.
>
>I don't think that RPG programmers deal with capabilities, so, the
>stock microprocessor needs only a stock RPG.
>
>What other languages are of importance on the AS/400? What is the OS
>written in, and are capabilities actually explicit at the source
>level?
>
>My experience with software-based capabilites has been positive, so
>it's not clear to me, offhand, that a stock RS/6000 is out of the
>question.

Not to mention that UNIBOL's RPG implementation on an RS/6000 runs lots
of big humongous circles around an AS/400 all the way across the board
from what I understand.  I also understand that IBM Sales Reps are told
not to acknowledge the existance of such a product.

I keep *HEARING* how bloody fast the new AS/400 lines are, but the
people who are telling me this are the same old folks that used the old
S/36's and '400's.

I'd *LOVE* to compare my under $25K PeeCee to an operating AS/400 say
under $75K with the *SAME* functionality.  ie. 48 ports, 30 users 9
printers and 7 HIGH SPEED modems.  I'd like to see just how much
performance improvement I'll get for 3 times the money.  Also I'd like
it to run real world small-medium business ($100M or less) applications
like simple sorting of customer databases and querying and reporting and
such.  *REMEMBER* all the quoted prices are for a naked system in most
cases.  Those perhipherals are gonna cost you a bundle.

-- 
Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...
From: cyc@quip.eecs.umich.edu (Yi-Chieh Chang)
Newsgroups: comp.arch
Subject: Simulation tools for computer system
Date: 22 Dec 92 21:00:28 GMT
Organization: University of Michigan EECS Dept., Ann Arbor, MI

I'm looking for simulation tools for study/analysis/comparing
computer systems, networks, and queueing networks.
Thanks for any response.

Yi-Chieh
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
From: mdchaney@fractal.ucs.indiana.edu (M Darrin Chaney)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Organization: Indiana University, Bloomington
Date: Tue, 22 Dec 1992 15:46:31 GMT

In article <1992Dec21.103432.294@rlgsc.com> gezelter@rlgsc.com writes:
>In article <BzKGKB.2Bp@pix.com>, stripes@pix.com (Josh Osborne) writes:
>> The we need a way for user level code to tell the OS what file info is
>> important to cache, and what isn't.  Then you can be almost as efficent
>> as VMS/RMS (you will have extra context switch overhead for the extra
>> syscalls), but you will still be able to allow any user to create new
>> filetypes.
>-- 
>Josh,
> 
>Important point that you bring up tangentially in your post. 
>While VMS does provide RMS as an operating system service, there 
>is nothing which prevents you from "folling your own" type of 
>file structure. However, every program which wants to read from 
>your special file structure will have to be intimately familiar 
>with it. Programs which use RMS can process files which were 
>created using RMS with no problems.
> 
>A misnote about the HSC which appeared in this thread. The HSC 
>does not really know anything about the content of the disk 
>files. However, RMS will do things inside of the CPU, such as 
>maintain index caches on a system wide basis, which are a 
>signifigant performance improvement. One problem with rolling 
>yourself is that, invariably, the management and monitoring tools 
>and utilities are bare-bones.
> 
>- Bob

Actually, I've seen alot of people here call RMS "the file system."  For those
of you who still think that RMS is the file system, I'll clue you in: RMS
is not the file system.

Let's think of what RMS stands for: "Record Management Services."  Hmm, sounds
more like a record manager than a file system, doesn't it though.

The file system is accessed via QIO calls, and knows nothing about file
formats.  All it knows about is disks and files, files via file ids.  It is
actually easy to open a file by id and read virtual blocks from it.  If you
want to roll your own Unix functions (fread and fwrite), this is the way
to do it.  It might be a little faster, and you needn't worry about RMS.

For stream-lf files, just buffer those blocks, and keep track of where the
lf is.  It's not difficult, and you can easily get around the 65534 limit
that RMS places on files.  Have fun...

	Darrin

-- 

mdchaney@iubacs mdchaney@bronze.ucs.indiana.edu mdchaney@rose.ucs.indiana.edu

"I want- I need- to live, to see it all..."
Newsgroups: comp.arch
From: deraadt@newt.cuc.ab.ca (Theo de Raadt)
Subject: Re: Any new instructions in a i486?
Organization: little lizard city
	<9212130000.AA05447@iecc.cambridge.ma.us>
	<PCG.92Dec19162224@decb.aber.ac.uk> <9212200017.12@rmkhome.UUCP>
Date: Mon, 21 Dec 1992 23:53:42 GMT

In article <9212200017.12@rmkhome.UUCP> rmk@rmkhome.UUCP (Rick Kelly) writes:
   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.  A curious individual with a 486DLC system, a
   486DX system, two logic analyzers, and two NeXTStep bootdisks should be
   able to track down the problem.

And probably binary-patch it to work.
 <tdr.
--

This space not left unintentionally unblank.		deraadt@newt.cuc.ab.ca
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: reentrant
Date: 31 Dec 92 18:35:25 GMT
Article-I.D.: cs.C04zn2.A95.2
Organization: School of Computer Science, Carnegie Mellon


[numerous names deleted]
>> >Much of the *C* run-time in *any* language is non-reentrant,

The OS world is moving towards multithreading, that is, multiple
threads of execution sharing a single address space. Nor am I giving
some kind of advance warning: this is in the field.

Re-entrant libraries are necessary to make this work, so, that's out
there too. Although I admit that the last time I multithreaded
something, I was careful to  have an "X" thread to do all the
X-windows calls.
-- 
Don		D.C.Lindsay	Carnegie Mellon Computer Science
Newsgroups: comp.arch
From: bernie@metapro.DIALix.oz.au (Bernd Felsche)
Subject: Re: Elegance vs Speed
Organization: MetaPro Systems, Perth, Western Australia
Date: Mon, 21 Dec 92 03:21:18 GMT

I saw the subject line and was wondering if there isn't any
elegance in speed.

If the program or system gives correct results in an
acceptable amount of time, what further elegance should one
look for, for example?
-- 
+-----+ Bernd Felsche                     _--_|\  #include <std/disclaimer.h>
| | | | MetaPro Systems Pty Ltd          /      \ bernie@metapro.DIALix.oz.au
| | | | 328 Albany Highway,              X_.--._/         Fax: +61 9 472 3337
|m|p|s| Victoria Park, Western Australia 6100  v        Phone: +61 9 362 9355
Newsgroups: comp.arch