Very Computer

Hello,

Has anybody used the ability to read and write in little endian mode on
sparc v9 implementations? I've read about specifying ASI_PRIMARY_LITTLE with
the load and store alternate instructions, but I'd like to do this from C if
possible.

What about marking the executable as little endian? Or a library (shared or
static) as little endian?

thanks for any suggestions,
Marc

D.J. Bernstein's CDB package always stores numbers in the CDB
databases as little-endian 32-bit integers.  

  http://cr.yp.to/cdb.html

You can check out his pack/unpack routines for examples of how to read
little-endian data into sparc big-endian integers.

--
--Ed Cashin                     integrit file-verification system:

    Note: If you want me to send you email, don't munge your address.

Hi,

Thanks for your reply, but I'd like to use the sparc v9's ability to handle
little endian data natively (and avoid the overhead of converting from
little endian to big endian).

Marc

I've never heard of it being done. I do read and write both endian's alot,
I just swap the bytes as a needed before writing and after reading.

--
http://www.math.fsu.edu/~bellenot
bellenot <At/> math.fsu.edu
+1.850.644.7189 (4053fax)

You can only alter this by setting a value in a privileged register, which a
user mode program does not have access to. Also if your process was little
endian then you could never call the operating system (assuming SPARC
Solaris), since your data would be bogus.

You could write inline asm procedures to read/write using the little endian
alternate address space. If you want functions to accept and swap a value
rather than being given a memory address you can write the value to temp
memory and then read it back using the little endian asi.

In my Modula-2 compiler is have a builtin function, SWAPENDIAN, that uses
the little endian asi on SPARC machines. On Intel it uses the bswap
instruction.

--
Norman Black
Stony Brook Software
the reply, fubar => ix.netcom

Quote:> Hello,

> Has anybody used the ability to read and write in little endian mode on
> sparc v9 implementations? I've read about specifying ASI_PRIMARY_LITTLE
with
> the load and store alternate instructions, but I'd like to do this from C
if
> possible.

> What about marking the executable as little endian? Or a library (shared
or
> static) as little endian?

> thanks for any suggestions,
> Marc

Quote:> You can only alter this by setting a value in a privileged register, which
a
> user mode program does not have access to.

At least for sparc v9 the ASI register allows non-priveleged reads and
writes (section 3.2.4 of the sparc v9 arch manual).

Quote:> Also if your process was little
> endian then you could never call the operating system (assuming SPARC
> Solaris), since your data would be bogus.

Thanks, that makes sense. I read that HAL System's sparc64 chip (a sparc v9
implementation) uses whatever is in the ASI register even when the trap
level is greater than 0. Does this mean that system calls on an OS (possibly
Solaris) running on the HAL's sparc64 chip would indeed work in this case?

Quote:

> You could write inline asm procedures to read/write using the little
endian
> alternate address space. If you want functions to accept and swap a value
> rather than being given a memory address you can write the value to temp
> memory and then read it back using the little endian asi.

I'll keep this in mind.

Quote:

> In my Modula-2 compiler is have a builtin function, SWAPENDIAN, that uses
> the little endian asi on SPARC machines. On Intel it uses the bswap
> instruction.

Do you get a significant performance boost by using the little endian asi
over manually swapping bytes?

tia,
Marc

Quote:> At least for sparc v9 the ASI register allows non-priveleged reads and
> writes (section 3.2.4 of the sparc v9 arch manual).

I am new to the SPARC but the ASI register is only used for the immediate
format of the load alternate instructions. It does not affect all load/store
instructions.

Our system explicitly puts the NO_FAULT ASI value into the ASI register to
allow certain instruction scheduling optimizations. This means I must use
the register load alternate format for my SWAPENDIAN built-in.

Quote:> Thanks, that makes sense. I read that HAL System's sparc64 chip (a sparc
v9
> implementation) uses whatever is in the ASI register even when the trap
> level is greater than 0. Does this mean that system calls on an OS
(possibly
> Solaris) running on the HAL's sparc64 chip would indeed work in this case?

I am not knowledgeable enough to comment.

Quote:> > In my Modula-2 compiler is have a builtin function, SWAPENDIAN, that
uses
> > the little endian asi on SPARC machines. On Intel it uses the bswap
> > instruction.

> Do you get a significant performance boost by using the little endian asi
> over manually swapping bytes?

It is more of a register allocation issue in the compiler, so I took this
route. Since a good register byte swapper on the SPARC processor would take
a few registers the register allocator would have to specially reserve some
registers for this specific operator. I implemented the SWAPENDIAN built-in
function as an operator in the compiler. Writing to a scratch memory
location and reading back requires nothing "special" so I took this route.
This can be slower than pure registers since it involves two memory
operations. It depends on if the memory location is cached. I did/do not
consider byte swapping a critical path of any application. So at least for
now I do the write then read alternate.

If you were to write an inline function for byte swapping I would write it
in high level code using shifts/ands/ors. I know for one, our compiler gets
"restricted" in optimization when user assembly code is inserted into normal
high level code. High level code gives the compiler free reign. If you want
to use the little endian asi, then you may be stuck with assembly.

--
Norman Black
Stony Brook Software
the reply, fubar => ix.netcom