Re: bytegroesse, was endianess/Re: audio-cd

From: Oliver Fromme <olli(at)secnetix.de>
Date: Fri, 22 Mar 2002 17:36:53 +0100 (CET)

Michael Haertl <michael.haertl(at)gmx.net> wrote:
> Oliver Fromme wrote:
> > Michael Haertl wrote:
> > > Oliver Fromme wrote:
> > > > [...]
> > > > Hinzu kommt auch, daß es Plattformen gibt, wo es gar nicht
> > > > möglich ist, einzelne Bytes zu lesen, z.B. auf Alpha. Da
> > > > _kann_ der Prozessor nur ein ganzes Wort aus dem Speicher
> > > > lesen. Wenn ein Programm nur ein Byte braucht, muß es
> > > > durch Maskierungs- und/oder Verschiebeoperationen heraus-
> > > > gefiltert werden.
>
> Wenn das in Software passiert, dann klingt das nach uferlos
> Overhead.

Das ist bei RISC so üblich. Frühe RISC-Prozessoren konnten
nicht einmal multiplizieren und dividieren, sondern das
wurde alles »in Software« gemacht. Und trotzdem waren die
ziemlich fix.

> > > ["Verschwendung", d.h. z.B. sizeof(char) == sizeof(long)]
> > > Fuer den Standardfall (z.B. logische Variablen,
> > > "kleine" Schleifenzaehler) ist dann eigentlich kein Workaround
> > > notwendig.
> >
> > Verstehe ich nicht, wozu ein Workaround?
>
> Ja eben das Shiften/Maskieren beim extrahieren von Octetts aus
> einem "Word" meinte ich.

Das macht der Compiler. Und gute Compiler (damit meine ich
jetzt nicht gcc), können das auch ziemlich effizient opti-
mieren.

> > Der Punkt ist aber, daß Speicherzugriffe (auf's RAM) nur
> > Wortweise erfolgen können (32 und 64 Bit), nicht Byteweise.
>
> Das Businterface des Prozessors macht das ohnehin so (s.u.).

Ich meinte natürlich auf Maschinencode-Ebene.

> Wenn "LoadByte/StoreByte" im Befehlssatz des Prozessors nicht
> mehr vorhanden ist, dann macht es m.E. kaum Sinn z.B. 4 "chars"
> in ein Speicherwort zu packen.

Doch, durchaus, mit einem vernünftig optimierenden Compi-
ler.

> Oliver Fromme wrote:
> > Ferner muß jeder [externe] Zugriff auch »aligned« sein, sonst
> > gibt's einen Prozessor-Trap.
>
> Das gabs m.W. doch auch schon beim m68k (?).

Richtig. Fand ich damals am Anfang auch nervig beim Pro-
grammieren (in Assembler und C), aber irgendwann habe ich
dann eingesehen, daß es durchaus sinnvoll ist.

> > > Dass
> > > auf dem externen Buss nur noch Woerter (und meist nur noch in
> > > Bursts) transportiert werden ist ja aufgrund der Cache-
> > > Hierarchien und Zugriffszeiten kaum anders sinnvoll.
> >
> > Stimmt. Da sieht man mal wieder, wie unsinnig die i386-
> > Architektur von intel ist ...
>
> Den Zusammenhang verstehe ich nicht, das ist schliesslich fast
> ueberall aehnlich geloest, so eben auch beim Pentium-X.

Sorry, da war mein Gedankensprung etwas weit.

Was ich meinte, ist, daß die i386-Prozessoren diese Align-
ment-Problematik quasi vor dem Programmierer verstecken.
Der Programmierer kann das völlig ignorieren, und der Pro-
zessor »workaroundet« das Mißalignment völlig transparent,
aber auf Kosten der Effizienz. Programmierer werden damit
dazu verleitet, pfuschigen Code zu produzieren.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"All that we see or seem is just a dream within a dream" (E. A. Poe)
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Fri 22 Mar 2002 - 17:36:56 CET

search this site