🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #13404

Re: AMD 29000 byte access -- apology and further commentary

#13404
From: gnu
Date: Sun, 05 Apr 1987 11:09
62 lines
3836 bytes
I stand somewhat corrected.  The AMD 29000 does have byte insert and
extract operations.  They work register-to-register, and take one
cycle.  They *do* depend on state hidden in the system's status
register (the low 2 bits of the last address loaded) so an optimizer is
not free to move the instruction past another load, but they're better
than shifts and masks for sure.  At the time of my posting, I didn't
have the real 29000 manual; it has since arrived.  (Thanx to Phil Ngai for
posting how to order it.)

I said:
> In other words, the designers of the 29000 did not think at all
> about typical Unix code...
In article <15337@amdcad.UUCP>, tim@amdcad.UUCP (Tim Olson) writes:
> Ok, we have taken  deep breaths and counted to 10, so now we can respond
> without flaming (that comment *is* a personal insult).

Sorry for the 'personalness' of the insult; it was unintended.  My 
complaint was with the architecture, not the designers.  I said it badly,
and I'm sorry.

>                                                         One of the goals
> of the Am29000 is flexibility for the user.  The Am29000 allows you to
> either use the byte manipulation instructions in conjunction with a word-
> oriented memory system *or* implement a byte-oriented memory system and
> use the option bits in the load/store control field to select the size of
> a memory access.  The flexibility is there...

Does this mean that a compiler can't tell whether a load instruction
will return the entire word, or just a byte?  It would seem that you'd
need two different compilers, libraries, etc for a machine that really
implemented a byte-oriented memory for the 29000.  If the compiler
generated a 'load' and then an 'extract byte', it would extract the
wrong byte, since the 'load' would have already extracted the
relevant byte into the low end of the destination register.

As I recall, the 29000 also has a mode in which it will trap to the OS
on any unaligned access to memory; this would seem to make both of
the above methods fail.  (Normally it ignores the low 2 bits of the
address.)  Wouldn't this require a third compiler?  And how would you
ever fetch unaligned bytes with this mode turned on?  You could mask
the address before using it, do the word load, then somehow move the
2 low bits into the system status register (may take a few instructions),
then do the extract byte, but it all seems very slow and cumbersome
as a way to get one character from RAM.

> > First you see if the operands overlap, then...are they aligned, then...
> > are they wider than a word, then...wider than two words?, then...

Tim objected to this characterization of how to do strcpy on a word
oriented machine.  However, it still looks to me like a good
description of the strcpy code they posted.

I do like the funnel shifter.

> To see the 8088 and the Am29000 compared, as if they were comparable, is
> worse than our worst nightmares.

AMD sells them both, does it not?
-- 
Copyright 1987 John Gilmore; you can redistribute only if your recipients can.
(This is an effort to bend Stargate to work with Usenet, not against it.)
{sun,ptsfa,lll-crg,ihnp4,ucbvax}!hoptoad!gnu	       gnu@ingres.berkeley.edu
Technical Details
Message-ID: <1960@hoptoad.uucp>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!lll-crg!hoptoad!gnu
References: <15292@amdcad.UUCP> <1001@ames.UUCP> <15313@amdcad.UUCP> <15337@amdcad.UUCP>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!lll-crg!hoptoad!gnu
From: gnu@hoptoad.UUCP
Newsgroups: comp.arch
Subject: Re: AMD 29000 byte access -- apology and further commentary
Message-ID: <1960@hoptoad.uucp>
Date: Sun, 5-Apr-87 06:09:43 EST
Article-I.D.: hoptoad.1960
Posted: Sun Apr  5 06:09:43 1987
Date-Received: Sun, 5-Apr-87 21:47:00 EST
References: <15292@amdcad.UUCP> <1001@ames.UUCP> <15313@amdcad.UUCP> <15337@amdcad.UUCP>
Organization: Nebula Consultants in San Francisco
Lines: 62