[NeoMac]

I hear a lot about how Macs use a different "endian" than PCs. It seems to slow down software and hardware ports to Macs.

Is it feasible for Apple to switch to the PC "end" ?? What would it improve, it anything? Would we have a bigger selection of 3D cards and software, etc??

Just curious.

[Dalgo]

It's a non issue. Switching the endian nature of the processor would break all current apps for the mac, including the OS. In other words apple is never going to do it unless they switch to a totally different processor line which is powerful enough to emulate the PowerPC instruction set at a decent speed.

FYI: The PowerPC processor can run in big or little endian mode, according to Motorola's documentation. It is pretty much a choice that must be made at boot time. It does, however, appear to be less efficient in little endian mode since it looks like some instructions aren't supported and would need to be done via software. Macs use big endian mode.

[AirSluf]

Also, unless they do something like assembler, programmers don't speak in "endians", code that comes out of a compiler for a specific CPU model does. Endian-ness is more an emulation speed issue than a porting one unless you need to be touching code at a very low level with human hands.

[Angus_D]

Originally posted by AirSluf:
<STRONG>Also, unless they do something like assembler, programmers don't speak in "endians", code that comes out of a compiler for a specific CPU model does. Endian-ness is more an emulation speed issue than a porting one unless you need to be touching code at a very low level with human hands.</STRONG>

No, this isn't correct. Whenever you deal with bytes directly you normally have to deal with endians. Like GIF is little endian even on PowerPC, I think. I know it's involved with file access and sockets.

[AirSluf]

No, this isn't correct. Whenever you deal with bytes directly you normally have to deal with endians. Like GIF is little endian even on PowerPC, I think. I know it's involved with file access and sockets.

Endian-ness or not, everything I do is 100% cross platform and I have not had to make any allowances in any of the work I do on the Mac to interface with PC or Linux(non-PPC) for endian-ness, including network and/or file streams which are definitely byte related. Your description would also break all ability to save a Word file on a Mac HFS+ disk and e-mail it as an attachment to a PC user who can then use it completely unmodified, or the reverse with Word or even MS-Dos Text. I do this constantly with non-Mac savvy folks so endian-ness usually isn't an issue for users or higher level programmers. By no means am I an expert at the endian issue, but it has not presented itself as an obstacle in any of the x-platform applications I have had a hand in developing.

The ability of identical PCI or AGP hardware to run in a Mac or PC also shows endian-ness is not a significant roadblock to anything. Yes, the dual-use hardware must have support built in for both ends but the economics of that decision are positive as the effort to incorporate both is much less than the end return in profit. The biggest obstacle to other peripheral manufactures is the physical market size. While two competing products can be profitable, the overall outlook for a third or fourth product in the same niche is MUCH gloomier. A marketing decision rather than a technical one.

[ink]

Originally posted by Angus_D:
<STRONG>
No, this isn't correct. Whenever you deal with bytes directly you normally have to deal with endians. Like GIF is little endian even on PowerPC, I think. I know it's involved with file access and sockets.</STRONG>

But who reads GIF files in the raw? Libraries do that (which is what I think AirSluf was talking about). The only place I've been bitten by endianness was with some network code (hence htonl and htons), but even a silly protocol like HTTP does that for you.

[Scott_H]

I deal with medical images and often have to byte swap. Most image files have a tag in the header that states endian-ness. It's a non issue because everyone is aware of it.

There's a kick ass unix command that you can use to swap bytes right on the command line

[Scribble]

Scott_H --

And that command would be??? I know several people, including myself, that would be very interested in knowing what it is.


I'd just write a stupid little C-program to swap, which does the trick also.


Scribble

[Scott_H]

Originally posted by Scribble:
<STRONG>Scott_H --

And that command would be??? I know several people, including myself, that would be very interested in knowing what it is.


I'd just write a stupid little C-program to swap, which does the trick also.


Scribble</STRONG>

You can use sed and ed to do it. I'd plunk out an example but I'm in OS 9 right now and can't test it.

[AG3]

PPC is bi-endian.......It has support for little endian as well as PPC native Big endian.

Why would you want anything to do with x86, its going to be obsolete when the itanium comes out in a years time. Itanium will come out as 800mhz, then well see some hi-cups.

[Scott_H]

Originally posted by AG3:
<STRONG>PPC is bi-endian.......It has support for little endian as well as PPC native Big endian.</STRONG>

Sure but once you make it part of a motherboard then it's set. As far as I know there's no dynamic way to change it. It wouldn't help anyway because programmers often step byte by byte through data. So there's no way to guess how they might expect the data. Unless you tell them in the file headder "big endian" and then they can swap or not swap and then use the data how they want to.

[Molz]

Originally posted by Scribble:
<STRONG>Scott_H --

And that command would be??? I know several people, including myself, that would be very interested in knowing what it is.


I'd just write a stupid little C-program to swap, which does the trick also.


Scribble</STRONG>

Here you go:

<BLOCKQUOTE><font size="1"face="Geneva, Verdana, Arial">code:</font><HR><pre><font size=1 face=courier>
$ dd <font color = green>if</font>=infile.foo of=outfile.foo.swaped conv=swab
</font>[/code]

Where infile.foo is the input file and outfile.foo.swaped is the the swaped byte version of the input file. Don't ask me why the conversion operation is called swab but it is.

[absmiths]

Using endianness as a roadblock to porting is like saying the Mac line terminator blocks porting (\r (Mac) \n (Unix) \r\n (Stupid DOS)). In any good software shop, reading endian bytes is handled in a macro so that the endianness of the whole application can be swapped with a flag. For things like GIF, those don't play into the equation at all because the processor does not execute GIF's, so the orientation of the pixels would have to be handled anyway. The single biggest barriers to porting are the hardware and API differences.

At any rate, that's why we use Macs, because they are different.