[Top] [All Lists]

Re: A question about architecture and byte order with RPMs

To: Greg Chesson <>
Subject: Re: A question about architecture and byte order with RPMs
Date: Fri, 5 Dec 1997 00:39:43 +0100
Cc: Alan Cox <>,,,
In-reply-to: <>; from Greg Chesson on Thu, Dec 04, 1997 at 11:42:21AM -0800
References: <> <>
On Thu, Dec 04, 1997 at 11:42:21AM -0800, Greg Chesson wrote:

> Future MMUs are in the future.  I'm more interested in solving the problem
> in a device-independent way.  Also, doing it on a page basis is a bit
> restrictive and limits your options.

Basically I think that the reverse endian bit as it is implemented in
the kernel isn't too useful.  As things are in the EntryLo register
pair on R4000 and better no bit to do things on a per page base as
Alan suggests is left.  Well, at lest not in the lower six bits that
currently contain the control information.  If the reverse endian
bit would also reverse accesses to userspace when running in kernel
mode, it'd be much better for performance as most of the byteswapping
could be left out.  Ok, this in the hope some silicon guys are reading
on this list. (Are there any?)

As far as your original suggestion goes - yes, there is a way to declare
variable attributes in GCC.  It works like:

  unsigned int zumbitsu __attribute__((unaligned));

This for example tells GCC that the variable zumbitsu may not be
allocated correctly aligned and it should generate code that takes
care of that.  Goodbye, address error :-)  This stuff is documented
in the GCC info pages, search for ``variable attributes'' and
``function attributes''.

Extending that mechanism to do byteorder swapping shouldn't be too
hard.  I however don't believe this to be a too useful mechanism
for most applications because a compiler doesn't know if used in
a particular context struct foo has to be swapped or not.

Did you propose this mechanism for Risc/OS 6?


<Prev in Thread] Current Thread [Next in Thread>