🚀 go-pugleaf

Frans Bouma wrote:
> 
> "Sjoerd Schreuder" <sa_schreuder@wanadoo.nl> wrote in message news:3C752437.D8E52A8B@wanadoo.nl...
> > robert wrote:
> > >
> > > Erik Warmelink <erik@flits102-126.flits.rug.nl>:
> > >  >Zowel de voorkeur voor 32 bit ints als het little endian formaat van
> > >  >constanten in code heeft wel wat Intel-achtigs.
> > >
> > > Je zit moeilijk te doen over keuzes die gemaakt zijn om tot een standaard
> > > te komen? Het lijken mij bijzonder logische keuzes...
> >
> > Mij lijkt dat 'logisch' een beetje overdreven. Er zijn andere keuzes
> > mogelijk, en die zijn net zo 'logisch'.
> >
> > * Aangezien 64 bits processoren al bestaan en binnen een paar jaar
> >   overal zullen zijn doorgedrongen, ligt een 64 bits integer type
> >   voor de hand.
> 
>     Een long is 64bit, waarom moet een int dan ook 64bit zijn?
>     Ik denk overigens dat het gros van de computers nog lange tijd
>     32bits zal zijn, intel is nl. niet van plan binnen afzienbare
>     tijd de 32bit lijn op te heffen, in tegendeel.

Is een long 64 bits? In C is de long meestal 32 bits, maar mag groter zijn.

> > * Intel is zo ongeveer de enige processor met little endian words.
> >   De eerste standaard op dat gebied was de "network byte order",
> >   en die is bigendian.
> 
>     Dat kan wel zijn, maar Intel heeft wel verreweg (qua volume) het
>     grootste aandeel op de processormarkt. Je kunt ook zeggen: waarom
>     nemen anderen geen little endian?
>     Er moet een keuze worden gemaakt. Als je kiest voor big-endian
>     voor een platform dat voor het leeuwendeel op intelprocs gaat
>     draaien, dan lijkt het me dat een rare zaak. Zeker gezien het
>     feit dat little endian procs de meerderheid vormen van het
>     aantal processoren op deze aardbol waar het platform op kan draaien.
>     Naast het feit natuurlijk dat little endian efficienter is
>     in virtual processoren.

Waarom zou je je eigenlijk vastleggen op little of big endian?
Dat is alleen van belang als je de individuele bytes van een word
kunt aanspreken. Dus in de volgende gevallen:
* Het casten van een pointer-to-word naar een pointer-to-byte.
* Het streamen van words naar externe bronnen zoals een file of
  het netwerk.

Het eerste geval wil je gewoon niet in je taal hebben zitten
(of maak je "implementation defined", zoals C en C++ doen).
In het tweede geval kun je zonder probleem een conversieslag doen
omdat je I/O toch al snelheidsbepalend is.

Dus mij lijkt het dat de beste oplossing is vrij te laten welke
vorm intern wordt gebruikt. Voor externe representatie moet je
dan wel een standaard kiezen, maar daar zijn al een heleboel
standaards voor: Unicode, TCP/IP, CORBA, ...

Andere standaards die al big-endian gebruiken:
- TCP/IP is big-endian.
- Unicode UTF-16 is big-endian.
(CORBA ken ik niet goed genoeg)
Is er eigenlijk al een standaard die little-endian voorschijft?

> > Gezien de keuzes die ze hebben gemaakt, lijkt de huidige Pentium
> > processor de voornaamste target van de standaard te zijn.
> 
>     Je moet EEN keuze maken.

Waarom zou je een keuze MOETEN maken? C en C++ doen dat ook niet,
en je kunt moeilijk zeggen dat die talen niet bestaan.

Wat mij betreft: laat lekker vrij die hap, zodat je efficiente
implementaties krijgt.

>               Kiezen voor 64bit integers levert een
>     probleem op, want hoe noem je dan 32bit integers? en hoe lang
>     moet dan een long zijn, 128 bit? En waarom zou je dan integerlengte
>     gelijkstellen aan long-lengte?

Waarom zou je die lengtes vastleggen? Minimale eisen voor range lijken
me nuttig, maar het nut van maximum grenzen ontgaat me.

Maar misschien ben ik te veel beinvloed door C en C++, waar dat allemaal
aan de compilerbouwer wordt overgelaten. Die kan een keuze maken die
voor dat platform natuurlijk is.

>                Plus kiezen voor big-endian
>     wanneer het leeuwendeel van het targetplatform op x86 gebaseerde
>     processors draait lijkt me niet zo nuttig. Je kunt dan beter
>     die extra conversieslagen bewaren voor het platform wat big-endian
>     procs gebruikt.

Conversieslagen moet je eenmalig bij I/O doen, dan kun je verder intern
in een efficient formaat werken. Het handigst is om met een vlaggetje
aan te geven in welke endian je het wegschrijft, en alleen bij het lezen
te converteren (indien nodig). In dat geval heb je zowel bij x86-x86
communicatie als bij SPARC-SPARC communicatie geen conversie nodig.

Sjoerd Schreuder