HDTenEightyP/NetNews huggingface dataset:
From: mayer@sono.uucp (Ron Mayer)
Newsgroups: comp.sys.intel
Subject: Re: PLM programming query
Date: 26 Aug 92 18:27:43 GMT
Organization: Acuson; Mountain View, California


chudley@canon.co.uk (Martin Chudley) <1992Aug26.093356.6125@canon.co.uk> writes:
>
>Apologies for this, it shouldn't be necessary but the PLM manual isn't very
>helpful on this subject.

How true.

>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 -

When I call the procedure, I use the "@" operator to find the address
of the strings; and use the bizzare construct below to zero-terminate
the string.

	call showstring(@('High Voltage Power Supply Failed.',0));

In the procedure being declared, I use something like:

    showstring: procedure (s_base) reentrant public;
        declare s_base				pointer;
        declare s based s_base (1)			byte;
        /* the array s seems to contain the string */
    end showstring;

This is using an old version of Intel's compiler.
    DOS 3.30 (038-N) PL/M-86 COMPILER V2.7
    Copyright Intel Corporation 1980, 1984, 1985
Does anyone know if PL/M compiler technology advanced somewhere within
the past 8 years?  Would anyone know if upgrading has any benifits
(better optimizer, something like libc.a(1/2:-), fewer bugs, fewer
compiler limits (size of strucure, etc))?


>maybe I should just fork out for something sensible like a C
>compiler.

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 :-)).


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
Newsgroups: comp.sys.intel
From: hays@ssd.intel.com (Kirk Hays)
Subject: Re: Future of i860 line
Organization: Intel Supercomputer Systems Division
Date: Wed, 2 Sep 1992 17:13:35 GMT

In article <1992Sep2.163031.15523@col.hp.com>, friedman@col.hp.com (John Friedman) writes:
|> mneideng@thidwick.acs.calpoly.edu (Mark Neidengard) writes:
|> > Wait up.  You speak as if the i860 is not superscalar; it sure as heck IS!
|> > 
|> > It has MULTIPLE pipelines, which can be used concurrently.  That's the
|> > textbook definition of superscalar microprocessing.
|> 
|> Actually, superscalar means that the processor can START executing
|> instructions concurrently, in the same clock cycle, that is.  The 860's
|> cannot do this, but they can be processing multiple instructions at the same
|> time that started at different times.

In that case, the i860 does meet the definition of superscalar, as an integer
core instruction and a FPU instruction can be started in the same cycle using DIM
(Dual Instruction Mode).  Also, a single FPU instruction can use both the
multiply and add pipelines.  Thus, in the limit, it is possible to have both
floating point pipelines and the integer core all working due to instructions
that were started in the same cycle.

I agree the i860 is not superscalar, so your definition must be flawed.  I
suspect a better definition might include some words about the processor
selecting which instructions to execute simultaneously.  The i860 doesn't do
that, but some members of the i960 family do.

[I'm not an Intel officer, so I don't speak for Intel.]
-- 
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.
Xref: sparky comp.sys.intel:1588 comp.sys.palmtops:2771
From: laub@Software.Mitel.COM (Boniface Lau)
Newsgroups: comp.sys.intel,comp.sys.palmtops
Subject: Re: Flash Cards
Date: 25 Aug 92 23:36:40 GMT
	<1992Aug19.133302.3243@crd.ge.com> <1992Aug23.050415.14904@uwm.edu>
Organization: Mitel. Kanata (Ontario). Canada.
In-reply-to: anthony@csd4.csd.uwm.edu's message of 23 Aug 92 05:04:15 GMT

>>>>> On 23 Aug 92 05:04:15 GMT, anthony@csd4.csd.uwm.edu (Anthony J Stieber) said:

Anthony> Yes, and even $800 for 20MB of solid state memory in the
Anthony> space of four or so stacked credit cards is *very* cheap.
Anthony> Right now the cheapest 2MB SRAM PCMCIA card is nearly $700.
		       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I bought my 2MB PCMCIA card couple weeks ago and paid only US$389 -
almost half of your price!

I got it from Active Data (800)223-0503 or (714)997-7718. 

Active Data provides excellent services and I have read many satisfied
customers posting their praise!
--
Boniface Lau    (613) 592-2122 ext. 3042    Boniface_Lau@Mitel.COM
Mitel Corp.  				    
350 Legget Drive, Kanata
Ontario, Canada, K2K 1X3
Organization: Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.sys.intel
Date: Wed, 26 Aug 1992 13:58:45 -0400 
From: Brian Patrick Dunphy <bd29+@andrew.cmu.edu>
Subject: X Windows

I'm trying to run X windows on a 386-40 connected to an internet network
using a 10-BaseT network card.  What is the best approach?  
I've seen the new Desqview/x and it seems to have the options that I
want but is a little more expensive than I would like.  I'm currently
running windows 3.1 and would prefer something that runs under it.

Thanks, 
Brian 

BD29@ANDREW.CMU.EDU
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.sys.intel
Subject: Re: Upgradability question for INTEL staff
Date: 26 Aug 92 13:37:11 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <183203@pyramid.pyramid.com>, atam@pyrps5.eng.pyramid.com (Alexander Tam) writes:
| I bought a DECpc 433ST EISA system recently. As I know, the motherboard, CPU
| module board and memory module board are made by Intel. My question is:
| 
| 	Is it really possible to upgrade my 486 EISA to 586/P5 later by just
| 	switching the CPU module board and putting more memory to the memory
| 	module board?

  I'm not from Intel, but I'll say that my contact there indicates that
it could be done. Now, DEC is going to making their own PCs, or so they
say, and may not offer the upgrade, or Intel may decide not to offer the
upgrade board for marketing reasons.

  I guess the answer is "it could be done, but it may not be."

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.sys.intel
Subject: Re: Future of i860 line
Date: 31 Aug 92 17:37:22 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1860@junkyard.UUCP>, joe@junkyard.UUCP (Joseph Sarkes) writes:
| Perhaps what intel will do is jam the 860 onto the 586 or 686 die
| as an accellerator/vector fp unit and share the caches tween the
| two and give more people(the entire 86 market place) the chance to
| see how neat a chip it is.

  The P5 chip that Intel was going to release had a faster FPU, although
I don't know if it was related to the 860 FPU or not. From remarks made
at FORUM I now believe that the P5 as it has been reported will never be
available to the public. The Intel speaker talked around the topic, but
implied that the chip was simply not manufacturable in commercial
quantities and that Intel is going to a new process to get the chip size
down, speed up, power consumption down, and yield up.

  Note that I am getting this from two people who were at the talk, I
missed it myself. If any other readers were there please add to this.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.
Newsgroups: comp.sys.intel
From: lfm@pgroup.com (Larry Meadows)
Subject: Re: Future of i860 line
Date: Wed, 26 Aug 1992 14:06:15 GMT
Organization: The Portland Group, Portland, OR

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
Newsgroups: comp.sys.intel
From: 32616@brahms.udel.edu (Alexander Ti Schwarm)
Subject: 486DLC Cyrix
Organization: University of Delaware
Distribution: usa
Date: Sun, 30 Aug 1992 23:06:32 GMT



From: jgm@hpdmd48.boi.hp.com (John McBride--in my own private Idaho)
Date: Thu, 3 Sep 1992 15:09:03 GMT
Subject: Re: help on AMD
Organization: HP-Boise, ID
Newsgroups: comp.sys.intel

>My problem is to convince the seller that Am386 is not good and I have
>read some artikels in news about the same problems (with the board not
>the seller) and now they a gone. Can anyone send me these and some other
>info about it?

I really doubt it was the Am386.  It was More likely the motherboard itself,
especially given all the low budget motherboard manufacturers around.
I doubt AMD would have sold more than 100 386s if there was a problem 
with them.

John McBride
Newsgroups: comp.sys.intel
From: engel@gdstech.grumman.com (Steve Engel)
Subject: i860 Experimenter's Platform
Organization: Grumman Data Systems, Woodbury, New York, USA.
Distribution: usa
Date: Thu, 27 Aug 1992 13:23:56 GMT

This is posted on behalf of John Whitson, who doesn't have network access.

I'm looking for a basic bare-bones i860 system for experimental hardware
designs. Very few requirements:

	o	Some RAM, some PROM with a bare-bones bootstrap,
		clock, and CPU.
	o	Some Wire-Wrap pins
	o	A Serial Port (or parallel port)
	o	Some Documentation
	o	No Disk, Tape, Ethernet, SCSI, HIPPI, etc. interface.

Ideally, something like Intel's QT960 package or like the old SDK-85.
Unfortunately, Intel doesn't supply one for the i860 family. Any help
would be welcome.

Send E-Mail replies to engel@gdstech.grumman.com, or by phone to
John Whitson, (516) 346-2892, or FAX to (516) 346-8125 if you so desire.
And thanks for your input!

John Whitson					Grumman Aircraft Systems
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.sys.intel
Subject: Re: Future of i860 line
Date: 28 Aug 92 16:24:46 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <TMH.92Aug26230950@doppel.first.gmd.de>, tmh@doppel.first.gmd.de (Thomas Hoberg) writes:

| 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?

  Please realize that I am a casual 860 user who talks to serious
users... but the problem seems to be that there is not (or maybe was
not) a good C compiler which would generally take advantage of the
performance of the chip. During another discussion I had several people
tell me that the 860 would run about 4x faster hand coded than with the
best compiler they could buy. These were people who were using it for
image processing and DSP and who /liked/ the chip, so I don't think it's
being badmouthed.

  To some extent this is true of the FPU in the x87 line as well, but
not nearly to that extent. I did hand code one inner loop (11
instructions) for speed a few years ago, and got about 40% by playing
with the FP stack like a pipe organ. I would not expect a compiler to do
the things I did, and the small gain indicates that while there is room
for improvement the compiler do pretty well.

  The inner loop ran 600 million times per frame, so it was definitely
worth it!

-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.
Newsgroups: comp.sys.intel
Subject: Re: Future of i860 line
From: mneideng@thidwick.acs.calpoly.edu (Mark Neidengard)
Date: Sat, 29 Aug 1992 00:29:28 GMT
Organization: Academic Computing Services, Cal Poly San Luis Obispo

In article <1992Aug28.182116.4396@megatek.com> megatek!rstewart@uunet.uu.net writes:
>
>>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.
>>>
>>>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?
>>
>
>My guess is that it is not a superscalar design. The chip relies heavily
>of the code generating all the pipe lining. This makes  compiler
>writing difficult (right Larry?). It makes assembly coding difficult.
>It leads to slower nominal performance rates. While an i860 is very fast
>on an infinitely long vector:vector operation (100 mflop @ 50 M) for 
>floating point that doesn't vectorize, it is less than blazing. 
>
>Superscalar designs also handle concurrent execution of different processing
>units alot nicer. 
>
>So, if INTEL took an i960 core, expanded it to 64 bits wide, mix in floating
>point, of i860 speeds, with out that damned pipelining by hand stuff, 
>had some SHARED registers between the floating point
>and integer sections, did speculative instruction execution on the alu and
>fpu, provided a 64 bit alu which ops could be segmented into 
>2*32, 4*16, or 8*8 bit concurrent 2's compliment operations, AND ALLOWED THE
>ENTIRE DATA CACHE TO BE BOOT TIME SELECTABLE AS EITHER DATA CACHE OR MEMORY
>MAPPED FAST DATA STORAGE, I'd be happy, and I think it would sell, IMHO. 
>
>-Rich
>
>rstewart@megatek.com

Wait up.  You speak as if the i860 is not superscalar; it sure as heck IS!

It has MULTIPLE pipelines, which can be used concurrently.  That's the
textbook definition of superscalar microprocessing.

Mark Neidengard
mneideng@cosmos.acs.calpoly.edu
From: schludermann@sscvx1.ssc.gov
Newsgroups: comp.sys.intel
Subject: WANTED 403 documentation & cache daughter board
Date: 2 Sep 92 01:24:26 GMT
Organization: Superconducting Super Collider Laboratory


    I need a cache daugher board and documentation for the intel 403
microcomputer.
                                   Thanxs,
                                          Kris
Newsgroups: comp.sys.intel
From: lfm@pgroup.com (Larry Meadows)
Subject: Re: Future of i860 line
Date: Fri, 28 Aug 1992 20:10:57 GMT
Organization: The Portland Group, Portland, OR

In article <1992Aug28.182116.4396@megatek.com> megatek!rstewart@uunet.uu.net writes:
> [ discussion about why the i860 failed deleted ]
>
>My guess is that it is not a superscalar design. The chip relies heavily
>of the code generating all the pipe lining. This makes  compiler
>writing difficult (right Larry?). It makes assembly coding difficult.

Right.

>It leads to slower nominal performance rates. While an i860 is very fast
>on an infinitely long vector:vector operation (100 mflop @ 50 M) for 
>floating point that doesn't vectorize, it is less than blazing. 
>
>Superscalar designs also handle concurrent execution of different processing
>units alot nicer. 
>
>So, if INTEL took an i960 core, expanded it to 64 bits wide, mix in floating
>point, of i860 speeds, with out that damned pipelining by hand stuff, 
>had some SHARED registers between the floating point
>and integer sections, did speculative instruction execution on the alu and
>fpu, provided a 64 bit alu which ops could be segmented into 
>2*32, 4*16, or 8*8 bit concurrent 2's compliment operations, AND ALLOWED THE
>ENTIRE DATA CACHE TO BE BOOT TIME SELECTABLE AS EITHER DATA CACHE OR MEMORY
>MAPPED FAST DATA STORAGE, I'd be happy, and I think it would sell, IMHO. 
>
>-Rich
>
>rstewart@megatek.com

All this stuff sounds like nice for imbedded systems, but much of it sounds
pretty useless for general purpose CPUs, at least the part about the segmenting
and the cache mapping.

I don't think that the hand pipelining is so bad, although being able to
issue multiple fp instructions without freezing would be fine.  However, I
do agree that the lack of superscalar between the integer, multiplier, and
adder is a problem.  If it were truly superscalar rather than dual-op+dual-mode,
it would be a lot easier to compile to.

I still think that good system designs can make the i860 competitive with
existing general-purpose risc chips.
-- 
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: Fri, 28 Aug 1992 18:21:16 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.
>>
>>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?
>

My guess is that it is not a superscalar design. The chip relies heavily
of the code generating all the pipe lining. This makes  compiler
writing difficult (right Larry?). It makes assembly coding difficult.
It leads to slower nominal performance rates. While an i860 is very fast
on an infinitely long vector:vector operation (100 mflop @ 50 M) for 
floating point that doesn't vectorize, it is less than blazing. 

Superscalar designs also handle concurrent execution of different processing
units alot nicer. 

So, if INTEL took an i960 core, expanded it to 64 bits wide, mix in floating
point, of i860 speeds, with out that damned pipelining by hand stuff, 
had some SHARED registers between the floating point
and integer sections, did speculative instruction execution on the alu and
fpu, provided a 64 bit alu which ops could be segmented into 
2*32, 4*16, or 8*8 bit concurrent 2's compliment operations, AND ALLOWED THE
ENTIRE DATA CACHE TO BE BOOT TIME SELECTABLE AS EITHER DATA CACHE OR MEMORY
MAPPED FAST DATA STORAGE, I'd be happy, and I think it would sell, IMHO. 

-Rich

rstewart@megatek.com
Newsgroups: comp.sys.intel
Subject: Re: PLM programming query
From: mosterman@mswe.dnet.ms.philips.nl (Wim Mosterman)
Date: 28 Aug 92 10:41:19 +0100
Organization: Philips Medical Systems Nederland

In article <1992Aug26.093356.6125@canon.co.uk>, chudley@canon.co.uk (Martin Chudley) writes:
> 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

For PLM-51 try this one:

/****************************************************************/
/* procedure which wants a pointer to a CONSTANT string		*/
/****************************************************************/
write_string: PROCEDURE (ptr, type) USING 2 PUBLIC;
    DECLARE type	BIT;	/* TRUE means ptr points to CONSTANT */
    DECLARE ptr		WORD;
    DECLARE string1	BASED ptr (1) BYTE CONSTANT;
    DECLARE string2	BASED ptr (1) BYTE AUXILIARY;

    IF (type) THEN DO;
 	/* Use string1 for constant type */
    END ELSE DO;
 	/* Use string2 for non-constant type */
    END;
END write_string;

/****************************************************************/
/* The calls:							*/
/****************************************************************/
DECLARE output_string (80)	BYTE AUXILIARY;

    CALL write_string(.('any string', 0DH, 0AH, 0), 1);
    CALL write_string(.output_string, 0);

Disclaimer:
	I'm not sure that the syntax is okay everywhere.
	I assembled this from some old sources I made long ago.

Hopefully this helps.
.-------------------------------..-------------------------------.
|  .--.          ,-.  ,-.       ||                        ,-----.|
|  \   \        /   \/   \      ||                        |     ||
|   \   \  ,.  /          \     ||                        |     ||
|    \   \/  \/   /\  /\   \    ||  Wim Mosterman         `-----'|
|     \          /  `'  \   \   ||  Philips Medical Systems      |
|      \   /\   /        \   \  ||  Best, The Netherlands        |
|       `-'  `-'          `--'  ||  mosterma@mmra1.ms.philips.nl |
`-------------------------------'`-------------------------------'
From: joe@junkyard.UUCP (Joseph Sarkes)
Newsgroups: comp.sys.intel
Subject: Re: Future of i860 line
Date: 29 Aug 92 20:44:22 GMT

Perhaps what intel will do is jam the 860 onto the 586 or 686 die
as an accellerator/vector fp unit and share the caches tween the
two and give more people(the entire 86 market place) the chance to
see how neat a chip it is.
-- 
My opinions are of course my own, but are indeed for sale 
(to the highest bidder).  Don't shoot!! I know secrets!! 
Joseph Sarkes		(junkyard!joe)
Newsgroups: comp.sys.intel