Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!rpi!crdgw1!crdos1!davidsen
From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
Newsgroups: comp.arch
Subject: Re: MIPS, Compaq and Microsoft in bed - NYT story
Message-ID: <3199@crdos1.crd.ge.COM>
Date: 14 Feb 91 14:11:55 GMT
References: <29920@usc> <45758@mips.mips.COM> <3188@crdos1.crd.ge.COM> <5974@labtam.labtam.oz>
Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen)
Organization: GE Corp R&D Center, Schenectady NY
Lines: 27

In article <5974@labtam.labtam.oz> graeme@labtam.labtam.oz (Graeme Gill) writes:

| 	Just a small point, but a lot of these machines have memory alignment
| restrictions. How do you ensure address alignment if you can't do an
| AND on an address ?  Isn't being able to do integer arithmetic on addresses
| the more general solution to testing alignment and calculating structure/array
| addresses ? (I am refering here to machine level rather than language level
| facilities).

  I think you're correct in saying that something in the hardware must
be able to generate an alligned address. I don't think that requires
moving addresses into ints and ANDing them, as long as there is a way to
do it.

  There are certainly portable ways to get alligned addresses, from
things like the C malloc() or the Pascal new. This moves the problem
from the portable part (the high level source) to the machine dependent
part of the library.

  It is a good point, though, that the hardware must provide allignment,
even if it can handle unalligned addresses. Note that Convex does this
by trapping the access, faking it in software, and generating a
nastygram for the user to encourage fixing the code.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
  "I'll come home in one of two ways, the big parade or in a body bag.
   I prefer the former but I'll take the latter" -Sgt Marco Rodrigez