---

Som bekendt kører PPC-processorer med omvendt »endianness« end
Intel-processorer, idet G4-processorerne dog kan kan sættes til at følge
Intel-processorernes »endianness«. Det er derfor VirtualPC kører
hurtigere på en G4 end på en G5.

Er der nogen der ved hvordan Apple har løst endianness-problemet med
Rosetta? Nu skulle man jo kunne køre Mac-programmer på en
Intel-processor.

Søgning på www viser at nogle mener at kald til MacOS X APIs bare bliver
udført »native«.

<http://macslash.org/comments.pl?sid=5552&cid=97873>

Og hvad »endianness« er for noget:

<http://en.wikipedia.org/wiki/Endianness>

--
Per Erik Rønne
http://www.RQNNE.dk

---

per@RQNNE.invalid (Per Rønne) writes:

> Er der nogen der ved hvordan Apple har løst endianness-problemet med
> Rosetta?

Med funktionskaldende htonl, htons, ntohl og ntohs?

--
Thomas Bjorn Andersen
+++ATH

---

Thomas Bjorn Andersen <tbamacnewsNOSPAM200508@gen-v.net> wrote:

> per@RQNNE.invalid (Per Rønne) writes:
>
> > Er der nogen der ved hvordan Apple har løst endianness-problemet med
> > Rosetta?
>
> Med funktionskaldende htonl, htons, ntohl og ntohs?

Jeg må indrømme at akronymerne ikke siger mig noget.
--
Per Erik Rønne
http://www.RQNNE.dk

---

per@RQNNE.invalid (Per Rønne) writes:

> Thomas Bjorn Andersen <tbamacnewsNOSPAM200508@gen-v.net> wrote:
>
>> per@RQNNE.invalid (Per Rønne) writes:
>>
>> > Er der nogen der ved hvordan Apple har løst endianness-problemet med
>> > Rosetta?
>>
>> Med funktionskaldende htonl, htons, ntohl og ntohs?
>
> Jeg må indrømme at akronymerne ikke siger mig noget.

Det er bare at slå dem op på et unix system. Hvis du ikke er vant til
at arbejde med unix, så start en Terminal.app på din Mac og skriv "man
htonl".


--
Thomas Bjorn Andersen
+++ATH

---

Thomas Bjorn Andersen <tbamacnewsNOSPAM200508@gen-v.net> wrote:

> per@RQNNE.invalid (Per Rønne) writes:
>
> > Thomas Bjorn Andersen <tbamacnewsNOSPAM200508@gen-v.net> wrote:
> >
> >> per@RQNNE.invalid (Per Rønne) writes:
> >>
> >> > Er der nogen der ved hvordan Apple har løst endianness-problemet med
> >> > Rosetta?
> >>
> >> Med funktionskaldende htonl, htons, ntohl og ntohs?
> >
> > Jeg må indrømme at akronymerne ikke siger mig noget.
>
> Det er bare at slå dem op på et unix system. Hvis du ikke er vant til
> at arbejde med unix, så start en Terminal.app på din Mac og skriv "man
> htonl".

Du ved jo udmærket at jeg sidder ved en unix-maskine, og ikke er uvant
med at starte terminalen eller X11 op.

Men ok, cmd-F3, så er jeg inde i terminalen:

Last login: Sun Apr 9 13:21:31 on ttyp1
Welcome to Darwin!
G4 per$ man htonl > t
G4 per$ cat t
BYTEORDER(3) BSD Library Functions Manual
BYTEORDER(3)

NAME
htonl, htons, ntohl, ntohs -- convert values between host and
network
byte order

LIBRARY
Standard C Library (libc, -lc)

SYNOPSIS
#include <arpa/inet.h>

uint32_t
htonl(uint32_t hostlong);

uint16_t
htons(uint16_t hostshort);

uint32_t
ntohl(uint32_t netlong);

uint16_t
ntohs(uint16_t netshort);

DESCRIPTION
These routines convert 16 and 32 bit quantities between network
byte
order and host byte order. On machines which have a byte order
which is
the same as the network order, routines are defined as null macros.

These routines are most often used in conjunction with Internet
addresses
and ports as returned by gethostbyname(3) and getservent(3).

SEE ALSO
gethostbyname(3), getservent(3)

STANDARDS
The byteorder functions are expected to conform with IEEE Std
POSIX.1-200x (``POSIX.1'').

HISTORY
The byteorder functions appeared in 4.2BSD.

BUGS
On the VAX bytes are handled backwards from most everyone else in
the
world. This is not expected to be fixed in the near future.

BSD June 4, 1993
BSD
G4 per$
==

Og det siger jo ikke noget om at PPC-kode emuleret gennem Rosetta skulle
køre mere effektivt end Intel-kode emuleret genne VPC på en G5.
--
Per Erik Rønne
http://www.RQNNE.dk

---

Per Rønne <per@RQNNE.invalid> wrote:

> Som bekendt kører PPC-processorer med omvendt »endianness« end
> Intel-processorer, idet G4-processorerne dog kan kan sættes til at følge
> Intel-processorernes »endianness«. Det er derfor VirtualPC kører
> hurtigere på en G4 end på en G5.
>
> Er der nogen der ved hvordan Apple har løst endianness-problemet med
> Rosetta? Nu skulle man jo kunne køre Mac-programmer på en
> Intel-processor.
>
> Søgning på www viser at nogle mener at kald til MacOS X APIs bare bliver
> udført »native«.
>
> <http://macslash.org/comments.pl?sid=5552&cid=97873>
>
> Og hvad »endianness« er for noget:
>
> <http://en.wikipedia.org/wiki/Endianness>

mon ikke en af de ting Rosetta gør at læse fra den anden side af så er
problemet jo løst ?
--
Michael Holm - ichat: kiaikido [at] mac.com
http://toitsu.dk - http://alexanderteknik.tk
http://parraadgivning.dk - http://siaholm.dk -
skal du rejse? http://danfae.dk - michael[at] toitsu.dk

---

per@RQNNE.invalid (Per Rønne) writes:

> Thomas Bjorn Andersen <tbamacnewsNOSPAM200508@gen-v.net> wrote:
>
>> per@RQNNE.invalid (Per Rønne) writes:
>>
>> > Thomas Bjorn Andersen <tbamacnewsNOSPAM200508@gen-v.net> wrote:
>> >
>> >> per@RQNNE.invalid (Per Rønne) writes:
>> >>
>> >> > Er der nogen der ved hvordan Apple har løst endianness-problemet med
>> >> > Rosetta?
>> >>
>> >> Med funktionskaldende htonl, htons, ntohl og ntohs?
>> >
>> > Jeg må indrømme at akronymerne ikke siger mig noget.
>>
>> Det er bare at slå dem op på et unix system. Hvis du ikke er vant til
>> at arbejde med unix, så start en Terminal.app på din Mac og skriv "man
>> htonl".
>
> Du ved jo udmærket at jeg sidder ved en unix-maskine, og ikke er uvant
> med at starte terminalen eller X11 op.

Ja ja, godt ord igen. Somme tider kan det dog være lidt svært at
gennemskue, præcist hvor teknisk du er, Per.

> Og det siger jo ikke noget om at PPC-kode emuleret gennem Rosetta skulle
> køre mere effektivt end Intel-kode emuleret genne VPC på en G5.

Kunne det ikke tænkes, at just-in-time kompilering gør det muligt at
emulere RISC kode mere effektivt end hvis man skal emulere hele den
komplekse x86 arkitektur? I og med at MacOSX PPC kører big-endian, er
der jo heller noget bøvl med at gætte på om hukommelsen tilgåes med
forskellige word-størrelser, da MSB altid ligger først.

--
Thomas Bjorn Andersen
+++ATH

---

Thomas Bjorn Andersen <tbamacnewsNOSPAM200508@gen-v.net> wrote:

> per@RQNNE.invalid (Per Rønne) writes:

> > Du ved jo udmærket at jeg sidder ved en unix-maskine, og ikke er uvant
> > med at starte terminalen eller X11 op.

> Ja ja, godt ord igen. Somme tider kan det dog være lidt svært at
> gennemskue, præcist hvor teknisk du er, Per.

Jeg blev færdig for 15 år siden, og det er ikke alle nyudviklinger jeg
har fulgt med i.

> > Og det siger jo ikke noget om at PPC-kode emuleret gennem Rosetta skulle
> > køre mere effektivt end Intel-kode emuleret genne VPC på en G5.
>
> Kunne det ikke tænkes, at just-in-time kompilering gør det muligt at
> emulere RISC kode mere effektivt end hvis man skal emulere hele den
> komplekse x86 arkitektur? I og med at MacOSX PPC kører big-endian, er
> der jo heller noget bøvl med at gætte på om hukommelsen tilgåes med
> forskellige word-størrelser, da MSB altid ligger først.

Ja, da jeg havde maskinel på dat 1 var det Intel 8080 og Z80 der var de
små processorer. Så har jeg ganske vist for 10 år siden undervist i
maskinel på datamatikeruddannelsen, men da var det heller ikke
pentium-processorer der blev gennemgået. Jeg kender ganske simpelt ikke
den nyerer Intel-arkitektur.
--
Per Erik Rønne
http://www.RQNNE.dk