HDTenEightyP/NetNews huggingface dataset:
From: vhs@rhein-main.de (Volker Herminghaus-Shirai)
Subject: Re: Swap byte instruction - how high is the win?
Reply-To: vhs@rhein-main.de
Date: Tue, 12 Jan 93 16:43:56 GMT

In article <1993Jan8.224906.15621@athena.mit.edu> jfc@athena.mit.edu (John F  
Carr) writes:
> In article <1993Jan8.111731.19116@odin.diku.dk>
> 	torbenm@diku.dk (Torben AEgidius Mogensen) writes:
> 
> >Newer processors (including the new ARMs) tend to have selectable
> >endianness instead of byte swap instructions.
> 
> The RS/6000 has a duplicate set of load and store instructions that
> byte-swap, but no register to register byte swap instruction.  The
> store multiple and string instructions only come in big-endian forms,
> but those tend to be used when byte reversal isn't important (it
> doesn't matter if the saved registers on the stack are byte swapped,
> as long as they are correct once restored).

Thanks to you and all the others who responded via mail for the info
but I feel I hadn't expressed myself clearly enough. What I am interested
in is "how high is the win" as a quantitative measure, i.e. somthing like
"I compiled an RPC library with a compiler that did not know about the
swap byte instruction (e.g. a 386 compiler) and later with a compiler that
did, and the difference was 5% to the benefit of one that used the swap
byte instruction"
or such. More generally spoken, I want to find out what one in missing
by running, on a 486 machine, a 386 Unix vs. a 486 one (regardless of the
existence of the latter).

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

Looks good on the outside, but -
	intel inside
From: limes@straylight.eng.sun.com (Greg Limes)
Newsgroups: comp.arch
Subject: Re: A theory for Big & Little Endian's origin
Date: 8 Jan 93 17:29:06
Organization: Sun Microsystems Computer Corporation (Mountain View, California,
	USA)
	<willmore.726511292@help.cc.iastate.edu> <16294@auspex-gw.auspex.com>
NNTP-Posting-Host: straylight
In-reply-to: wally@Auspex.COM's message of 8 Jan 93 20:02:07 GMT

In article <16294@auspex-gw.auspex.com> wally@Auspex.COM (Wally Bass) writes:
|   Actually, I think that it's not the 'load' problem so much as it is
|   the 'add' problem. When you are going to do an add on a machine with
|   1 byte adder, you want the low order bytes of both operands first,
|   and the high order bytes last, because that is the direction in
|   which the carry propagates.

One can make an equivalent argument for the 'compare' problem. When
you are going to do a compare on a machine with a 1 byte comparator,
you want the high order bytes of both operands first, and the low
order bytes last, because you can stop working sooner. One can even
point out when sorting records that storing your numbers in big-endian
format means you only need to know the offset and length of the key
fields, not whether they are alpha or numeric.

I believe that whether bytes were big-endian or little-endian was
largely an arbitrary decision when the oldest ancestor of the ISA was
being designed, based on reasons that made sense at the time but which
may now be completely lost in the mist. All we can do now is deal with
the results of the fact that about half the ISAs are "wrong" :-)
Newsgroups: comp.arch
From: rschnapp@metaflow.com (Russ Schnapp)
Subject: Re: Def  of a workstation (a lark)
Organization: Metaflow Technologies Inc.
Date: Thu, 7 Jan 1993 00:28:24 GMT

In article <1993Jan6.165640.2894@lsl.co.uk>, snail@lsl.co.uk writes:
|> On a workstation, software does not worry about how much memory it has; just
|> page it out to disk. Microsoft windows can release memory and re-read it from
|> the disk, but it can't page memory *out* to the disk (not unless it changed
|> recently).

Not terribly recently -- Windows 3.1 has fully virtual memory in
"enhanced mode".  (For some reason, they limit virtual memory to twice
the size of physical memory.)  I believe that 3.1 has been out for a
year or so.
-- 

...Russ Schnapp
BIX: rschnapp           Email: netcom!metaflow!rschnapp or rschnapp@metaflow.com
Metaflow Technologies   Voice: 619/452-6608x230;  FAX: 619/452-0401
La Jolla, California    Unless otw specified, I`m speaking only for myself!
Newsgroups: comp.arch
From: des@inmos.co.uk (David Shepherd)
Subject: Re: Def of a workstation (a lark)
X-Newsreader: TIN [version 1.1 PL8]
Date: Wed, 6 Jan 93 10:48:34 GMT

Yamanari (rsrodger@wam.umd.edu) wrote:
: 	Can anyone give me a definition of workstation,

simple,

	I have a workstation
	You have a PC
	They use terminals

--
--------------------------------------------------------------------------
david shepherd: des@inmos.co.uk                     tel: 0454-616616 x 625
                inmos ltd, 1000 aztec west, almondsbury, bristol, bs12 4sq
                New Year Resolution for 1993: Start using capital letters.
Xref: sparky comp.arch:12201 comp.benchmarks:1922
From: jpenix@uceng.uc.edu (John Penix)
Newsgroups: comp.arch
Subject: Re: A theory for Big & Little Endian's origin
Date: 8 Jan 93 16:39:25 GMT
Organization: University of Cincinnati

In article <1iig7aINNtc@spim.mti.sgi.com> jackc@vermont.mti.sgi.com (Jack Choquette) writes:
>
>To me it seems like different endianess came about because of the way
>humans like to see things listed out.  When humans make a list, they
>like to make and read it top to bottom:
>		0  ******
>		1  ******
>		2  ******
>		 etc.
rest deleted....

I remember reading (and I'll hunt down the title if you'd like) that
IBM's endedness came from a mechanical memory device that was something
like a wheel.  For the bytes to be read in in the proper order for
processing the lower order had to come first.  They stuck with it due
to their standards of backwards compatibility.  I don't recall them
bringing in any linguists :)


-------------------------------------------------------------------------
                               Wife:    "It was sex and drink that killed
   John Penix                            your uncle, sex and drink!"
   jpenix@uceng.uc.edu         Husband: "Ya, he couldn't get either one
   University of Cincinnati              of 'em, so he shot himself."  
                                                             - Benny Hill
-- 
-------------------------------------------------------------------------
                               Wife:    "It was sex and drink that killed
   John Penix                            your uncle, sex and drink!"
   jpenix@uceng.uc.edu         Husband: "Ya, he couldn't get either one
From: michalj@fuw.edu.pl (Michal Jankowski)
Newsgroups: comp.arch
Subject: Re: A theory for Big & Little Endian's origin
Date: 10 Jan 93 10:58:21 GMT
	<C0JE18.8Mp@mentor.cc.purdue.edu> <1993Jan8.100549.28792@sei.cmu.edu>
Organization: Warsaw University Physics Dept.

>>>>> On Fri, 8 Jan 1993 10:05:49 EST, firth@sei.cmu.edu (Robert Firth) said:

Robert> One interesting exception is the mediaeval conceit of
Robert> embedding a roman number in a name or phrase, which of course
Robert> works because the roman numerals aren't positional.
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Huh? Did you forget that IX = 9 and XI = 11?

  Michal
Newsgroups: comp.arch
From: grout@sp90.csrd.uiuc.edu (John R. Grout)
Subject: Re: Speculative Loads
Reply-To: j-grout@uiuc.edu
Organization: UIUC Center for Supercomputing Research and Development
Date: Tue, 5 Jan 93 20:08:27 GMT

glew@pdx007.intel.com (Andy Glew) writes:

>      Compilers can perform significantly more optimizations if accesses
>      to address 0 (and neighbourhood) are guaranteed not to fault.

> [paper reference edited]

I recently wrote a survey term paper on "Instruction-Level Parallelism
Research" (which, due to the large number of requests, is now available via
anonymous FTP from sp2.csrd.uiuc.edu in directory /pub/grout...  if you do not
have anonymous FTP, I will email it in LaTeX or Postscript form upon request).

Here is an edited bibliography from that paper in LaTeX oos-named
bibliographystyle which only has references to papers on speculative
execution:

\begin{thebibliography}{123456789012345678901234567890}

\bibitem[ASPLOS, 1992]{asplos5}
{\em Fifth International Conference on Architectural Support for Programming
  Languages and Operating Systems\/} (Boston, MA, Oct. 1992), ACM.

\bibitem[Chang {\em et~al.}, 1991]{CH91}
Pohua~P. Chang, Scott~.A. Mahlke, William~Y. Chen, Nancy~J. Warter and
Wen-mei~W. Hwu.
\newblock {IMPACT}: An Architectural Framework for Multiple-Instruction-Issue
Processors.
\newblock In \cite{sigarch91}, pp.~266--275.

\bibitem[Lam and Wilson, 1992]{LW92}
Monica~S. Lam and Robert~P. Wilson.
\newblock Limits of Control Flow on Parallelism.
\newblock In \cite{sigarch92}, pp.~46--57.

\bibitem[Mahlke {\em et~al.}, 1992a]{MA92a}
Scott~A. Mahlke, William~Y. Chen, Wen-Mei~W. Hwu, B. Ramakrishna Rao and
Michael~S. Schlansker.
\newblock Sentinel Scheduling for VLIW and Superscalar Processors.
\newblock In \cite{asplos5}, pp.~238--247.

\bibitem[Mahlke {\em et~al.}, 1992b]{MA92b}
Scott~A. Mahlke, William~Y. Chen, Wen-Mei~W. Hwu, B. Ramakrishna Rao and
Michael~S. Schlansker.
\newblock Exception recovery for systems with compiler-controlled speculative
execution.
\newblock CRHC Technical Report, in preparation.

\bibitem[SIGARCH, 1990]{sigarch90}
{\em Proceedings of the 17th Annual Symposium on Computer Architecture\/}
(Seattle, May 1990).

\bibitem[SIGARCH, 1991]{sigarch91}
{\em Proceedings of the 18th Annual Symposium on Computer Architecture\/}
(Toronto, May 1991).

\bibitem[SIGARCH, 1992]{sigarch92}
{\em Proceedings of the 19th Annual Symposium on Computer Architecture\/}
(Gold Coast, May 1992).

\bibitem[Smith {\em et~al.}, 1990]{SM90}
Michael~D. Smith, Monica~S. Lam and Mark~A. Horowitz.
\newblock Boosting Beyond Scalar Scheduling in a Superscalar Processor.
\newblock In \cite{sigarch90}, pp.~344--354.

\bibitem[Smith {\em et~al.}, 1992]{SM92}
Michael~D. Smith, Mark Horowitz and Monica~S. Lam.
\newblock Efficient Superscalar Performance Through Boosting.
\newblock In \cite{asplos5}, pp.~248--259.

\end{thebibliography}
--
John R. Grout						j-grout@uiuc.edu
University of Illinois, Urbana-Champaign
Center for Supercomputing Research and Development
Newsgroups: unix.questions,com.sys.dec,comp.arch,comp.os.vms
From: wagner@utoday.com (Mitch Wagner)
Subject: net.views - dec and alpha
Organization: Open Systems Today
Date: Fri, 08 Jan 93 17:12:43 GMT
Followup-To: comp.unix.questions

       Is Alpha going to revitalize DEC?

       (Please include your involvement with DEC products 
       in your answer---i.e., say if you're a current DEC 
       customer, former DEC customer, ISV, etc.)

 
 
We're asking this question to collect opinions for the "net.views" column in
OPEN SYSTEMS TODAY. Please E-mail your responses to wagner@utoday.com.
 
By responding to that address, you'll be granting permission to OST to publish
your response.
 
In order to use your response, we'd like to know who you are. Please tell us
our real, full name, your job title, your employer, and location---or,
alternately, if you're a student, your class standing (freshman, sophomore,
junior, senior, grad, etc.), college and university, and its location. Please
also include a telephone number where you can be reached during daytime hours
in North America.
 
Please limit responses to about two full screens (24x80) of text, not including
headers and other administrivia.
 
Responses to net.views will be posted to this space in about two weeks.
 
Thanks for participating, and we look forward to hearing from you!
 
 


                         -- mitch w.
--
Mitch Wagner, senior editor, Open Systems Today
2353 Massachusetts Ave. Suite 47, Cambridge, MA 02140
wagner@utoday.com  (617)547-8485  CIS:70212,51  GEnie:MITCHWAGNER  
For subscription information, please call 516/562-5882

Newsgroups: comp.arch
From: peter@ferranti.com (peter da silva)
Subject: Re: Def of a workstation (a lark)
Organization: Xenix Support, FICC
Date: Wed, 6 Jan 1993 16:05:10 GMT

In article <1iarmrINNk28@news.cerf.net> davsmith@nic.cerf.net (David Smith) writes:
> 1. You don't send Bill Gates any money when you buy a workstation

Check your list of copyrights on Solaris. It's based on System V, and System
V includes Xenix code.
-- 
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: alewine@crhc.uiuc.edu (Neal Alewine)
Newsgroups: comp.arch
Subject: Precise Interrupts
Date: 8 Jan 1993 13:09:41 -0600
Organization: Center for Reliable and High-Performance Computing, University of Illinois at Urbana-Champaign
NNTP-Posting-Host: gershwin.crhc.uiuc.edu


I have been trying to fully understand the implications of precise 
versus restartable states relative to their affect on program 
correctness in the presence of interrupts. I have read 
[Smith&Pleszkun,1985], Hennessy&Patterson's Architecture book, 
Mike Johnson's Super-scalar book, and many others but have not 
found an actual example that clarifies the problem. 

What I am looking for is a good example (i.e., a specific scenario) 
which causes program incorrectness if a restartable state is used 
in lieu of a precise state. I will setup the problem the way it 
appears to me. If my setup is flawed, please let me know also.

Assume there is a program sequence; a, b, c, d, e ... and it has 
been reordered. Assume c excepts and an exception handler is invoked 
(if c was speculated it is assumed that the exception handling has 
been delayed until the branch commits and also that the hardware has 
rolled back to instruction c, undoing all changes subsequent to c). 
The system is now in a state which is imprecise (since it is not 
guaranteed to be identical to the system state at c if the original 
program sequence had executed up to c). However the state is 
restartable, because without the exception (or with the exception 
assuming the exception handler runs correctly and does not change 
the current state), we could begin execution with the imprecise 
state, at c, producing the correct program output. 

It appears that there are two potential problems with handling an 
exception on an imprecise (but restartable) boundary. First, the 
exception handler may need the precise state to do it's job right 
or second, the exception handler fails to restore the restartable 
system state upon completion. The exception to the latter case is 
any changes to the system state caused by the exception handler 
which could have been caused by the excepting instruction itself 
are OK, since the dependencies for such changes overlap. I have 
not been able to invent a specific scenario (other than debugging) 
for either case without being able to apply a similar case to an 
in-order sequence which also fails; indicating that a good 
compiler would restrict such a case. 

Any help would be greatly appreciated.

Regards,

Neal Alewine

Keywords: scheduling, precise interrupts, speculative execution
From: wong@rkna50.riken.go.jp (Wong Weng Fai)
Newsgroups: comp.arch
Subject: SPARC Simulator ...
Date: 7 Jan 93 05:49:19 GMT
Organization: Institute of Physical & Chemical Research (RIKEN) Saitama,Japan

Hi,

	Is there a *free* SPARC simulator floating around somewhere in the
public domain ?

	Thanks !

Regards,

W.F. Wong.
Goto Laboratory,
The Institute of Physical and Chemical Research (RIKEN),
2-1, Hirosawa, Wako-shi,
Saitama 351-01, Japan.
email : wong@rkna50.riken.go.jp
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Speculative Loads
Organization: Intel Corp., Hillsboro, Oregon
	<1hm0cpINN8nf@darkstar.UCSC.EDU> <1hm114INN6v2@transfer.stratus.com>
	<GLEW.92Dec31163459@pdx007.intel.com>
Date: Mon, 4 Jan 1993 17:54:38 GMT

	  On a related note (vis-a-vis debugging ease) to the branch-and-link issue, another peeve
	  I've always had is that no commercially available processors (that I know of) make NULL
	  pointer detection easy withou serious run-time overhead.  Various OS's try by unmapping
	  the first N pages of memory, which works fine until you run into a chip like the 68030,
	  which supports huge displacements.  Not to mention if the index register pushes the
	  effective address out of your protected window, you're hosed.  If you have a standard
	  base_reg+index_reg+disp format, it would seem to me that having the processor check the
	  base register for NULL and faulting if it is wouldn't be that hard (or inefficient).
	  Especially if NULL happens to be zero on that machine.

      Rather contradicts another thread.

      Compilers can perform significantly more optimizations if accesses
      to address 0 (and neighbourhood) are guaranteed not to fault.

      See:

	  "Proving safety of speculative load instructions at compile time"
	  David Bernstein
	  Michael Rodeh
	  Mooly Sagiv
	  IBM Israel


Oops, forgot journal:

ConferencePaper {
    Title = "Proving safety of speculative load instructions at compile time"
    Author = "David Bernstein"
    Author = "Michael Rodeh"
    Author = "Mooly Sagiv"
    Affiliation="IBM Israel"

    Book="Lecture Notes in Computer Science 582"
    Editor="B. Krieg-Bruckner (ed.)"
    
    Conference="ESOP 92,
    	4th European Symposium on Programming"

    Place="Rennes, France"
    Date=" Feb 92"

    Publisher="Springer-Verlag"
}

--

Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
Hillsboro, Oregon 97124-6497

This is a private posting; it does not indicate opinions or positions
of Intel Corp.

Intel Inside (tm)
Newsgroups: comp.arch,comp.benchmarks,comp.parallel
From: snail@lsl.co.uk
Newsgroups: comp.arch
Subject: Re: big + little endian (was: Comparison of Alpha, MIPS ..)
Date: 6 Jan 93 17:12:42 GMT
Organization: Laser-Scan Ltd., Cambridge

In article <markg.79.726169747@county.lmt.mn.org>, markg@county.lmt.mn.org (Mark Gilbert) writes:
> In article <WAYNE.92Dec30093950@backbone.uucp> wayne@backbone.uucp (Wayne Schlitt) writes:
>>From: wayne@backbone.uucp (Wayne Schlitt)
> I have identified the root of this whole big-endian/little-endian debate.  
> The conflict is is between text and numbers.  We read left to right.  But, 
> if you were to number the digits of an integer, you would do it right to 
> left.  The one's digit would be 0, the ten's digit, 1, etc.
> 
> This should never have been the case.  We adopted our number system from the 
> Arabs, and the Arabs read right to left.  For them, the direction of reading 
> text and numbers is CONSISTENT.  The whole problem arose because we failed 
> to reverse the numbering system when we borrowed it from the Arabs.
> 
> I propose that we now correct this historical oversight.  Let us write 
> numbers least significant digit first.  The bang symbol can be used to 
> replace the decimal point, in order to distinguish little-endian numbers 
> from big-endian.  The integer six hundred and fifty four should now be 
> written !456.  Sixteen dollars and twenty five cents is now $ 52!61.

You've just proved yourself wrong!

The number six-hundred and fifty four is written 6-5-4, left to right, exactly
the way we write. That is, I read that I have 6 hundreds before I'm interested
in finding out how many tens or units I have. Now I may had to scan the number
for length to work out that the 6 refers to hundreds, but that is a separate
operation.

The number !456 would be read as 4 and fifty and 6 hundred. If I were to read
that at six hundred and fifty four, I would still have to scan the number to
find the hundreds digit, then the tens then the units and combine this to give
the number six hundred and fifty four.

So either way, we must scan the number, just that currently we write the number
the way we say it.

Also: surely $16.25 is actually 52!61$ in your scheme?
-- 
snail@lsl.co.uk      

"Washing one's hands of the conflict between the powerful and the powerless
 means to side with the powerful, not to be Neutral."
                                                     Quote by Freire.
                                                     Poster by OXFAM.
From: sbobadbh@w204zrz.zrz.tu-berlin.de (Shashi-Shakher Mishra)
Newsgroups: comp.arch
Subject: Asynchronous acorn.
Date: 8 Jan 1993 11:24:42 GMT
Organization: ZRZ der TU-Berlin
Distribution: world
NNTP-Posting-Host: w204zrz.zrz.tu-berlin.de
Keywords: How do they interface the new asynchronous acorn with the main memory ? Is the cache asynchronous too ?

Rohit Sharma
sharma@math.tu-berlin.de



Newsgroups: comp.sys.apple,misc.misc,comp.periphs.printers
From: tsdavies@rodan.syr.EDU (T.S. Davies)
Subject: Apple Imagewriter I Fails to Print on Backstroke
Followup-To: poster
Reply-To: T.S. Davies <tsdavies@mailbox.syr.edu>
Organization: Sam Hill Cabal, DS
Distribution: na
Date: Tue, 5 Jan 93 17:38:58 EST


When printing using our (admittedly old) Apple Imagewriter, printing
bidirectionally (the default), the print quality of the right-to-left
strokes of the printhead is very low -- faded and broken.  On the next
stroke (left-to-right), everything is fine.  And if the printer is set
to only print from left-to-right (using ESC >), it prints fine.

The problem is that the main use of this printer is printing
AppleWorks documents, and AppleWorks doesn't allow you to set up a
standard set of control codes to be sent to the printer each time you
print.  Both the database and the spreadsheet allow you to send
special printer control codes from an option table, but the
wordprocessor does not.

The ideal solution would be something that would fix the printer so it
works exactly the way it used to.  Next best would be a way to make it
always print unidirectionally (not possible according to the DIP
switch chart in the manual).  Last best would be a way to convince the
AppleWorks software to send the necessary codes each time you print.

Setup:

Apple //e
512K Applied Engineering memory/80-column card
DuoDisk Drive unit
Super Serial Card
Apple Imagewriter (I)
AppleWorks v. 1.1R

This problem has just recently appeared, which suggests that it's a
question of wear rather than some basic software/hardware
incompatibility.

Any help will be greatly appreciated!  Please respond directly to me,
and I will summarize the replies to the 'Net.


--
I'm enthralled by combine harvesters. In fact, I yearn to have one -- as a pet.
	From _The Day of the Jackal_
-------------------------------------------------------------------------------
    T.S. Davies		tsdavies@mailbox.syr.edu		SHC, DS
Xref: sparky comp.sys.apple:41 junk:71286 tn.general:98 misc.forsale:34957 misc.forsale.computers:45166