🚀 go-pugleaf

"Sjoerd Schreuder" <sa_schreuder@wanadoo.nl> wrote in message news:3C762FF1.B9125B5B@wanadoo.nl...
> Frans Bouma wrote:
> > "Sjoerd Schreuder" <sa_schreuder@wanadoo.nl> wrote in message news:3C752437.D8E52A8B@wanadoo.nl...
> > > 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.

    in .NET is een long 64bits vziw.

> > > * 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?

    hoe zou je het dan willen oplossen? :)

> 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, ...

    Nou, als er gekozen zou zijn binnen de CLR voor big endian, dan
    had elke operatie naar fysiek memory een conversie nodig gehad,
    wanneer je in mixed mode werkt, of wanneer code buiten de CLR
    aangeroepen worden. Lijkt me niet zo verstandig.

> 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?

    JPG?

    Maar ik denk dat hier van een mug een olifant gemaakt
    wordt. In een hogere ordetaal werkt men met typed data, en
    hoe individuele bytes zijn gerangschikt is veelal niet van belang:
    voor het optellen van een short bij een int is het niet van belang
    die volgorde te weten, alleen bij het lezen van data uit een file
    die is geschreven met een C programmaatje bv, dan moet je weten
    of de 4 bytes die een int voorstellen, ook in hetzelfde format
    staan als de endian-configuratie van het platform waar de inlezende
    partij op draait. Voorbeeld hiervan is het inlezen van TGA files
    op inteldozen :)

> > > 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.

    je moet toch je 4 byte dwords opslaan in een volgorde. Voor
    de C/C++ programmeur is dat steevast niet belangrijk, totdat
    er bv een blok data ingelezen wordt wat de inhoudt van een struct
    is, dus wat je bv direct naar een struct cast. Is die data
    weggeschreven op een big-endian bak, dan is het lastig werken
    op een intelbak. Ookal zit je in C/C++. Maar omdat dit niet
    alledaagse problemen zijn: nogmaals: hier wordt van een mug
    een olifant gemaakt, wat niet vreemd is bij rethoriek, afkomstig
    uit de Warmelink-hoek :)

> >               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.

    Die maximale grenzen ontleen je aan de brontaal, maar er is
    binnen de CLR geen 1 brontaal maar meerdere. Welke te kiezen?

> 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.

    valt uiteraard veel voor te zeggen. Maar als je zit te werken in taal A,
    zonder maximale waarden voor lengtes en 64bit wordt gekozen voor ints,
    hoe zijn dan de datablokken inwisselbaar met classes geschreven in taal
    B met maximale lengte voor ints van 32bits? Dat levert weer marshalling
    ellende op, iets wat men juist wil vermijdden. Ik vind het overigens
    best wel geneuzel: een long is 64bit, een int 32. Wil je 64bits gebruiken,
    gebruik je een long. gebruik je 32bits, gebruik je een int.

        FB