HDTenEightyP/NetNews huggingface dataset:
From: schow@bqneh3.bnr.ca (Stanley T.H. Chow)
Newsgroups: comp.arch
Subject: Debugging feats (was Re: Why would you like a debugger (Was: What would you like in a debugger?
Date: 12 Aug 92 16:53:24 GMT
Organization: Bell Northern Research Ltd, Ottawa

In article <1241@esl.ESL.COM> davida@barney.esl.com (David Alexander) writes:
>  [problem with big WEB program]
>Then we had our weekly meeting, and as we're talking, Prof. Knuth
>is flipping through my WEB source which he had never been shown before, and
>about 40 pages into the listing, in the middle of our discussion, he says,
>"By the way, here's your NIL pointer error..."  Of course he was correct.

Not to deny Knuth's ability, but it is also possible that he has seen so
many people make the same mistake over and over that he can pick out the
bug by doing local pattern matching. I know that when I was "student
advisor" in the computer room, I used to amaze students by picking out
their bugs before they can even tell me the symtoms. (I don't think I was
unique at all).  Not knowing anything about WEB or the program in question,
this is mere speculation.
  
--
Stanley Chow            InterNet: schow@BNR.CA
Bell Northern Research  UUCP:     ..!uunet!bnrgate!bqneh3!schow
(613) 763-2831
Me? Represent other people? Don't make them laugh so hard.
From: zstern@adobe.com (Zalman Stern)
Newsgroups: comp.arch
Subject: Re: 32 => 64 Transition
Date: 22 Aug 92 00:29:12 GMT
Organization: Adobe Systems Incorporated

In article <1992Aug22.001234.10390@adobe.com> zstern@adobe.com (Zalman  
Stern) writes:
[Complete text of pervious post with no new content.]
I was selecting a bunch of text to delete because NeXT's NewsGrazer always  
excerpts the entire post when you followup. I accidentally dragged the mouse  
across the post button (while still selecting the text) and sure enough it  
sent it off and deleted the post window. Another of many NeXTStep  
mis-features.

Anyway... What I was going to say is that Alpha is very much a natural 64  
bit machine. It has minimal support for 32 bit operations. The R4000 has  
about equal support (or backwards compatibility for the less charitable) for  
32 bit and 64 bit.

In an ANSI C universe, the type size_t is used for array indices, the  
arguemnt to malloc. (ptrdiff_t is the type for the difference of two  
pointers. It is should be the same type as size_t only signed.) In the DEC  
model where int is 32 bits and long and pointers are 64 bits, size_t should  
be typedef'ed to unsigned long. That way you can allocate and manipulate  
arrays larger than 2^32 bytes in size. At MIPS, the counter argument to this  
was that little code out there actually conforms to the ANSI standard and  
people use int variables to index arrays all the time. Hence if you want to  
compile dusty decks and have them use arrays bigger than 2^32 bytes, you  
want int to be 64 bits...
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  "Yeah. Ask 'em if they'll upgrade my shifters too." Bill Watterson
From: mash@mips.com (John Mashey)
Newsgroups: comp.arch
Subject: Re: 32 => 64 Transition
Date: 17 Aug 1992 02:53:25 GMT
Organization: MIPS Computer Systems, Inc.
NNTP-Posting-Host: winchester.mips.com

In article <robert.713773090@cs.anu.edu.au> robert@cs.anu.edu.au (Robert Cohen) writes:
>Who uses 16 bit variables anymore anyway, memory's cheap, right :-)

To answer this quesiton, try:
	cd /usr/include/sys
	cat *.h|grep -c short
for a quick idea.

I.e., a typical UNIX kernel has plenty of shorts, because it has
many dense-packed data structures, and at least some networking
software makes serious use of shorts, as do some device drivers.


If you mostly look at user code,you may decide that
16-bit ints can be done away wit....  but if you look at
kernel code a lot, you may think otherwise...
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com [soon to be mash@sgi.com, but not quite moved yet].
DDD:  	408-524-7015,  or 524-8253
USPS:	(soon) Silicon Graphics, 2011 N. Shoreline Blvd, Mountain View, CA 94043
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: 32 => 64 Transition
Date: 14 Aug 92 01:36:24 GMT
Organization: Auspex Systems, Santa Clara

>And it isn't all ancient history, either. Windows-NT uses Unicode as its native
>character set, requiring 16 bit characters.

Which is *not* the same as requiring 16-bit "char"s in C, odd though
that may sound....

ANSI C has a "wchar_t" type (a typedef), stuck in there as a character
type intended precisely for such character sets as Unicode; I expect
that UNIX, the Mac System, and Windows NT will all have "char" be an
8-bit byte on systems with 8-bit bytes, and have "wchar_t" be 16 or 32
bits for codes such as Unicode.  (It's 16 bits on the machine on which
I'm typing this; it's running SunOS 4.1.1.)
From: tozo@konech.UUCP (Toni Zollikofer)
Newsgroups: comp.arch
Subject: Re: Crossbar switching chips - info needed
Date: 20 Aug 92 07:16:55 GMT
Organization: Kontron Elektronik GmbH Eching, Germany

Maybe you should have a look at the
IDT49FCT804x TRI-PORT BUS MULTIPLEXER.

-------------------------------------------
Toni Zollikofer
Kontron Elektronik
Eching b. Muenchen
Newsgroups: comp.arch
From: HAGAN@deimos.ucc.umass.edu (Craig I Hagan)
Subject: Re: CACHE MISS PENALTY FOR 386/486??
Organization: University of Massachusetts at Amherst
Date: Wed, 19 Aug 1992 20:02:57 GMT
X-News-Reader: VMS NEWS 1.20

In <1992Aug19.042318.10163@nuscc.nus.sg> eletanjm@nuscc.nus.sg writes:

> Just what is a typical cache miss penalty on 
> (1) a 386 system with external cache 
> (2) a 486 system with only internal cache
> (3) a 486 system with internal cache and external secondary cache 
> 
> I'm assuming an typical AT style system.
> 
> Just how do you determine the miss penalty anyway?

Well, i am going to attempt to not make a fool of myself.

My guess would be that you would figure out the miss penalty (maximum
penalty would probably be the best/easiest to computer) by taking the
time to determine that there has been a cache miss, and add the
memory access time of the main memory to that. If you had two
caches (for example, an i486 with both an internal, and an external
cache, then you would have:

time to determine internal cache miss + time to determine external cache miss
	+ time to retrieve the actual data from memory

presumable the first two would be the shortest of the bunch as the
the CAM in the cache controller can process a hit/miss fairly
quickly (this would depend on the controller, naturally - unfortunately
i am not sure of the current speeds of the controllers). 

the last, memory access would be dependant upon the number of wait
states in the memory, as well as the physical speed and layout
of the memory (probably worst case would be between the speed
of the memory [e.g. 60ns, 70ns, 80ns, etc] to something like 10-20ns
above that, but probably very close to the speed of the RAM itself.

A guess on my part would say that a cache miss wouldn't be much
worse than a normal memory access on a similar machine without
the cache.

----------

Craig Hagan
University Computing Center
UMASS/Amherst
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Lengths. Was: Re: 32 => 64 Transition
Date: 15 Aug 92 14:34:48 GMT
Organization: Purdue University Statistics Department

In article <robert.713773090@cs.anu.edu.au> robert@cs.anu.edu.au (Robert Cohen) writes:
>peter@ferranti.com (peter da silva) writes:

>>What size would *you* make an int? 64 bits? What do you do for a 32-bit
>>data type? Short? Then what do you do for a 16-bit data type? Create another
>>abomination "short short" or "long char"? "long long" is bad enough.

>The perfect solution: int= 64, long =128 (for real men's numbers),
>short = 32, char = 8, long char= 16, short short = 24,
>long short = 48 and short long = 96.
>If we need more precision we can start using short short long and
>long short long etc.
>In case anyone hasn't realised yet :-) :-) :-)

>More seriously, I belive that we need a way to machine independently
>specify the precision such as int:32.
>When I write a program I usually know what sort of range I expect
>a variable to have to hold. I dont care if its an int or a long or a short
>on different machines, I want a number about that big.

>Who uses 16 bit variables anymore anyway, memory's cheap, right :-)

There are many situations in which one generates what is essentially
a bit stream, and works with that.  The generation process takes about
the same length of time regardless of the sizes of the "words" produced
up to machine arithmetic size.  I have not found any situations yet 
where using 16-bit blocks is the "right" thing to do, but some situations
which I have not completely investigated may call for it.

There is another usage which will be coming out shortly, that of text
communication not restricted to the Latin alphabet.  I have read on other
groups about a protocol, called unicode, which will use 16 bits/character.
As you have said, memory's cheap, so why should we be limited to 8 bits?

Other sizes which should be considered are 52 (53?), the length of the
significand in an IEEE float, etc.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)
Xref: sparky comp.arch:8911 comp.lang.c:12360 comp.programming:2332 comp.unix.programmer:4313
From: johnm@cory.Berkeley.EDU (John D. Mitchell)
Newsgroups: comp.arch,comp.lang.c,comp.programming,comp.unix.programmer
Subject: Re: Summary of responses [was: What would you like from a debugger?]
Summary: Swat
Keywords: summary,debugging,tcl,swat,pc/geos
Date: 15 Aug 92 00:58:01 GMT
Organization: University of California, at Berkeley

In article <id.SKBS.RIL@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
[...Lots of comments about Tcl and Tk...]

The Swat debugger for GeoWorks' PC/GEOS is built on top of Tcl.  It's by
far the most powerful debugger I've ever seen (let alone used :-).

All of the good points that Peter mentioned in his post are true.
Extensibility in a debugger is truly wonderful.

John
johnm@cory.Berkeley.EDU

P.S.	I'm speaking for myself.  GeoWorks speaks for itself.
Newsgroups: comp.arch
From: rod@philips.oz.au (Rod Roberts)
Date: Fri, 21 Aug 92 02:50:59 GMT
Organization: Philips Public Telecommunications Systems, Melbourne, Australia
Subject: PA-Risc architecture artices. Where to find??
Summary: See Subject
Keywords: PA-Risc HP

I am looking for articles which describe the HP PA-Risc architecture. Can
anyone give me some pointers to where I may be able to ftp these from. How
about you guys at HP, can you help? ThanX in advance.

						       Rod


-- 
Rod Roberts
e-mail: rod@philips.oz.au | Phone: +61 (3) 881 3574 | Fax: +61 (3) 881 3577
Philips Public Telecommunications Systems
23 Lakeside Drive, Burwood East 3151, Melbourne, Victoria, AUSTRALIA
From: ivie@cc.usu.edu (CP/M lives!)
Newsgroups: comp.arch
Subject: Re: PALcode instructions vs TRAP instructions
Date: 16 Aug 92 19:58:33 MDT
Organization: Utah State University

In article <34303@cbmvax.commodore.com>, jesup@cbmvax.commodore.com (Randell Jesup) writes:
> ivie@cc.usu.edu (CP/M lives!) writes:
>>Not really. The OS will believe the console code about how much memory is
>>available. The console reports the memory size as smaller than physical by
>>the amount of memory needed for the PALcode and the console. The OS will not
>>try to use the memory thus reserved for PALcode.
> 
> 	This would seem to be dangerous, because of wild pointers.  Just
> because the OS doesn't know about the memory doesn't mean that there won't
> be a write to those locations.  I do hope that PALcode fetches are checked
> for illegal accesses.

The problem with wild pointers should be solved as soon as the OS is up far
enough to initialize the page tables. If the page tables don't include the
console memory, the OS can't get at them.

At least, that works on a VAX. I'm not sure whether the kernel runs mapped 
on an Alpha. Wouldn't work on a MIPS.

Roger Ivie
ivie@cc.usu.edu
Newsgroups: comp.arch
Subject: Re: Finding which bit set in a bit-string.
From: jcb (Jim Becker)
Date: 12 Aug 92 19:53:58 GMT
Return-Path: <jcb>
To: postnews


   From: schow@bqneh3.bnr.ca (Stanley T.H. Chow)
   
   In article <1992Aug6.153710.8565@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
   >In article <9208041713.AA16446@verbosa.ncd.com>, jcb (Jim Becker) writes:
   >
   >| next  question -- how do you create a bi-directional linked list using
   >| a single 32 bit pointer??? gee, another "trick"!! :)
   >
   >  Pretty neat trick if you have an answer. Or is this a trick question
   >where you say "I didn't tell you that the range of the values is
   >constrained?" Please post to comp.compression, too, how you represent
   >any two possible 32 bit values in only 32 bits.
   
   The question is mis-phrased. The problem is really:
   
      How do you bi-directionally traverse a singly linked list without
      needing extra storage.
   
this is a fuzzy problem definition  as  well,  but  i  really  am  not
interested  in  getting into semantics arguments. please excuse me for
not  being  more  verbose  in  the  problem  description  (very out of
character for me, i can assure you.. :).)

my idea was to get across  the  concept  of  people  asking  interview
questions  that  are  "meaningless  tricks"  rather  than  those which
discern problem solving techniques and experience.

   There are many capabilities of true double links that are not possible
   with the xor scheme.

   Stanley Chow            InterNet: schow@BNR.CA

i always use double links, and have never used tricks like  this,  for
bi-directional list traversal. however, those who mention you can only
traverse the list from first<->last don't  think  of  retaining  _two_
pointers  into  the  list.  with _two_ pointers you can do the same as
with  _one_  in  a "true" bi-directional list, albeit with XOR hacking
and more pointer management overhead.

like i said, i don't code like this. but it might  be  useful  if  you
have memory restraints and like people to call you  "King  Hacker"  to
your face.. :)

apologies  to  those  who  don't  feel  this is appropriate use of the
comp.arch newgroup.  so how many mflops come enabled with  a  base  P5
anyway? :*)

-jim
--
 -Jim Becker / jcb@ncd.com   /   Network Computing Devices, Inc. (NCD)
Newsgroups: comp.arch
From: peter@ferranti.com (peter da silva)
Subject: Re: Why would you like a debugger (Was: What would you like in a debugger?
Reply-To: peter@ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
Date: Sat, 15 Aug 1992 19:32:50 GMT

In article <1992Aug13.144226.8391@yrloc.ipsa.reuter.COM> rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
> Ah, perhaps I'm missing something here, but I personally do NOT like
> the idea of modifying ANY code in order to debug it. That is, insertion
> of printfs is harmful to maintainability. 

It can be. I've had my share of heisenbugs. But I've had about as many "cured"
by running them under the debugger, or by linking with a debugging version of
malloc. A good interpreter/compiler would allow you to make changes in a local
copy, avoiding the telephone problem. Plus, if you use a "DEBUG_PRINTF" macro
they're easy to find...
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180
From: toon@moene.indiv.nluug.nl (Toon Moene)
Newsgroups: comp.arch
Subject: Re: Unnormalized FP and a PDP-11 bug (Re: Algorithm for bit finding)
Date: 14 Aug 92 22:02:42 GMT
Organization: Moene Computational Physics, Amsterdam, The Netherlands

In article <1992Aug12.075553.1@zodiac.rutgers.edu>  
leichter@zodiac.rutgers.edu writes:
[... Interesting story about FP faults generated by copying bytes
     with FP move instructions deleted ... ]

> (My favorite story of a simliar problem is on the CDC 6000 series.  They
> use 1's complement arithmetic, and when you load a B register, you can't
> really load a constant - you load contant plus some other B register.  
> No problem:  B0 is always 0, so you add it.  Except that in one's 
> complement there is also -0 (all 1 bits), and the arithmetic unit tries 
> very hard never to generate -0 as an output.  In fact, 0+(-0) is 0.  So 
> you can't load -0 that way!  The trick is to realize that the REAL 
> identity for addition on this machine is -0, and get that into a 
> register (using bit-wise operations) for use in place of 0 when loading 
> data that isn't really numbers.)

Hm, I wonder why you would want -0 in a 18-bit index register - masking  
instructions only operated on the 60-bit registers ...

I've another horror story on one's complement 'arithmetic'. On the old  
UNIVAC 1100 series computers (36-bit one's complement machines), there  
once was a FORTRAN compiler that stored the 'no-dead-code-in-this-basic-
block' flag in a double (72-bit) integer. Now for optimization, they first  
tested this integer against zero, before examining every bit to determine  
the basic blocks to remove :-) It was certainly interesting hearing this  
customer talk about his large FORTRAN subroutine diminished to a few  
instructions by this compiler ...

--
Toon Moene (toon@moene.indiv.nluug.nl)
Kantershof 269, 1104 GN  Amsterdam, The Netherlands
Tel.: + 31 20 6982029; Fax: + 31 20 6003411
No Disclaimers; a NeXT at home protects against this occupational hazard.
Newsgroups: comp.arch,comp.arch.storage
From: ken@netcom.com (Ken Kofman)
Subject: Memory Hierarchy Questions
Date: Thu, 20 Aug 92 22:28:16 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

Hi,
 
I have a few questions, and I hope this is the right place to post them.
 
Suppose you had a memory device with the following characteristics:
64 bit word width, 512 byte block size (64 words), 700 ns access time,
1280ns transfer time (1 word / 20ns), cost as much as dram but was twice
as dense, and each device had a size of 300-500Mbytes.
 
Would you design it into a system, and, if so, what would you do with it,
other than use it as a ramdisk?  What if the block size were 256 or 64
bytes?  What if the price were a little less than DRAM?
 
Along these lines, I have also developed an interest in learning about
the kinds of memory hierarchies being designed into real-world larger
systems.  The Patterson/Hennessey book was a good start, but I'm also
interested in actual data.  How does doubling main memory from 200Meg to
400Meg, from 0.5Gig to 1Gig, or from 1Gig to 2 impact the miss rate?  What
is the width and access time of this main memory?  What are the
characteristics of the cache hierarchy in the system?  This will probably
vary depending upon the way the system is used.  In short, I would like
to find out what is currently state of the art for larger systems, and
how well they do.
 
I would greatly appreciate any information, or references.
 
I also am curious about the software overhead of a disk access, which
does not seem to be discussed very often, since seek time and rotational
latency tend to dominate disk transactions.
 
Finally, if anyone knows of a good reference on developing simulations of
large memory systems, please let me know.
 
The basic question I'm trying to answer for myself is whether it would be
useful to take a system with its maximum amount of main memory, almost
double the main memory by using the forementioned hypothetical ;-) device
instead of DRAM, and put another level of cache (using paged or SC DRAM)
in front of it.
 
Whew!!  So much to learn.
 
Thank you in advance,
 
Ken Kofman
 

-- 
anti-life and anti-choice
anti-flowers and anti-sunshine
anti-freedom and anti-love
From: stripes@pix.com (Josh Osborne)
Newsgroups: comp.arch
Subject: Re: Why would you like a debugger (Was: What would you like in a debugger?
Date: 15 Aug 92 04:15:26 GMT
Organization: Project GLUE, Merriversity of Uniland, College Purgatory

In article <341@moene.indiv.nluug.nl> toon@moene.indiv.nluug.nl (Toon Moene) writes:
[...]
>one of these (I would be interested in hearing how people debug embedded  
>systems, however). For all other sorts of programming: write critical  
>variable's values to the screen    [...]

I write video games, they are sort-of real time, and definitally embedded
systems.  Sometimes I write veriables to UART port A (port B is used to
talk to the sound device).  Much of the time I use ICE (In-Circuit Emulator).
The ICE I have emulates my CPU and a goodly chunk of memmory (which can
be configured read-only - to simulate ROM without forcing you to re-burn
EEPROMS after each compile, or read-write which I haven't needed to do).

In many ways using ICE is alot easyer then normal debugging.  It is 100%
real-time, even if you are having it do complex stuff.  It can have breakpoints
(or other actions) on data (reads or writes, or more complex things) again
with no speed loss.  It can give you a complete history of the last N 
instructions executed (where N is at least 150 for me), and all the bus cycles
executed.

The ICE I have has downsides.
Normally I run my code until it hits a breakpoint, use the trace data to
figure out what source I was executing, and use my brain for the rest.
A source debugger would let me know alot faster.  If I need to look at
a structure element I have to figure out it's offset by hand and find it.
If I want another ICE (say for testing multi-board games, or testing a
non-devlepment game (i.e. a real test-unit), or whatever) it costs over
$10k.

There does exist ICE that will do (at least some) source level debugging.
I would love some.  As it is, I would rathere run UPS on my code then use
ICE, except I can't afford the speed hit...

(So what do I want in a software debugger?  Mostly just a C++ version
of UPS, and data watchpoints...  what do I want in ICE?  The same :-)
-- 
           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