HDTenEightyP/NetNews huggingface dataset:
From: hays@ssd.intel.com (Kirk Hays)
Subject: Re: Future of i860 line
Organization: Intel Supercomputer Systems Division
Date: Mon, 31 Aug 1992 17:02:11 GMT

In article <1992Aug31.151640.16824@megatek.com>, rstewart@ganglia.megatek.uucp (Rich Stewart) writes:
|> In article <Btr4Iz.GB9@pgroup.com> lfm@pgroup.com (Larry Meadows) writes:
|> >In article <1992Aug29.031847.28867@nas.nasa.gov> klee@wilbur.nas.nasa.gov (King M. Lee) writes:
|> >>
|> >>One reason why the i860(tm) did do better may be that good compilers
|> >>were not available when it was first introduced. It would have been
|> >>better for the i860 if they had developed compilers while designing
|> >>the chip. The compilers have improved, but it may be too late.
|> >
|> >Are you listening, Intel?
|> >
|> >>
|> >>Of all the modern micros, the i860(tm) is the  only one I know of
|> >>that allows one to bypass cache. There are two instructions to
|> >
|> >Yes!  Very good point.  If you can't bypass cache then you have
|> >to hope/arrange for re-use, which is much harder.
|> >-- 
|> >Larry Meadows		The Portland Group
|> >lfm@pgroup.com
|> 
|> Stop this. You can bypass cache on lots of chips. Most caching cpu's
|> can have cache bypassed in the page tables. A second way, if your board
|> is designed to do it, is a software toggle of some sort. I think, most
|> modern cpu's, have a cache enable/disable pin.

Ah, but tha i860 is the only one that allows you to do it on a load-by-load
basis, without a lot of OS and page table crufting about, and without flipping
mode bits, which was Larry's point.

|> And finally, you do not want to use pfld's that might access memory
|> that is in a cachable address range. (Right Larry?).

Nope, wrong. The pfld instruction works just fine on something which is in cache
- the main memory access gets ignored, and the value from the cache is returned.

All in all, the i860 is rather strange, but when you hit the "sweet spot", watch
out.

-- 
Kirk Hays - NRA Life.
Start your day with a little civil disobedience.  Call BATF at 1-800-ATF-GUNS or
1-800-RUN-GUNS, tell them what you think of gun grabbers and government employees
that encourage people to narc on their neighbors.  Good for the soul.
From: scottw@boulder.Central.Sun.COM (Scott Wiesner)
Newsgroups: comp.sys.intel
Subject: Re: Who's winning VESA/PCI ?
Date: 2 Sep 92 07:43:48 GMT
Organization: Sun Microsystems, Inc.
Distribution: world
Reply-To: scottw@boulder.Central.Sun.COM
NNTP-Posting-Host: boulder.central.sun.com

I've seen lots of companies selling "local bus" machines, but I'm not aware
that any of them are actually based on the VESA proposal.  VESA only voted
on the proposal on 8/28, and assuming it passed (I haven't heard yet), it is
now a VESA standard.  VESA is going to treat this standard more carefully 
than they've done in the past with things like the VGA standards because 
compliance is important.  I believe there will be a testing lab used to verify
VL-Bus compliance, and companies will certify their hardware through this
lab and then have the right to use a trademarked/copyrighted/whatever logo
in sales materials, packaging, etc.  

If the proposal passed, I would assume that we'll see a flurry of press releases
from companies supporting the standard.  

I know almost nothing about PCI.  Sorry.

Scott Wiesner
SunSoft
Boulder, Colorado
From: frank@clark.edu (Frank Torres)
Newsgroups: comp.sys.intel
Subject: Who's winning VESA/PCI ?
Summary: want to buy a computer
Keywords: VESA, PCI, matured.
Date: 1 Sep 92 07:36:07 GMT
Distribution: usa
Organization: Clark College, Vancouver, Wa.  USA


    I was wondering if VESA or PCI was taking off.  I have noticed 
more machines using VESA Local Buses and not PCI's(INTEL).  Does anyone
know at this time in the great game of things who is winning.  Also, I
would like to know if local buses have matured enough to go and buy a
local bus system.

   You may email mail me or post it to this news group I read it a lot.

Email Address: frank@clark.edu
Thanks frank.
Newsgroups: comp.sys.intel
From: lfm@pgroup.com (Larry Meadows)
Subject: Re: Future of i860 line
Date: Tue, 1 Sep 1992 15:15:07 GMT
Organization: The Portland Group, Portland, OR

In article <1992Aug31.151640.16824@megatek.com> megatek!rstewart@uunet.uu.net writes:
>Stop this. You can bypass cache on lots of chips. Most caching cpu's
>can have cache bypassed in the page tables. A second way, if your board
>is designed to do it, is a software toggle of some sort. I think, most
>modern cpu's, have a cache enable/disable pin.
Yeah, but at full bus bandwidth in user mode in a way that works for every
system?
>
>And finally, you do not want to use pfld's that might access memory
>that is in a cachable address range. (Right Larry?).
Easy if you are vectorizing.
-- 
Larry Meadows		The Portland Group
lfm@pgroup.com
Newsgroups: comp.sys.intel
From: rstewart@ganglia.megatek.uucp (Rich Stewart)
Subject: Re: Future of i860 line
Reply-To: megatek!rstewart@uunet.uu.net
Organization: Megatek Corporation, San Diego, California
Date: Mon, 31 Aug 1992 15:16:40 GMT

In article <Btr4Iz.GB9@pgroup.com> lfm@pgroup.com (Larry Meadows) writes:
>In article <1992Aug29.031847.28867@nas.nasa.gov> klee@wilbur.nas.nasa.gov (King M. Lee) writes:
>>
>>One reason why the i860(tm) did do better may be that good compilers
>>were not available when it was first introduced. It would have been
>>better for the i860 if they had developed compilers while designing
>>the chip. The compilers have improved, but it may be too late.
>
>Are you listening, Intel?
>
>>
>>Of all the modern micros, the i860(tm) is the  only one I know of
>>that allows one to bypass cache. There are two instructions to
>
>Yes!  Very good point.  If you can't bypass cache then you have
>to hope/arrange for re-use, which is much harder.
>-- 
>Larry Meadows		The Portland Group
>lfm@pgroup.com

Stop this. You can bypass cache on lots of chips. Most caching cpu's
can have cache bypassed in the page tables. A second way, if your board
is designed to do it, is a software toggle of some sort. I think, most
modern cpu's, have a cache enable/disable pin.

And finally, you do not want to use pfld's that might access memory
that is in a cachable address range. (Right Larry?).
-Rich
Newsgroups: comp.sys.intel
From: kunkee@ferranti.com (randy kunkee)
Subject: Re: PLM programming query
Organization: Unix/Xenix Support Group
Date: Fri, 28 Aug 1992 15:28:30 GMT

In article <MAYER.92Aug26102743@porky.sono.uucp> mayer@sono.uucp (Ron Mayer) writes:
>Yeah, me too.  Unless you have a huge codebase of existing PL/M code
>which needs to be maintained, I'd _strongly_ recommend switching to C
>(or c++, fortran, lisp, forth, teco, assembly language, or anything
>but PL/M (1/2 :-)).
>

Ditto for us.

>
>Also, on a similar subject, has anyone had any experience with any of
>these things, could you let me know your opinions of them:
>
>    The plm front end for GCC supposedly being developed by someone at
>    the "Technical Research Centre of Finland, Laboratory for
>    Information Processing (VTT/TIK)"
>
>    The PL/M-86 to C converter by
>    "Micro-Processor Services, Inc.; (516) 499 4461"
>
>
>    Ron Mayer
>    mayer@acuson.com


I've spoken to the MPS folks, and decided that our PLM code was too
idiosyncratic to work well with them.  We have Robert Ankeney's
translater and will be enhancing it ourselves to translate PLM to C.
Still, if your PLM is not very convoluted, MPS might work well.  We
just had some different ideas about how things should be done.

The e-mail address in Finland is tml@tik.vtt.fi.  I'm sorry I don't
know the name.  The posting was some months ago, and it would be
interesting to find out how this work is going.
-- 
Randy Kunkee
Ferranti International Controls Corporation
12808 W. Airport Blvd.  Sugar Land, TX 77478
UUCP: uupsi!ficc!kunkee       ph: (713) 274-5132
INTERNET: kunkee@ferranti.com
From: jgm@hpdmd48.boi.hp.com (John McBride--in my own private Idaho)
Date: Wed, 2 Sep 1992 15:01:45 GMT
Subject: Re: Intel 486 on-chip cache in a multiprocessor config ?
Organization: HP-Boise, ID
Newsgroups: comp.sys.intel

>>Can the 486  on-chip cache maintain cache coherency in 
>>a shared memory MP configuration ? 
>>
>>Al Dykes
>>---------
>>adykes@jpr.com

>   Yes, it has bidirectional address lines.
>   I don't recall, however, if it can implement Exclusive/Shared/Dirty/Invalid
>status on the cache and source its data to other caches, or will only flush
>the cache or a single line when an address in its cache is given to the chip
>from an outside system. 
>-- 
>         -----> All opinions expressed here are my own, not IBM's <-----
>Raul Izahi Lopez	Izahi Engineering
>izahi@bsc.no		IBM Bergen Environmental Sciences and Solutions Centre
>			Thormoehlensgate 55, 5008 Bergen, NORWAY (47-5)54-4653

The 486 has write-through caches, so it only implements the Valid 
(Exclusive/Shared) and Invalid states of the MP MOESI cache protocol.  
(The 486 can't tell the difference between a line that is exclusive 
and shared, since it only has a valid bit.) 

Typically, 486 MP systems will have a second level cache that will take
care of the MP protocol for each 486.  An MP system with write-through cache
CPUs would not perform terribly well, because the of MP bus bandwidth
chewed up by all the writes.

John McBride
From: white_ca@lrc.edu
Newsgroups: comp.sys.intel
Subject: help me
Date: 31 Aug 92 18:57:22 GMT
Organization: Lenoir-Rhyne College, Hickory, NC


Can anyone tell me anything about the Onyx computer.  The computer that I
have was originally used in a floral shop. It has the TeleFloral
name printed on the keyboard. Any info. would be appreciated.

*************************************************************************
*                    * Evidence that TX men do grow weary!!!            *  
*                    *  If life is but a dream, then dreamers are those * 
*Charles White       *  who see a vision of a reality soon to come.     *
*1220 8th st N.E.    *                                                  * 
*Hickory, N.C. 28601 *                                                  *
*************************************************************************   
Newsgroups: comp.sys.intel
From: adykes@jpradley.jpr.com (Al Dykes)
Subject: Intel 486 on-chip cache in a multiprocessor config ?
Organization: Unix in NYC
Date: Mon, 31 Aug 1992 17:07:10 GMT

Can the 486  on-chip cache maintain cache coherency in 
a shared memory MP configuration ? 

Al Dykes
---------
adykes@jpr.com




Newsgroups: comp.sys.intel,comp.sys.palmtops
From: anthony@csd4.csd.uwm.edu (Anthony J Stieber)
Subject: Re: Flash Cards
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Date: Fri, 28 Aug 1992 05:22:33 GMT

In article <w4cns9n.payner@netcom.com> payner@netcom.com (Rich Payne) writes:

>Agreed, but voltages above that provided by the batteries requires
>a DC-DC converted, which sucks power as well. So for portable devices,
>power delivered will not equal power consumed for voltages above the
>battery voltage. 

True, and the Kittyhawk drive only needs a 5 volt power supply, so this is
one disadvantage for Flash memory.  However, many machines need a DC-DC
converter anyway as they run at 5 volts while 2xAA batteries only
provide 3 volts.

As far as I know, there are *no* PCMCIA machines with EPROM
programmers, only seperate PCMCIA card drives.  Perhaps someone will
make a card with a built in EPROM programmer, it would be really nice
for all the people out there with other machines.

>>                                      The 4MB card consumes 0.15 watts
>>active, and 0.04 watts standby.  
>
>By active, do you mean reading, writing, or both?

I don't know, there weren't any figures specifically for writing.

>Can several zones be erased simultaneously? Does this increase power
>consumption?

Yes, and yes.

>              And how does the file system do small writes without
>erasing other files? Does it require 256K of cache, and if so will
>this not increase write times by the amount needed to load/read the
>cache?

I don't know, all I've heard about the MS-FFS is that it apparently
works.  I suppose it trys to optimize writes and may use some
mechanisms similar to optical WORM file systems.  For example:  when a
file is opened for overwrite the new data is put into another zone and
the old data is scheduled for erasure, the system might even compare
the old and new data and only write changes.  Small writes aren't a
problem because they are small, when enough of the files have been
deleted or overwritted, the data is copied to another zone and the old
zone is erased.  My guess is that the file system will get very slow
(due to often erasures) if all the zones are full of data.  Even if
caches are used, it will still be a lot faster than a disk drive, and
never slower (except for writes).
--
<-:(= Anthony Stieber	anthony@csd4.csd.uwm.edu   uwm!uwmcsd4!anthony
From: tmh@doppel.first.gmd.de (Thomas Hoberg)
Newsgroups: comp.sys.intel
Subject: Re: Future of i860 line
Date: 26 Aug 92 21:09:50 GMT
Organization: GMD-FIRST, Berlin
In-reply-to: lfm@pgroup.com's message of 26 Aug 92 14:06:15 GMT

In article <BtLGIG.3q2@pgroup.com> lfm@pgroup.com (Larry Meadows) writes:
   In article <1992Aug23.020507.13375@thunder.mcrcim.mcgill.edu> panisset@lightning (Jean-Francois Panisset) writes:
   >From some of the messages posted around here recently, I gather that
   >Intel has announced that there will be no more development of the i860
   >line.
   Actually, the announcement was that Intel had admitted the failure of
   the i860 as a general-purpose CPU.  They still intend to support it in
   graphics and embedded applications; speculation is that they will also
   support it for the iPSC MPP systems.  No followon has been announced,
   but one would obviously be needed if they do indeed plan to continue to
   use i860-like chips in the iPSC.
   -- 
   Larry Meadows		The Portland Group
   lfm@pgroup.com

Why did it fail, though? While there might be better CPUs today, I
thought it pretty good when it came out. Was there anything seriously
wrong with it (except that it'd do virtual caching)? Was it just that
the various vendors were too busy promoting their own designs or
tuning their old architectures? Is it just bad luck that nobody
decided to pick it up or is there something about the i860 that I
missed?
---
Thomas M. Hoberg   | Internet: tmh@first.gmd.de
1000 Berlin 41     |           tmh@cs.tu-berlin.de
Wielandstr. 4      |
Germany            | BITNET:   tmh@tub.bitnet 
+49-30-851-50-21   |
From: chudley@canon.co.uk (Martin Chudley)
Newsgroups: comp.sys.intel
Subject: PLM programming query
Keywords: PLM 8051
Date: 26 Aug 92 09:33:56 GMT
Organization: Canon Research Centre Europe Ltd

Apologies for this, it shouldn't be necessary but the PLM manual isn't very
helpful on this subject.

All I want to do is pass a string to a procedure. At present I'm using the
dot operator to pass a string constant in the function call and a based variable
to access it inside the procedure, and I get garbage. Can anyone send a few
lines of code showing how to do this - maybe I should just fork out for
something sensible like a C compiler.

Thanks

-- 
Martin Chudley (Postmaster)

ARPA : chudley@canon.co.uk				Voice : +44 483 574325
UUCP : ...seismo!mcsun!uknet!canon!chudley		Fax   : +44 483 574360
Xref: sparky comp.sys.intel:1593 alt.lang.asm:363 comp.os.msdos.programmer:8843
From: amodra@ucs.adelaide.edu.au (Alan Modra)
Newsgroups: comp.sys.intel,alt.lang.asm,comp.os.msdos.programmer
Subject: 386SX code optimisation
Date: 27 Aug 92 15:24:15 GMT
Followup-To: comp.sys.intel
Organization: Information Technology Division, The University of Adelaide, AUSTRALIA

I'm often involved in producing fast, tight assembly code for things
like BIOS and drivers.  One little thing that helps here is to put
entry points into code on machine word boundaries ie. on a 386SX align
to word boundaries, and on a 386DX align to dword boundaries.  OK you
say, that's all fairly obvious - feed as much code as you can into the
CPU pipeline on its first fetch.  The curious thing about a 386SX is
that it often pays to align to addresses that are an odd multiple of
two.  Anyone know why this is so ?

I suspect it may be that the internal pipelines of the 386SX are 32 bits
wide, and the prefetch unit gets as much of the first dword as it can
before passing instructions on to the next stage.  This means that if
your first code fetch is on a dword boundary, you get two word reads
before anything happens.  If your first code fetch is on an odd multiple
of 2 address, then you read only one word.

Here's some relative timing I measured on one of my 386SX systems, for
64K of repeated JMPs and other code snippets:

                                     Start address mod 4
                                  0       1       2       3
Code              bytes                    Timing
JMP short         EB,02,xx,xx   1.208   1.208   1.000   1.318
JMP near          E9,01,00,xx   1.000   1.000   1.091   1.091
JNC short         73,02,xx,xx   1.203   1.203   1.000   1.312
JNC long          0F,83,00,00   1.000   1.158   1.000   1.075
NOP; JMP short    90,EB,01,xx   1.065   1.065   1.000   1.076
MOV AX,AX; JMP    89,C0,EB,00   1.000   1.089   1.009   1.089
XCHG BX,BX; JMP   87,DB,EB,00   1.058   1.076   1.000   1.136
MUL BP; JMP       F7,E5,EB,00   1.062   1.062   1.000   1.087

Timing is normalized to the fastest time in each row.

Anyone from Intel like to comment on why the 386SX (mis)behaves this
way?  I'd expect this sort of behaviour on a 386DX with 16 bit memory
but not on a 386SX which can (and does) fetch words rather than dwords.
Newsgroups: comp.sys.intel
From: hoffberg@phebos.aps.anl.gov (Mike G. Hoffberg)
Subject: 8051 C compilier
Keywords: 8051
Organization: Argonne National Laboratory, Chicago Illinois
Date: Wed, 2 Sep 1992 14:28:51 GMT


I am looking for a C compilier for the 8051 which can take advantage
of running multiple tasks and manage interrupts.

Currently I am using the Archimides "Timesaver" C-51 compilier, it is
ill suited for this task.

There are two other companies that I know of which produce C
compiliers for the 8051, Franklin and Keil Electronics (of Germany).
Does anyone know of a US distributer for Keil Electronics?  Or of any
other compiliers on the market?

Thanks in advance,

MIKE
-- 
Michael Hoffberg               /.\ <Build APS>    "Jeez, am I the only  ~\   /~
hoffberg@phepbos.aps.anl.gov  // \\ Argonne        one who paid full      \ / 
hoffberg@anlaps.aps.anl.gov  //_O_\\ National      price?" F.F.            | 
Zippy was here              /__| |__\ Lab                  Obbyn! Obbyn!  _|_
From: grs@werple.pub.uu.oz.au (Gary Schmidt)
Newsgroups: comp.sys.intel
Subject: How can I identify CPU types ??
Date: 23 Aug 92 13:27:51 GMT
Followup-To: poster
Organization: Werple public-access Unix, Melbourne

I want to be able to programmatically identify which variation of the Intel
80x86 my program is running on, without having to use protected mode
instructions.

I would like some assemby code that I can assemble for any OS, be it MeSsy-DOS,
*NIX, PICK, OS/2, ... etcetera, that does not need any high privs to be run,
and will tell me whether I am on an 8086, 80286, 80386, or an 80486.  I really
want something that will allow me to determine the difference between a '386
and a '486, not so much whether it's an SX step or not, but whether it is a
'486.

Please bear in mind that I do not want to switch the processor in and out of
various modes, and I want the sort of stuff that could be linked into any
piece of code.

	Cheers,
		Gary	B-)

-- 
______________________________________________________________________________

  Gary R. Schmidt          Internet/ACSNet/FishNet: grs@werple.pub.uu.oz.au
______________________________________________________________________________
From: t9214309@phillip.edu.au
Newsgroups: comp.sys.intel
Subject: ipsc simulator ??
Date: 25 Aug 92 20:18:38 GMT
Organization: RMIT (Bundoora Campus)

Dear Netters:
I would like to know if there is any public domain version of the ipsc
simulator. I am looking for one to run on the SUN SPARC or the SONY W/S.
I remember that UIUC had a simulator that works on the SUN W/S. Could 
someone out there send me instructions of how to get one?
Thanx in advance
Madhav
e-mail : t9214573@phillip.edu.au
Newsgroups: comp.sys.intel
From: klee@wilbur.nas.nasa.gov (King M. Lee)
Subject: Re: Future of i860 line
Organization: NAS, NASA Ames Research Center, Moffett Field, CA
Date: Sat, 29 Aug 92 03:18:47 GMT




In article <TMH.92Aug26230950@doppel.first.gmd.de> tmh@doppel.first.gmd.de (Thomas Hoberg) writes:
>In article <BtLGIG.3q2@pgroup.com> I write:
>   Actually, the announcement was that Intel had admitted the failure of
>   the i860 as a general-purpose CPU.  They still intend to support it in
>   graphics and embedded applications; speculation is that they will also
>   support it for the iPSC MPP systems.  No followon has been announced,
>   but one would obviously be needed if they do indeed plan to continue to
>   use i860-like chips in the iPSC.
>

One reason why the i860(tm) did do better may be that good compilers
were not available when it was first introduced. It would have been
better for the i860 if they had developed compilers while designing
the chip. The compilers have improved, but it may be too late.

Of all the modern micros, the i860(tm) is the  only one I know of
that allows one to bypass cache. There are two instructions to
laod floating point registers; a normal load which will fetch 
from cache if there is a hit and load a line of cache if there is 
a miss; the second, a pipelined load, will fetch from cache if 
there is a hit and from main memory without updating cache if 
there is a miss. If data is in cache, normal loads are faster.
If data will not be reused, pipelined laods may be faster.
Judicious use of these two instructions can
make some numerically intensive code run fast.  
Unfortunately, the compilers do not normally generate the pipelined load 
instructions because of the complexity in deciding whether
whether  data will be reused.  This may be the reason that assembly 
language programmers can get good results (they know the algorithm), 
but compilers do not.  This, I think, is  very important point because
for numerically intensive code, memory bandwidth is very important.




--

King Lee
klee@nas.nasa.gov
Xref: sparky comp.sys.intel:1592 comp.sys.palmtops:2782
From: anthony@csd4.csd.uwm.edu (Anthony J Stieber)
Newsgroups: comp.sys.intel,comp.sys.palmtops
Subject: Re: Flash Cards
Date: 27 Aug 92 17:10:32 GMT
Organization: Computing Services Division, University of Wisconsin - Milwaukee

In article <fr-n==q.payner@netcom.com> payner@netcom.com (Rich Payne) writes:

>This? Flash EPROM sounds interesting, but it still seems to me that
>the voltage and power requirements to -write- to it are far above the
>power requirements for a small drive. It would not seem that the present
>FLASH EPROM would be a replacement for current small HD's. But I think
>it still would be usefull. 

Voltage isn't the same as power.  The 4MB card consumes 0.15 watts
active, and 0.04 watts standby.  The main problems with Flash EPROM are
that it takes on the average 2 seconds to erase a 256KB zone.  The
entire zone must be erased.  Once erased, writes take 10us per byte and
reads are 200ns maximum, data transfer at 8MB/s.  The card can be shut
down between accesses so it takes no power, then be instantly powered
back up.  A disk drive will take a few seconds just to spin up.  Disk
drives also have head and rotational latency.  Note that all the figures
I have are for 4MB cards, 20MB cards may differ significantly.

I could certainly see a 20MB Flash card replacing a Kittyhawk or
similar drive in at least some applications.  Simply by size and power
consumption, two or more 20MB cards would fit where only one hard drive
would.  They may end up more complementary that competitive however.
Even a drive as small as the Kittyhawk could probably have a few
megabytes of Flash memory for use as cache.  This could give the low
power and speed of Flash with the low cost of disk.
--
<-:(= Anthony Stieber	anthony@csd4.csd.uwm.edu   uwm!uwmcsd4!anthony
Newsgroups: comp.sys.intel