HDTenEightyP/NetNews huggingface dataset:
From: hoffman@xdelta.enet.dec.com
Newsgroups: comp.arch
Subject: Alpha PALcode (was PALcode instructions vs TRAP instructions)
Date: 12 Aug 92 20:41:36 GMT
Reply-To: hoffman@xdelta.enet.dec.com ()
Organization: Digital Equipment Corporation



|>So I understand: on hardware-reset/power-up

    The Alpha Architecture (of which the 21064 microprocessor is the first
    implementation) does not load the PALcode, the system console is
    responsible for the load.  The system console itself may be a PROM-based
    "embedded" console, or it may be an external or "detached" processor. 
    Examples of these types of consoles from the VAX family are the VAX 6000
    series console and the VAX 8840 console, respectively.  Hybrid consoles
    are also allowed by the architecture.

|>The Alpha-chip loads through its serial interface max. 8kB into its cache.

    I do not know where you are deriving the maximum size, the use of
    the cache, nor the requirement that the chip perfrom the load via
    a serial interface.  This is not to say that there are no such
    limits or restrictions in the architecture, just that I am unaware
    of such limits.  (I do know that the Alpha Architecture specifically
    relegates the details of the PALcode load to the implementation.)

|>This code, among other things, loads through the serial interface the PAL-Code
|>and writes it to some RAM, from where it can be executed as fast as everything.
|>
|>Access, and change of it, by system software might be possible by catching
|>requests of page table changes and preventing write access to those pages.
|>But doesn't this slow down the system? Every access to the page tables,
|>which happens quite frequently, has to checked.

     I am not sure I follow your logic -- the console is responsible
     for much/all of the memory and page table setup required during
     system bootstrap, and is quite capable of reserving "private"
     memory for use by the console or the PALcode.

|>I also could not find in the Alpha architecture handbook a flag about PALcode
|>state. There may be one on the chip, but not as part of the architecture.

     The PALcode state is part of the Alpha Architecture.  Look in the
     Per-CPU slots of the Hardware Restart Parameter Block (HWRPB).
From: eletanjm@nuscc.nus.sg (TAN JIN MENG)
Newsgroups: comp.arch
Subject: Re: CACHE MISS PENALTY FOR 386/486??
Date: 20 Aug 92 01:50:43 GMT
Article-I.D.: nuscc.1992Aug20.015043.7280
Organization: National University of Singapore

Let me try to *narrow* down the options.

I'm interested in order of magnitude only - I realise how difficult it
might be.

Lets define a "typical AT clone" as a non memory interleave system, main
memory DRAM access with 1 wait state - no other special memory access
scheme and the external memory cache is implemented in a standard manner
regards INTEL recommendations.

I've seen discussions on this topic re. RISC systems but have not seen
one regarding x86 or 68xxx.

jin meng
From: S_JUFFA@iravcl.ira.uka.de (|S| Norbert Juffa)
Newsgroups: comp.arch
Subject: Re: Debugging feats (was Re: Why would you like a debugger (
Date: 13 Aug 1992 18:16:23 GMT
Organization: University of Karlsruhe (FRG) - Informatik Rechnerabt.
Distribution: world
NNTP-Posting-Host: irav1.ira.uka.de
X-News-Reader: VMS NEWS 1.23

In <1992Aug12.165324.27749@bcars64a.bnr.ca> schow@bqneh3.bnr.ca writes:


> 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.
>
Having also been a "student advisor" (in Germany we call them "tutor") in the
computer room some time back, I would support Stanley's opinion. I, too, would
occasionally amaze students by picking out there bugs as soon as I saw their
code. I am pretty much sure that after doing a lot of debugging work, you find
a lot of bugs by a kind of pattern matching. Plus you know where to look for
the most common errors: uninitialized pointer? function side effects due to use
of global veriables? procedure entry and exit code? stack corruption
(unbalanced PUSH and POP)? (the last two apply especially to assembly language 
programming. Taking into consideration that Prof. Knuth has 30 years of
programming experience while I have only 10 years, I find it very well possible
that he finds bugs just by flipping thru a printout.
> --
> 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.

Norbert
-------------------------------------------------------------------------------
Norbert Juffa       email:S_JUFFA@IRAVCL.IRA.UKA.DE         Live and let live!
From: peter@ferranti.com (Peter da Silva)
Subject: Re: 32 => 64 Transition
Organization: Xenix Support, FICC
Date: Thu, 20 Aug 1992 18:18:40 GMT

In article <MARC.92Aug19170300@marc.watson.ibm.com> marc@watson.ibm.com (Marc Auslander) writes:
> The intent of ANSI C appears to be that int is the "natural"
> arithmetic of the machine.  This is reflected in the integer promotion
> rules, which promote to int but NOT to long.

Well, is 64 bits the natural arithmetic of Alpha? The 68000 was a "32 bit"
processor, but the best code was generated with 16 bit ints. In any case,
making int larger than long is explicitly contrary to the standard.

	[long = int * int;]

> is defined to do its arithmetic in int, producing an int result, and
> then convert to long at the assignment.  If i+j overflows (as int) the
> results are undefined.

This is true, and is the way existing C compilers on non-vaxian systems
behave. But [32 = 16 * 16] *is* the natural multiplication mode, and a
good compiler will use a single 16-32 multiply here.

Personally, I think long should have been 64 bits all along, from the VAX
on, to allow [64 = 32 * 32], the natural VAX multiply.

In any case:
		PDP	68K	286	VAX	VAX+
	char	 8	 8	 8	 8	 8
	short	16	16	16	16	16
	int	16	16	16	32	32
	long	32	32	32	32	64
	char*	16	32	16/32	32	32

We have some people noting that long==32, and assuming that's the important
non-variant, giving this sort of model:

		VAXist
	char	 8
	short	16
	int	64
	long	32
	char*	64

Another useful property is that all word sizes be available. This is what DEC
seems to have chosen:

		Alpha
	char	 8
	short	16
	int	32
	long	64
	char*	64

So long as you don't want a single addressible object over 2 GB, this should
create no problems.

I don't have the instruction set in front of me, but this would appear to
imply a [64 = 32 * 32] instruction exists, but not a [128 = 64 * 64] one.
If it did, then you'd want to do this:

		Beta
	char	 8
	short	16 or 32
	int	64
	long	128
	char*	64

But what size should short be?
-- 
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
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: interrupt overhead
Organization: Intel Corp., Hillsboro, Oregon
	<Brsx7o.G69@zoo.toronto.edu> <1992Jul22.163956.57436@cc.usu.edu>
	<Brus8r.2K7@zoo.toronto.edu> <Brv1E9.76t@zoo.toronto.edu>
Date: Tue, 18 Aug 1992 22:56:22 GMT

    >Pretty much the inescapable minimum is two pipeline breaks plus a cycle for
    >the "return from interrupt" instruction...

    John Carr has pointed out to me, in private mail, that a clever CPU
    doesn't actually need to flush its pipelines, if the things in the
    pipeline are guaranteed not to incur exceptions.  So it's potentially
    not much worse than a couple of taken branches.

This is a latency versus thruput tradeoff.

If you insert interrupts at the end of the pipe, instead of clearing
the pipe, you are potentially adding to the interrupt delivery
latency.


--

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
From: zstern@adobe.com (Zalman Stern)
Subject: Re: 32 => 64 Transition
Organization: Adobe Systems Incorporated
Date: Sat, 22 Aug 1992 00:12:34 GMT

In article <id.X1JS.KFC@ferranti.com> peter@ferranti.com (Peter da Silva)  
writes:
> In article <MARC.92Aug19170300@marc.watson.ibm.com> marc@watson.ibm.com  
(Marc Auslander) writes:
> > The intent of ANSI C appears to be that int is the "natural"
> > arithmetic of the machine.  This is reflected in the integer promotion
> > rules, which promote to int but NOT to long.
> 
> Well, is 64 bits the natural arithmetic of Alpha? The 68000 was a "32 bit"
> processor, but the best code was generated with 16 bit ints. In any case,
> making int larger than long is explicitly contrary to the standard.
> 
> 	[long = int * int;]
> 
> > is defined to do its arithmetic in int, producing an int result, and
> > then convert to long at the assignment.  If i+j overflows (as int) the
> > results are undefined.
> 
> This is true, and is the way existing C compilers on non-vaxian systems
> behave. But [32 = 16 * 16] *is* the natural multiplication mode, and a
> good compiler will use a single 16-32 multiply here.
> 
> Personally, I think long should have been 64 bits all along, from the VAX
> on, to allow [64 = 32 * 32], the natural VAX multiply.
> 
> In any case:
> 		PDP	68K	286	VAX	VAX+
> 	char	 8	 8	 8	 8	 8
> 	short	16	16	16	16	16
> 	int	16	16	16	32	32
> 	long	32	32	32	32	64
> 	char*	16	32	16/32	32	32
> 
> We have some people noting that long==32, and assuming that's the  
important
> non-variant, giving this sort of model:
> 
> 		VAXist
> 	char	 8
> 	short	16
> 	int	64
> 	long	32
> 	char*	64
> 
> Another useful property is that all word sizes be available. This is what  
DEC
> seems to have chosen:
> 
> 		Alpha
> 	char	 8
> 	short	16
> 	int	32
> 	long	64
> 	char*	64
> 
> So long as you don't want a single addressible object over 2 GB, this  
should
> create no problems.
> 
> I don't have the instruction set in front of me, but this would appear to
> imply a [64 = 32 * 32] instruction exists, but not a [128 = 64 * 64] one.
> If it did, then you'd want to do this:
> 
> 		Beta
> 	char	 8
> 	short	16 or 32
> 	int	64
> 	long	128
> 	char*	64
> 
> But what size should short be?
> -- 
> 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

--
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
Newsgroups: comp.arch,comp.lang.c
From: ssimmons@convex.com (Steve Simmons)
Subject: >>>>>>>>>  What would you like in a debugger?
Date: Sun, 16 Aug 1992 17:50:45 GMT
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

> 
> There are several more important problems that need to be solved
> first.  I'll be happy to define some way for debuggers to talk to
> each other across machines once I find one or two that do what I
> want on a single machine.  To be absolutely frank, the current
> state of debugging "technology" is little short of abysmal.  I
> don't use any debugger at the present time on UNIX systems because
> I haven't found a single good one.  I don't care whether the debugger
> displays linked lists nicely in an X environment.  This (without
> fail) means that the programmers have concentrated on the GUI to
> the detriment of the basic functionality of the debugger.
> 
> Seeing as nobody else has written a debugger that I'm happy with,
> I'm designing one myself.  To be frank, I was somewhat disappointed
> with many of the responses to my original question; people seem to
> be more worried about the number of widgets they can twiddle than
> whether their debuggers help them trace problems efficiently.
>
>        -- Bryan

Bryan:

You are definitely a true developer ... You ask people their opinions...
None of them agree with yours and so you go out and reinvent the 
wheel. ;-) 

I've followed the thread here.  Most people have suggested key requirements
within a debugger. In fact, most of them are mundane and have been
implemented in one form (or another) in "a" debugger.   The problem 
is that no one debugger provides it all.  

My advice is the following... Start with the source for one debugger... 
(maybe gdb or dbx).  Then, rewrite the code to do you what you think is 
right.   I can guarantee two things.  Some people will love it and some
people will hate it.  We wrote ours from scratch and it took 6-8 people 
over one year to do it.   Personally, we probably made a mistake in 
this tactic although we were limited by GNU's copyright.  Also, we 
spent much time dealing with issues of optimized code debugging. 
Good luck from one CXdb developer (Convex's debugger). 

Thank you. 


					Steve Simmons 
Newsgroups: comp.arch,alt.folklore.computers
From: dave@imax.imax.com (Dave Martindale)
Subject: Re: Babbage books (was: Proposal: Computer History Project)
Organization: Imax Corporation, Mississauga Canada
Date: Thu, 13 Aug 1992 18:13:53 GMT

In article <1992Aug11.134401.26906@grmbl.saar.de> me@grmbl.saar.de writes:

>He also didn't use asynchronous counters (I mean that the force,
>you use to turn in the lowest number wheel gets used to turn the
>whole bank of wheels if you have a carry which propagates from
>the lowest to the highest decimal). This gets important if you
>have a very big number of decimals (his universal machine had
>about fifty). All tolerances add together and the wheels get
>stuck.

This is not true of the Difference Engine, at least.  The basic addition
is done with all digits in parallel, but that's a relatively constant load.
Any carries generated just result in a little lever being moved to a
new position (Babbage called it "warned"), but no carry propagation happens
at this stage.

Then, when the main addition is done, another piece of mechanism comes
into play to handle carry propagation, and that is done serially.
Each digit wheel is rotated one place if a carry is pending in that
position, and any "carry in" that creates a "carry out" at this stage
simply sets the "carry in" lever for the next higher digit, before the
carry happens in that place.  So the more digits you have the longer the
carry process takes, but at any given time there are at most two or three
pieces of hardware moving.

I don't know what the Analytical Engine did for addition, though.

	Dave
From: abaum@armltd.uucp (Allen Baum)
Newsgroups: comp.arch
Subject: Re: HP-9100 (was HP-97 Calculator)
Date: 21 Aug 92 13:29:33 GMT
Organization: Advanced RISC Machines Ltd

jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes:

>From article <11AUG199221494044@erin.caltech.edu>,
>by shoppa@erin.caltech.edu (TIM SHOPPA):
>>                                                 ... my HP calculator (an
>> old desktop unit, whose model number I can't recall right now, that has

>You have a classic antique desktop computer, one of the first two
>programmable calculators ever marketed!  Save it and care well for it,
>because it'll be a museum piece someday.

>The diode matrix contains low level microcode [for] a digit serial processor
>The middle layer microcode is stored in a braided wire memory;

I agree! The HP9100A (the first machine I ever programmed) is amazing.

I thought that the microcode was stored in an inductively coupled ROM, consisting of
a 14 layer pc board, where the inner layer traces defined the bits. The Russians
copied this calculator, which meant they had to peel back every layer of the PC board
to do it.

The digit serial processor was extremely primitive- it couldn't add, just increment or
decrement a digit. Addition/subtraction was programmed from that, and multiplication,
division, exps/trigs/etc. programmed from those.

The logic family is interesting. The boards are masses of diodes, (& resistors) packed
about as tightly as you could, with a few transistors here and there. It was discrete
DTL logic, with additional feature that one of the inputs was the power supply, and
it was wired up so that the input least likely to be turned on was the one connected
to the power supply, to conserve power.

-- 

----------------
Allen J. Baum		Apple Computer		baum@apple.com, abaum@armltd.co.uk
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.arch
Subject: Re: Why would you like a debugger (Was: What would you like in a debugger?
Date: 12 Aug 92 19:21:22 GMT
	<19920809.175600.935@almaden.ibm.com> <1241@esl.ESL.COM>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Coleg Prifysgol Cymru

On 12 Aug 92 01:25:36 GMT, davida@barney.esl.com (David Alexander) said:

davida> Somewhere in the midst of my 10000 lines of WEB code I was
davida> following a pointer incorrectly and spent a week banging my head
davida> against the wall trying to track down this one bug.  Then we had
davida> our weekly meeting, and as we're talking, Prof. Knuth is
davida> flipping through my WEB source which he had never been shown
davida> before, and about 40 pages into the listing, in the middle of
davida> our discussion, he says, "By the way, here's your NIL pointer
davida> error..." [ ... ]  Not everyone can be Donald Knuth.

Well, maybe not in other ways, but in this way *everyone* can be like
him. If one writes programs knowing what they do, instead of trying to
see if they are going to work, it becomes very easy to debug like this.

If you know, or can easily discern, the flow of predicates of your
program, it takes only a very small deductive ability to trace back from
symptom to the predicate that has been violated.


On the other hands debuggers are invaluable, because the method above
fails when there are bugs in the supporting environment (preprocessor,
include files, compiler, libraries, OS, etc...). Such debuggers almost
by necessity must be assembler level debuggers.
--
Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
Newsgroups: comp.arch
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: Why would you like a debugger (Was: What would you like in a debugger?
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: Thu, 13 Aug 92 14:42:26 GMT

In article <id.8J9S.1P4@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>In article <343@moene.indiv.nluug.nl> toon@moene.indiv.nluug.nl (Toon Moene) writes:
>> OK, but I only explained why *I* wouldn't use a debugger. Note: here's my  
>> silent assumption: Debuggers are slow: they've a steep learning curve,  
>> load slowly, take their time to reach the breakpoint you think will tell  
>> you what's going wrong (I often watch my colleagues using one - it's so  
>> much fun :-)
>
>What, slower than recompiling the program with appropriate printfs?
>
>I don't use debuggers often, and if I had a fast enough interactive compiler
>I wouldn't use them at all, but they're a hell of a lot faster than "make"
>when you get down to the last bit of troubleshooting.


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's easy to get in a situation where you THINK you have changed something,
or maybe you haven't, but you went and had coffee, then the phone rang...

Granted, the ability to make deltas reduces the potential harm here,
but I MUCH prefer non-intrusive (from the source code modiciation 
standpoint) debuggers.




Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
Newsgroups: comp.arch
From: solman@athena.mit.edu (Jason W Solinsky)
Subject: Re: question on computer systems using Alpha ...
Organization: Massachusetts Institute of Technology
Date: Thu, 13 Aug 1992 01:34:35 GMT

In article <1992Aug11.132311.1793@ryn.mro4.dec.com>, bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar) writes:
|> 
|> >In article <1992Aug10.202955.4254@talon.ucs.orst.edu>, lus@ucs.orst.edu (Shih-Lien Lu) writes:
|> > I was reading the Alpha uP spec and notice that it runs with a 3.3V
|> > power supply. Is it correct to assume that most of the memory and peripheral
|> > chips are still powered with 5V supply? How would one put chips
|> > of different supply voltages into one system? Thanks in advance.
|> > 
|> The input pins are capable of being driven by standard 5V TTL/CMOS devices. The
|> outputs drive up to 3.3V which is well within the range for TTL devices being 
|> driven. The CPU does need 3.3V. Most of the surrounding logic is generally 5V.
|> We have been using 3.3V microprocessors for VAX for a few years now. You can 
|> derive the 3.3V from a standard 5V supply by using a DC to DC regulator on your
|> circuit board.

I remember seeing an Alpha presentation where a very elaborate multi-staged
system was used to scale up the outputs to a full 5V. Are you sure that the
21064 can't do that?

Jason W. Solinsky
Newsgroups: comp.arch
From: zrepachol@cc.curtin.edu.au (Paul Repacholi)
Subject: Re: PALcode instructions vs TRAP instructions
Organization: Curtin University of Technology
Date: Mon, 17 Aug 1992 15:49:30 GMT

In article <1992Aug16.195833.58188@cc.usu.edu>, ivie@cc.usu.edu (CP/M lives!) writes:

...

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

Optional. The BIG difference is tat a VAX will do a TLB re-load in the u-code
but ALL the page table manipulation is at the ISP level in the ALPHA. THis code
must run page fault free of course...

~Paul
From: ivie@cc.usu.edu (CP/M lives!)
Newsgroups: comp.arch
Subject: Re: PALcode instructions vs TRAP instructions
Date: 12 Aug 92 09:22:11 MDT
Organization: Utah State University

In article <1992Aug12.094231.1767@uklirb.informatik.uni-kl.de>, kirchner@uklira.informatik.uni-kl.de (Reinhard Kirchner) writes:
> 
> Access, and change of it, by system software might be possible by catching
> requests of page table changes and preventing write access to those pages.
> But doesn't this slow down the system? Every access to the page tables,
> which happens quite frequently, has to checked.
> 
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.

> I also could not find in the Alpha architecture handbook a flag about PALcode
> state. There may be one on the chip, but not as part of the architecture.
> 
That's part of the software architecture, not the hardware architecture, and
isn't covered by the book. You'll probably have to buy the Alpha VMS Internals
book (haven't seen it yet) to find this sort of stuff. The PALcode section of
the Alpha Architecture Manual talks about lots of things that are part of the
software architecture; such as VMS PALcodes manipulating the "stack" (Alpha
doesn't have one).

Roger Ivie
ivie@cc.usu.edu