C packed struct
Lutz Donnerhacke
man aus unbekanntem Grund, daß structs gepackt seien und das man diese dann
auch weiter verwenden könne.
Und so führt ein selbstdokumentierender Code:
[...]
typedef struct {
oid_t oid;
u_int16_t type;
} snap_hdr;
const snap_hdr cdp_snap = {{{0x00, 0x00, 0x0c}}, htons(0x2000)};
typedef struct {
u_int8_t version;
u_int8_t ttl;
u_int16_t checksum;
} cdp_hdr;
[...]
zu
01 00 0c cc cc cc 00 80 ad 1e 79 ba 00 00 aa aa
03 00 00 00 0c 00 20 00 02 b4 00 00
statt zu
01 00 0c cc cc cc 00 80 ad 1e 79 ba 00 00 aa aa
03 00 00 0c 20 00 02 b4 00 00
Auf Seite 518 in X3J11 steht dann unter J.3.9 auch tatsächlich:
: The alignment of non-bit-field members of structures (6.7.2.1). This
: should present no problem unless binary data written by one implementation
: is read by another.
Mir ist grade sehr offtopic zumute.
Ulrich Eckhardt
> Wenn man zuviel Ada Drogen nimmt, programmiert man unsinniges C. So erwartet
Ich versuche gerade mir diese Drogen in Form von GtkAda 2.0 auf Linux
und NT einzuwerfen. Für Linux wars (inclusive gcc 3.2 neucompileren)
nach 2 Tagen ok. Auf NT kämpfe ich schon seit einer Woche
erfolglos GtkAda ans laufen zu kriegen. Irgendwo fehlt entwerder
immer was oder hat gerade die falsche Version oder eigent sich nur
für den Microsoft-Compiler <ARGL>. Naja morgen mal schauen, ob
das GtkAda 1.3 exe irgendwas taugt.
> Und so führt ein selbstdokumentierender Code:
Grübel. Kanns sein, das der gepostete Code irgendwie nicht
identisch mit dem ist, das du uns eigentlich sagen wolltest?
> Mir ist grade sehr offtopic zumute.
AOL! Und deshalb macht meinereiner jetzt den Computer aus und
setzt sich in die Badewanne.
Uli
--
Ulrich Eckhardt
http://www.uli-eckhardt.de
Lutz Donnerhacke
>Lutz Donnerhacke wrote:
>> Wenn man zuviel Ada Drogen nimmt, programmiert man unsinniges C. So erwartet
>
>Ich versuche gerade mir diese Drogen in Form von GtkAda 2.0 auf Linux
>und NT einzuwerfen. Für Linux wars (inclusive gcc 3.2 neucompileren)
>nach 2 Tagen ok. Auf NT kämpfe ich schon seit einer Woche
GCC 3.2 ist buggy. Mehr als buggy. Zumindest der dysfunktionale Ada Teil.
>> Und so führt ein selbstdokumentierender Code:
>
>Grübel. Kanns sein, das der gepostete Code irgendwie nicht
>identisch mit dem ist, das du uns eigentlich sagen wolltest?
C ist ungeeignet zur hardwarenahen Programmierung gar nicht. Im Gegenteil:
Es ist unmöglich, durch Hardware vorgeschrieben Strukturen in wartbarer Form
überhaupt mit C anzufassen.
BTW: Das ist der Grund für die beliebten SIGBUS ...
struct xxx * px = (void *) irgendwas;
if(px->foo)
egal_weil_schon_vorher_sigbus;
Felix von Leitner
> GCC 3.2 ist buggy. Mehr als buggy. Zumindest der dysfunktionale Ada Teil.
Warum wirfst du nicht statt Ada ein paar bunte Ocaml-Speedpillen ein?
Dann hast du wenigstens einen coolen Compiler im Hintergrund.
> C ist ungeeignet zur hardwarenahen Programmierung gar nicht.
Parse Error.
Man programmiert ja auch heute nicht mehr hardwarenah.
Völlig veraltetes Paradigma. Und überhaupt, da fehlen ja die Design
Patterns und ohne Multithreading kann das ja eh gar nichts werden.
> BTW: Das ist der Grund für die beliebten SIGBUS ...
Das ist ja auch der Grund, wieso man auf x86 programmiert.
Kein SIGBUS.
Lutz Donnerhacke
>Thus spake Lutz Donnerhacke (lu...@iks-jena.de):
>> GCC 3.2 ist buggy. Mehr als buggy. Zumindest der dysfunktionale Ada Teil.
>
>Warum wirfst du nicht statt Ada ein paar bunte Ocaml-Speedpillen ein?
Das hilft?
>Dann hast du wenigstens einen coolen Compiler im Hintergrund.
GNAT ist auch cool. Nur eben zu sehr im Hintergrund. Für ein Frontend.
>> C ist ungeeignet zur hardwarenahen Programmierung gar nicht.
>
>Parse Error.
Ack.
>Man programmiert ja auch heute nicht mehr hardwarenah.
>Völlig veraltetes Paradigma. Und überhaupt, da fehlen ja die Design
>Patterns und ohne Multithreading kann das ja eh gar nichts werden.
Gut, dann mach Du das "modern". Ich bin halt haltmodisch.
>> BTW: Das ist der Grund für die beliebten SIGBUS ...
>
>Das ist ja auch der Grund, wieso man auf x86 programmiert.
>Kein SIGBUS.
Bitte? Der Prozessor macht automatisch einen Refetch auf gestückelten Werten?
movl eax, (register)
macht drei Buszugriffe? Ein 32bit -> krach und dann einen 8 und einen 24 bit
Zugriff? Ist der Prozessor völlig verrückt geworden?
Florian Weimer
> Auf Seite 518 in X3J11 steht dann unter J.3.9 auch tatsächlich:
> : The alignment of non-bit-field members of structures (6.7.2.1). This
> : should present no problem unless binary data written by one implementation
> : is read by another.
>
> Mir ist grade sehr offtopic zumute.
Das Problem hat übrigens auch Ada, und zwar recht massiv (einmal, was
die Norm angeht, ein andres Mal, was die Praxis betrifft).
Florian Weimer
> C ist ungeeignet zur hardwarenahen Programmierung gar nicht. Im Gegenteil:
> Es ist unmöglich, durch Hardware vorgeschrieben Strukturen in wartbarer Form
> überhaupt mit C anzufassen.
Es gibt in GNU C ein paar Erweiterungen.
> BTW: Das ist der Grund für die beliebten SIGBUS ...
> struct xxx * px = (void *) irgendwas;
> if(px->foo)
> egal_weil_schon_vorher_sigbus;
Wenn "irgendwas" mal ein "struct xxx *" war, sehe ich nicht, wo da das
Problem sein soll.
Lutz Donnerhacke
Natürlich, aber mit Ada kann ich mir wenigstens selbst die Säge an Bein
ansetzen. In C bin ich von der Willkür der Compilerlaune abhängig. *schluck*
Lutz Donnerhacke
>lu...@iks-jena.de (Lutz Donnerhacke) writes:
>> C ist ungeeignet zur hardwarenahen Programmierung gar nicht. Im Gegenteil:
>> Es ist unmöglich, durch Hardware vorgeschrieben Strukturen in wartbarer Form
>> überhaupt mit C anzufassen.
>
>Es gibt in GNU C ein paar Erweiterungen.
Und Watcom hat noch andere. Von Microsoft ganz zu schweigen. In GCC schreibt
man __attribute__(packed) nach die Strukturdefinition. Erst dann darf man
die so definierte Struktur verwenden (z.B. für typedef), muß aber immer
wieder __attribute__(packed) erwähnen. Das sind Mantramethoden. Da kann man
auch gleich Hühner opfern, das ist deterministischer.
>> BTW: Das ist der Grund für die beliebten SIGBUS ...
>> struct xxx * px = (void *) irgendwas;
>> if(px->foo)
>> egal_weil_schon_vorher_sigbus;
>
>Wenn "irgendwas" mal ein "struct xxx *" war, sehe ich nicht, wo da das
>Problem sein soll.
Es war ein memcpy dazwischen.
Felix von Leitner
> >> GCC 3.2 ist buggy. Mehr als buggy. Zumindest der dysfunktionale Ada Teil.
> >Warum wirfst du nicht statt Ada ein paar bunte Ocaml-Speedpillen ein?
> Das hilft?
Naja, in dem Sinne wie ein Schlag auf den Kopf einen kurzzeitig die
Magenschmerzen vergessen läßt.
Langfristig könnte ich glaube ich mit Ocaml nicht arbeiten, aber es
hilft einem dabei, die Schmerzen mit C/Ada zu vergessen.
> >Dann hast du wenigstens einen coolen Compiler im Hintergrund.
> GNAT ist auch cool. Nur eben zu sehr im Hintergrund. Für ein Frontend.
Was genau ist an GNAT deiner Ansicht nach "cool"?
Das nicht abschätzig gemeint, ich bin nur neugierig.
> >Man programmiert ja auch heute nicht mehr hardwarenah.
> >Völlig veraltetes Paradigma. Und überhaupt, da fehlen ja die Design
> >Patterns und ohne Multithreading kann das ja eh gar nichts werden.
> Gut, dann mach Du das "modern". Ich bin halt haltmodisch.
Das ist inzwischen auch schon wieder gut abgehangen. Modern ist J2EE
mit EJB, on-the-fly XSLT-Nutzung und SOAP.
> >> BTW: Das ist der Grund für die beliebten SIGBUS ...
> >Das ist ja auch der Grund, wieso man auf x86 programmiert.
> >Kein SIGBUS.
> Bitte? Der Prozessor macht automatisch einen Refetch auf gestückelten Werten?
> movl eax, (register)
> macht drei Buszugriffe? Ein 32bit -> krach und dann einen 8 und einen 24 bit
> Zugriff? Ist der Prozessor völlig verrückt geworden?
An sich ist da noch ein Cache dazwischen, und soweit ich weiß zieht der
Prozessor dann zwei 32-bit Werte und extrahiert die gewollten. Beim
Schreiben ist das natürlich etwas aufwendiger.
Felix
Felix von Leitner
> ansetzen. In C bin ich von der Willkür der Compilerlaune abhängig. *schluck*
Freu dich doch, daß moderne Technologie etwas Aufregung in dein
monotones Leben bringt! Deterministisch kann schließlich jeder.
Florian Weimer
> Das ist ja auch der Grund, wieso man auf x86 programmiert.
> Kein SIGBUS.
Nicht notwendigerweise. Es ist konfigurierbar.
Florian Weimer
> Natürlich, aber mit Ada kann ich mir wenigstens selbst die Säge an
> Bein ansetzen. In C bin ich von der Willkür der Compilerlaune
> abhängig. *schluck*
Soll ich Dir die einschlägige AI herauskramen? TC 1 behebt es auch
nicht.
Außerdem ist Cross-Vendor- und Cross-Version-Kompatibilität bei Ada
nachweislich schlechter als bei C. Für die meisten Architekturen gibt
es einfach keine ABI-Spezifikation.
Kaum ein C-Compiler-Hersteller wird es sich leisten, mal eben von
Minor Release zu Minor Release die ABI zu ändern.
Ronald Wahl
> * Florian Weimer wrote:
>> lu...@iks-jena.de (Lutz Donnerhacke) writes:
>>> C ist ungeeignet zur hardwarenahen Programmierung gar nicht. Im Gegenteil:
>>> Es ist unmöglich, durch Hardware vorgeschrieben Strukturen in
>>> wartbarer Form überhaupt mit C anzufassen.
>>
>> Es gibt in GNU C ein paar Erweiterungen.
> Und Watcom hat noch andere. Von Microsoft ganz zu schweigen. In GCC schreibt
> man __attribute__(packed) nach die Strukturdefinition. Erst dann darf man
> die so definierte Struktur verwenden (z.B. für typedef), muß aber immer
> wieder __attribute__(packed) erwähnen. Das sind Mantramethoden. Da kann man
> auch gleich Hühner opfern, das ist deterministischer.
Sicher?
#pragma pack(1) /* byte alignment */
typedef struct {
...
} bla_t;
#pragma pack() /* restore default alignment */
... und dann bla_t einfach benutzen ohne nochmal irgendwo was am
alignment zu drehen. Zumindest funktionierte das bisher bei mir.
AFAIK, kann man auch hinter jedes Struktur_element_
__attribute__(packed) schreiben, obiges ist aber kuerzer.
- ron
Florian Weimer
> * Florian Weimer wrote:
>>lu...@iks-jena.de (Lutz Donnerhacke) writes:
>>> C ist ungeeignet zur hardwarenahen Programmierung gar nicht. Im Gegenteil:
>>> Es ist unmöglich, durch Hardware vorgeschrieben Strukturen in wartbarer Form
>>> überhaupt mit C anzufassen.
>>
>>Es gibt in GNU C ein paar Erweiterungen.
>
> Und Watcom hat noch andere.
Und wo ist der Unterschied zu Ada? Die Chancen, daß Du einen Satz
Representation Clauses durch einen anderen Compiler als GNAT bekommst,
sind niedriger, als Du denkst, fürchte ich.
>>Wenn "irgendwas" mal ein "struct xxx *" war, sehe ich nicht, wo da das
>>Problem sein soll.
>
> Es war ein memcpy dazwischen.
Das macht nichts, solange es mal ein "struct xxx *" war.
Florian Weimer
>>Warum wirfst du nicht statt Ada ein paar bunte Ocaml-Speedpillen ein?
>
> Das hilft?
Wenn man die QPL mag, vielleicht.
Thiemo Seufer
[snip]
> >>Wenn "irgendwas" mal ein "struct xxx *" war, sehe ich nicht, wo da das
> >>Problem sein soll.
> >
> > Es war ein memcpy dazwischen.
>
> Das macht nichts, solange es mal ein "struct xxx *" war.
Und falls das Ziel des memcpy passend aligned war.
Thiemo
Juergen P. Meier
> * Felix von Leitner wrote:
>
>>Man programmiert ja auch heute nicht mehr hardwarenah.
>>Völlig veraltetes Paradigma. Und überhaupt, da fehlen ja die Design
>>Patterns und ohne Multithreading kann das ja eh gar nichts werden.
>
> Gut, dann mach Du das "modern". Ich bin halt haltmodisch.
"moderat modern".
>>> BTW: Das ist der Grund für die beliebten SIGBUS ...
>>
>>Das ist ja auch der Grund, wieso man auf x86 programmiert.
>>Kein SIGBUS.
>
> Bitte? Der Prozessor macht automatisch einen Refetch auf gestückelten Werten?
> movl eax, (register)
> macht drei Buszugriffe? Ein 32bit -> krach und dann einen 8 und einen 24 bit
> Zugriff? Ist der Prozessor völlig verrückt geworden?
Nein, er kommt von Intel. Da muss die Hardwaere die Fehler der
Software ausbuegeln. Ist nicht umsonst die Primaere Plattform fuer
Wintendo.
Aber das ist hier sowas von OffTopic,
Juergen
--
_ _
/.._ _ _ /_) /|/| . _ | "This World is about
\_/(// (/(`// / . / |(`/(`/ | to be Destroyed."
=======_/======================== | Juergen P. Meier
Lutz Donnerhacke
>> >> GCC 3.2 ist buggy. Mehr als buggy. Zumindest der dysfunktionale Ada Teil.
>> >Warum wirfst du nicht statt Ada ein paar bunte Ocaml-Speedpillen ein?
>> Das hilft?
>
>Naja, in dem Sinne wie ein Schlag auf den Kopf einen kurzzeitig die
>Magenschmerzen vergessen läßt.
Das Argument hat was: Schau, das ist noch schlimmer.
>> >Dann hast du wenigstens einen coolen Compiler im Hintergrund.
>> GNAT ist auch cool. Nur eben zu sehr im Hintergrund. Für ein Frontend.
>
>Was genau ist an GNAT deiner Ansicht nach "cool"?
>Das nicht abschätzig gemeint, ich bin nur neugierig.
Ich benutze häufig die Funktionen: Stylecheck, Show Type Representation und
die begründeten Fehlermeldungen (mit Quellennachweis warm das ein Fehler ist).
>> >Man programmiert ja auch heute nicht mehr hardwarenah.
>> >Völlig veraltetes Paradigma. Und überhaupt, da fehlen ja die Design
>> >Patterns und ohne Multithreading kann das ja eh gar nichts werden.
>> Gut, dann mach Du das "modern". Ich bin halt haltmodisch.
>
>Das ist inzwischen auch schon wieder gut abgehangen. Modern ist J2EE
>mit EJB, on-the-fly XSLT-Nutzung und SOAP.
Dann bin ich anachronistisch, weil ich bis auf XSLT keinen der Begriffe kenne.
Und XSLT habe ich auch von Rigo eingeprügelt bekommen.
>> Bitte? Der Prozessor macht automatisch einen Refetch auf gestückelten
>> Werten? movl eax, (register) macht drei Buszugriffe? Ein 32bit -> krach
>> und dann einen 8 und einen 24 bit Zugriff? Ist der Prozessor völlig
>> verrückt geworden?
>
>An sich ist da noch ein Cache dazwischen, und soweit ich weiß zieht der
>Prozessor dann zwei 32-bit Werte und extrahiert die gewollten. Beim
>Schreiben ist das natürlich etwas aufwendiger.
Du weißt aber, was Hardware damit macht, ja?
Holger Veit
Nein, von der entsprechenden Compiler-Dokumentation. Leider muss man die
lesen. #pragma pack(1) ist ueblich. Compiler, die das nicht haben (oder ein
vergleichbares Konstrukt[1]), sind Schrott und unbrauchbar fuer hardwarenahe
Programmierung.
Holger
[1] Alternativ koennte man auch den entsprechenden Teil in FORTRAN schreiben
und dann EQUIVALENCE nehmen.
--
Please update your tables to my new e-mail address:
holger.veit$ais.fhg.de (replace the '$' with '@' -- spam-protection)
Lutz Donnerhacke
>lu...@iks-jena.de (Lutz Donnerhacke) writes:
>> Natürlich, aber mit Ada kann ich mir wenigstens selbst die Säge an
>> Bein ansetzen. In C bin ich von der Willkür der Compilerlaune
>> abhängig. *schluck*
>
>Soll ich Dir die einschlägige AI herauskramen? TC 1 behebt es auch nicht.
Danke, das kann ich selbst.
>Außerdem ist Cross-Vendor- und Cross-Version-Kompatibilität bei Ada
>nachweislich schlechter als bei C. Für die meisten Architekturen gibt
>es einfach keine ABI-Spezifikation.
*Hmm* Nenn mich altmodisch, aber ich spezifiziere für den Datenaustausch
von den ABI unabhängige Formate. Kleine Programme, die vollständig in einem
Compiler durchgezogen werden.
>Kaum ein C-Compiler-Hersteller wird es sich leisten, mal eben von
>Minor Release zu Minor Release die ABI zu ändern.
Wäre das wirklich so ein Problem? Nunja, vielleicht wegen der module/lib/DLLs.
Holger Veit
> * Florian Weimer wrote:
>>lu...@iks-jena.de (Lutz Donnerhacke) writes:
>>> C ist ungeeignet zur hardwarenahen Programmierung gar nicht. Im Gegenteil:
>>> Es ist unmöglich, durch Hardware vorgeschrieben Strukturen in wartbarer Form
>>> überhaupt mit C anzufassen.
>>
>>Es gibt in GNU C ein paar Erweiterungen.
>
> Und Watcom hat noch andere. Von Microsoft ganz zu schweigen. In GCC schreibt
> man __attribute__(packed) nach die Strukturdefinition. Erst dann darf man
Die gcc-Konvention ist FDA.
> die so definierte Struktur verwenden (z.B. für typedef), muß aber immer
> wieder __attribute__(packed) erwähnen. Das sind Mantramethoden. Da kann man
> auch gleich Hühner opfern, das ist deterministischer.
Sowas kapselt man in geeigneten Headerfiles. Siehe <os2.h> und alles, was
drunterhaengt (das will man nicht wissen, was da an diversen Calling Conventions
und Struct Alignments rumfliegt, aber es laeuft).
Holger
Lutz Donnerhacke
>On Mon, 14 Oct 2002 20:39:09 +0000 (UTC), Lutz Donnerhacke wrote:
>> * Florian Weimer wrote:
>>> Es gibt in GNU C ein paar Erweiterungen.
>
>> Und Watcom hat noch andere. Von Microsoft ganz zu schweigen. In GCC schreibt
>
Ja.
>#pragma pack(1) /* byte alignment */
Pack setzt Alignement? Das ist Terminologiemißbrauch.
X3J11 enthält den Suchstring "pack" in genau zwei Absätzen:
:10 An implementation may allocate any addressable storage unit large enough
: to hold a bit-field. If enough space remains, a bit-field that
: immediately follows another bit-field in a structure shall be packed into
: adjacent bits of the same unit. If insufficient space remains, whether a
: bit-field that does not fit is put into the next unit or overlaps
: adjacent units is implementation-defined. The order of allocation of
: bit-fields within a unit (high-order to low-order or low-order to
: high-order) is implementation-defined. The alignment of the addressable
: storage unit is unspecified.
:
:11 A bit-field declaration with no declarator, but only a colon and a width,
: indicates an unnamed bit-field.105) As a special case, a bit-field
: structure member with a width of 0 indicates that no further bit-field is
: to be packed into the unit in which the previous bit-...
Und da muß ich sagen, daß mich diese Absätze auch nicht besser stimmen,
besonders, weil es die einzigen Absätze sind, in denen etwas zur Auffüllung
einer Struktur gesagt wird. Fußnote 262 zeigt, wie schlimm die Norm
wirklich ist:
:262) The contents of `holes'' used as padding for purposes of alignment
: within structure objects are indeterminate. Strings shorter than their
: allocated space and unions may also cause problems in comparison.
=> Keine Strukturen verwenden.
>alignment zu drehen. Zumindest funktionierte das bisher bei mir.
:6.10.6 Pragma directive
:
:Semantics
:
: A preprocessing directive of the form
: # pragma pp-tokensopt new-line
: where the preprocessing token STDC does not immediately follow pragma in
: the directive (prior to any macro replacement)146) causes the
: implementation to behave in an implementation-defined manner. The behavior
: might cause translation to fail or cause the translator or the resulting
: program to behave in a non-conforming manner. Any such pragma that is not
: recognized by the implementation is ignored.
:
: 146) An implementation is not required to perform macro replacement in
: pragmas, but it is permitted except for in standard pragmas (where
: STDC immediately follows pragma). If the result of macro replacement
: in a non-standard pragma has the same form as a standard pragma, the
: behavior is still implementation-defined; an implementation is
: permitted to behave as if it were the standard pragma, but is not
: required to.
Ich wünsche mir einen Bastard Compiler from Hell, der immer, wenn die
Sprachnorm "undefined", "implementation-defined behaivior" oder "erronous
behaivior" gestattet, Code einfügt, der ein zufälliges File von der Platte
löscht.
>AFAIK, kann man auch hinter jedes Struktur_element_
>__attribute__(packed) schreiben, obiges ist aber kuerzer.
6.4.2.2 definiert den vordefinierten Bezeichner __func__
6.10.8 definiert die vordefinierten Makros __DATE__, __FILE__, __LINE__,
__STDC__, __STDC_HOSTED__, __STDC_VERSION__, __TIME__,
__STDC_IEC_559__, __STDC_IEC_559_COMPLEX__ und __STDC_ISO_10646__.
Außerdem heißt es dort in Absatz 4, daß kein weiterer vordefinierter
Bezeichner mit zwei Unterstrichen oder mit Unterstrich und
Großbuchstabe beginnen soll. In Absatz 5 wird die Definition von
__cplusplus untersagt.
Was soll also __attribute__ sein? Eine Normverletzung.
Lutz Donnerhacke
>lu...@iks-jena.de (Lutz Donnerhacke) writes:
>> * Florian Weimer wrote:
>>>lu...@iks-jena.de (Lutz Donnerhacke) writes:
>>>> C ist ungeeignet zur hardwarenahen Programmierung gar nicht. Im
>>>> Gegenteil: Es ist unmöglich, durch Hardware vorgeschrieben
>>>> Strukturen in wartbarer Form überhaupt mit C anzufassen.
>>>
>>>Es gibt in GNU C ein paar Erweiterungen.
>>
>> Und Watcom hat noch andere.
>
>Und wo ist der Unterschied zu Ada?
Das Reference Manual schreibt vor, was ein Ada Compiler verstehen und wie er
es umsetzen muß. Representation Clauses gehören dazu. Pragma Pack
insbesondere.
>Die Chancen, daß Du einen Satz Representation Clauses durch einen anderen
>Compiler als GNAT bekommst, sind niedriger, als Du denkst, fürchte ich.
Das mag sein, wenn man sich auf die Erweiterungen verläßt. Muß man aber nicht.
>>>Wenn "irgendwas" mal ein "struct xxx *" war, sehe ich nicht, wo da das
>>>Problem sein soll.
>>
>> Es war ein memcpy dazwischen.
>
>Das macht nichts, solange es mal ein "struct xxx *" war.
man Alignment.
Lutz Donnerhacke
>Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>> Und Watcom hat noch andere. Von Microsoft ganz zu schweigen. In GCC schreibt
>> man __attribute__(packed) nach die Strukturdefinition. Erst dann darf man
>
>Die gcc-Konvention ist FDA.
Federal Drug Administration? (korrekt: U.S. Food and Drug Administration)
Yep: Die Suchmaschine auf www.fda.gov findet auf das Stichwort GCC hin viel.
>> die so definierte Struktur verwenden (z.B. für typedef), muß aber immer
>> wieder __attribute__(packed) erwähnen. Das sind Mantramethoden. Da kann man
>> auch gleich Hühner opfern, das ist deterministischer.
>
>Sowas kapselt man in geeigneten Headerfiles.
Und die baut man mit autoconf? Weil das so üblich ist? He! Ich wollte
Vorschläge, wie sich meine Stimmung heben könnte, nicht wie man meine
Nervenbahnen in den Kollaps treibt.
>Siehe <os2.h> und alles, was drunterhaengt (das will man nicht wissen, was
>da an diversen Calling Conventions und Struct Alignments rumfliegt, aber
>es laeuft).
Man will das wissen. Wie sonst soll ich den Kram ansprechen, ohne jedesmal
einen C-Wrapper für jeden Hutzebutz in dessen 38 Ausführungen zu schreiben?
Ulrich Eckhardt
> * Florian Weimer wrote:
>>nachweislich schlechter als bei C. Für die meisten Architekturen gibt
>>es einfach keine ABI-Spezifikation.
> *Hmm* Nenn mich altmodisch, aber ich spezifiziere für den Datenaustausch
> von den ABI unabhängige Formate. Kleine Programme, die vollständig in einem
> Compiler durchgezogen werden.
Ist aber nicht auf jeder Plattform ordentlich durchzuführen.
>>Kaum ein C-Compiler-Hersteller wird es sich leisten, mal eben von
>>Minor Release zu Minor Release die ABI zu ändern.
>
> Wäre das wirklich so ein Problem? Nunja, vielleicht wegen der module/lib/DLLs.
Ich will derzeit mal mein WHFC (siehe meine Webseite) komplett
überarbeiten und da eine Möglichkeit schaffen z.B. das Telefonbuch
via "Plug-Ins" zu erweitern. Eine Art des Telefonbuchs soll via
ODBC auf eine Datenbank zugreifen können. Da Ada aber nichts vergleich-
bares (zumindest habe ich bisher noch nichts gefunden) hat muß ich
da eine Möglich schaffen via C zu programmieren.
Ulrich Eckhardt
> * Ulrich Eckhardt wrote:
>>Ich versuche gerade mir diese Drogen in Form von GtkAda 2.0 auf Linux
>>und NT einzuwerfen. Für Linux wars (inclusive gcc 3.2 neucompileren)
>>nach 2 Tagen ok. Auf NT kämpfe ich schon seit einer Woche
>
> GCC 3.2 ist buggy. Mehr als buggy. Zumindest der dysfunktionale Ada Teil.
Dann compilier ich den 2.95 noch mal mit Ada support.
Mein Rechner wird ohnehin schon unruhig, wenn ich nicht jeden Tag
wenigstens ein mal einen gcc durchcompiliert habe.
Ulrich Eckhardt
>
> Außerdem ist Cross-Vendor- und Cross-Version-Kompatibilität bei Ada
> nachweislich schlechter als bei C. Für die meisten Architekturen gibt
> es einfach keine ABI-Spezifikation.
Mwaa. Sag doch sowas nicht. Ich bin gerade dabei Ada wegen
Plattformübergreifend (für Werte von Linux+Windows) zu lernen.
Holger Veit
> * Holger Veit wrote:
>>Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>>> Und Watcom hat noch andere. Von Microsoft ganz zu schweigen. In GCC schreibt
>>> man __attribute__(packed) nach die Strukturdefinition. Erst dann darf man
>>
>>Die gcc-Konvention ist FDA.
Fuer den A....
> Federal Drug Administration? (korrekt: U.S. Food and Drug Administration)
> Yep: Die Suchmaschine auf www.fda.gov findet auf das Stichwort GCC hin viel.
>
>>> die so definierte Struktur verwenden (z.B. für typedef), muß aber immer
>>> wieder __attribute__(packed) erwähnen. Das sind Mantramethoden. Da kann man
>>> auch gleich Hühner opfern, das ist deterministischer.
>>
>>Sowas kapselt man in geeigneten Headerfiles.
>
> Und die baut man mit autoconf? Weil das so üblich ist? He! Ich wollte
> Vorschläge, wie sich meine Stimmung heben könnte, nicht wie man meine
> Nervenbahnen in den Kollaps treibt.
Autoconf ist auch FDA, es autokonfiguriert nicht, wenn sich der Programmierer
dann nicht um das erzeugte CONFIG.H schert - was unter Linux mittlerweile
uebliche Praxis ist. Damit laeuft das Gewurschtel dann natuerlich nur
unter Linux, mit etwas Talent sogar nur unter Linux Kernel-X.Y.Z mit
glibc-A.B.C [0]. BTDT.
>>Siehe <os2.h> und alles, was drunterhaengt (das will man nicht wissen, was
>>da an diversen Calling Conventions und Struct Alignments rumfliegt, aber
>>es laeuft).
>
> Man will das wissen. Wie sonst soll ich den Kram ansprechen, ohne jedesmal
> einen C-Wrapper für jeden Hutzebutz in dessen 38 Ausführungen zu schreiben?
Die Definitionen in den Header-Files (hier: <os2.h>) nehmen einem genau
das fuer die ueblichen Compiler auf dem System ab. Naeheres regelt dann
DOSCALL1.DLL, welche der verlaengerte Arm des Kernels ist. Man will
nicht jeden System-Hutzebutz selber frickeln. Und fuer eigene APIs
nimmt man dann das (dort auch deklarierte) Symbol APIENTRY, und
stoert sich nicht daran, was das ist[1].
Holger
[0] Und Linux-Frickler sind besonders talentiert diesbezueglich :-(
[1] _System, d.h. C-Calling-Convention fuer 32 bit Entries
_far _pascal, d.h. 16:16 Pascal-Convention fuer 16 bit Entries[2]
[2] Alles andere "unkonventionelle", vom Programmierer selbst zusammen-
geschraubte, ist DRECK.
Adrian Knoth
> ODBC auf eine Datenbank zugreifen können. Da Ada aber nichts vergleich-
> bares (zumindest habe ich bisher noch nichts gefunden)
Was suchst du? Datenbanksupport?
--
mail: a...@thur.de http://adi.thur.de PGP: v2-key via keyserver
Wo ein guter Gag ist, kann auch die Gage nicht weit sein.
Ulrich Eckhardt
> Ulrich Eckhardt <ul...@gmx.de> wrote:
>
>>ODBC auf eine Datenbank zugreifen können. Da Ada aber nichts vergleich-
>>bares (zumindest habe ich bisher noch nichts gefunden)
>
> Was suchst du? Datenbanksupport?
Ja, allerdings möglichst Datenbankunabhängig. Vergleichbar
mit ODBC/JDBC eben.
Felix von Leitner
> > Das ist ja auch der Grund, wieso man auf x86 programmiert.
> > Kein SIGBUS.
> Nicht notwendigerweise. Es ist konfigurierbar.
Man lernt doch nie aus.
Felix von Leitner
> >mit EJB, on-the-fly XSLT-Nutzung und SOAP.
> Dann bin ich anachronistisch, weil ich bis auf XSLT keinen der Begriffe kenne.
> Und XSLT habe ich auch von Rigo eingeprügelt bekommen.
Geh mal mit deinem Schutzengel einen saufen, er arbeitet ausgesprochen
effizient. Wenn er einen kleinen Bruder hat, habe ich einen Job für
ihn.
> >An sich ist da noch ein Cache dazwischen, und soweit ich weiß zieht der
> >Prozessor dann zwei 32-bit Werte und extrahiert die gewollten. Beim
> >Schreiben ist das natürlich etwas aufwendiger.
> Du weißt aber, was Hardware damit macht, ja?
Ich lebte unter der Vorstellung, ich spräche von der Hardware.
Felix
Lutz Donnerhacke
>Florian Weimer wrote:
>> Außerdem ist Cross-Vendor- und Cross-Version-Kompatibilität bei Ada
>> nachweislich schlechter als bei C. Für die meisten Architekturen gibt
>> es einfach keine ABI-Spezifikation.
>
>Mwaa. Sag doch sowas nicht. Ich bin gerade dabei Ada wegen
>Plattformübergreifend (für Werte von Linux+Windows) zu lernen.
Wenn Du nicht erwartest, daß Du ix86 Code auf 68k laufen lassen kannst, hast
Du schon gewonnen. Nutze selbstgeschriebene 'Input 'Output Routinen und sei
froh.
Lutz Donnerhacke
[...]
>uebliche Praxis ist. Damit laeuft das Gewurschtel dann natuerlich nur
>unter Linux, mit etwas Talent sogar nur unter Linux Kernel-X.Y.Z mit
>glibc-A.B.C [0]. BTDT.
Du warst das?
>>>Siehe <os2.h> und alles, was drunterhaengt (das will man nicht wissen, was
>>>da an diversen Calling Conventions und Struct Alignments rumfliegt, aber
>>>es laeuft).
>>
>> Man will das wissen. Wie sonst soll ich den Kram ansprechen, ohne jedesmal
>> einen C-Wrapper für jeden Hutzebutz in dessen 38 Ausführungen zu schreiben?
>
>Die Definitionen in den Header-Files (hier: <os2.h>) nehmen einem genau
>das fuer die ueblichen Compiler auf dem System ab.
Und die bekomme ich dann ohne C-Wrapper nach Ada/Perl/Ocaml?
>Naeheres regelt dann DOSCALL1.DLL, welche der verlaengerte Arm des Kernels
>ist. Man will nicht jeden System-Hutzebutz selber frickeln. Und fuer
>eigene APIs nimmt man dann das (dort auch deklarierte) Symbol APIENTRY,
>und stoert sich nicht daran, was das ist[1].
Und die spreche ich dann ohne C-Wrapper nach Ada/Perl/Ocaml an?
Lutz Donnerhacke
>
> effizient. Wenn er einen kleinen Bruder hat, habe ich einen Job für ihn.
Ob er Berlin mag?
>>> An sich ist da noch ein Cache dazwischen, und soweit ich weiß zieht
>>> der Prozessor dann zwei 32-bit Werte und extrahiert die gewollten.
>>> Beim Schreiben ist das natürlich etwas aufwendiger.
>> Du weißt aber, was Hardware damit macht, ja?
>Ich lebte unter der Vorstellung, ich spräche von der Hardware.
Dann kennst Du sicher auch Hardware, die beim Lesen eines memory mapped
Registers dieses löscht.
Adrian Knoth
>>>ODBC auf eine Datenbank zugreifen können. Da Ada aber nichts vergleich-
>>>bares (zumindest habe ich bisher noch nichts gefunden)
>> Was suchst du? Datenbanksupport?
> Ja, allerdings möglichst Datenbankunabhängig. Vergleichbar
> mit ODBC/JDBC eben.
Dann nimm ODBC. Bindings gibt es genügend. Spontan fällt mir da
gnade.sourceforge.net ein. (GNU Ada Database Environment).
--
mail: a...@thur.de http://adi.thur.de PGP: v2-key via keyserver
Nicht alles was hinkt, ist ein Vergleich.
Andreas Krey
>Wenn man zuviel Ada Drogen nimmt, programmiert man unsinniges C. So erwartet
>man aus unbekanntem Grund, daß structs gepackt seien und das man diese dann
>auch weiter verwenden könne.
>
Hihi. Ich hatte gerade den Zweitkontakt mit C++ nach einer Zeit Java.
Button b = new Button (parent);
übersetzt zwar dank massiv überladener Operatoren,
ist aber doch nicht ganz dasselbe wie
Button *b = new Button (parent);
Andreas
Ulrich Eckhardt
>>mit ODBC/JDBC eben.
> Dann nimm ODBC. Bindings gibt es genügend. Spontan fällt mir da
> gnade.sourceforge.net ein. (GNU Ada Database Environment).
Ahh. Wenigstens etwas erfreuliches hat der Tag heute :-).
Uli (gerade verzweifelnd MinGW durchs Modem quetschend)
Juergen P. Meier
> Ich wünsche mir einen Bastard Compiler from Hell, der immer, wenn die
> Sprachnorm "undefined", "implementation-defined behaivior" oder "erronous
> behaivior" gestattet, Code einfügt, der ein zufälliges File von der Platte
> löscht.
GCC?
und wech,
Juergen
Uwe Ohse
>Dann kennst Du sicher auch Hardware, die beim Lesen eines memory mapped
>Registers dieses löscht.
Ach was. Hardware mit internem Zustandsflag für spezielle Bereiche. Wird
gelöscht beim Lesen, gesetzt nur wenn neue Daten verfügbar sind. Lesen
ohne gesetztes Flag -> SEGV.
Transfer area 0..7, transfer area ready flag 0..7, IIRC.
Gruß, Uwe
Felix von Leitner
> Dann kennst Du sicher auch Hardware, die beim Lesen eines memory mapped
> Registers dieses löscht.
Du meinst bei Hardware, bei der die Register nicht eh write-only sind,
nicht?
Bei memory mapped I/O ist aber gewöhnlich kein Cache dazwischen IIRC.
Felix
Jens Grivolla
Nicht zuverlässig.
Ciao,
Jens
Juergen P. Meier
Genau.
Florian Laws
>
>>> BTW: Das ist der Grund für die beliebten SIGBUS ...
>>
>>Das ist ja auch der Grund, wieso man auf x86 programmiert.
>>Kein SIGBUS.
>
> movl eax, (register)
> macht drei Buszugriffe? Ein 32bit -> krach und dann einen 8 und einen 24 bit
> Zugriff? Ist der Prozessor völlig verrückt geworden?
Nein, kompatibel.
Grüße,
Florian
Florian Laws
>>
>> Und die baut man mit autoconf? Weil das so üblich ist? He! Ich wollte
>> Vorschläge, wie sich meine Stimmung heben könnte, nicht wie man meine
>> Nervenbahnen in den Kollaps treibt.
>
> Autoconf ist auch FDA, es autokonfiguriert nicht, wenn sich der Programmierer
> dann nicht um das erzeugte CONFIG.H schert - was unter Linux mittlerweile
> uebliche Praxis ist. Damit laeuft das Gewurschtel dann natuerlich nur
> unter Linux, mit etwas Talent sogar nur unter Linux Kernel-X.Y.Z mit
> glibc-A.B.C [0]. BTDT.
Aber es beruhigt den Linux-root, der, wenn er sich schon einmal traut, ein
Programm aus dem Source zu installieren, erwartet, dass dies mit
"./configure; make; make install" zu funktionieren hat.
Grüße,
Florian
Andreas Bogk
>>> >Warum wirfst du nicht statt Ada ein paar bunte Ocaml-Speedpillen ein?
>>> Das hilft?
>>Naja, in dem Sinne wie ein Schlag auf den Kopf einen kurzzeitig die
>>Magenschmerzen vergessen läßt.
> Das Argument hat was: Schau, das ist noch schlimmer.
Ach, das ist doch bloß Fefes Art, mal eine Software zu loben. Der
Ocaml-Compiler ist derzeit anerkannt das Abgefahrenste, was man an
Compilertechnologie zu sehen bekommt.
>>Das ist inzwischen auch schon wieder gut abgehangen. Modern ist J2EE
>>mit EJB, on-the-fly XSLT-Nutzung und SOAP.
> Dann bin ich anachronistisch, weil ich bis auf XSLT keinen der
> Begriffe kenne.
Oh du Glücklicher!
Gruss Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
Andreas Bogk
> *Hmm* Nenn mich altmodisch, aber ich spezifiziere für den Datenaustausch
> von den ABI unabhängige Formate. Kleine Programme, die vollständig in einem
> Compiler durchgezogen werden.
Ja, Source Code ist das einzig sinnvolle ABI.
Hanno 'Rince' Wagner
Felix von Leitner <usenet-...@fefe.de> wrote:
> Das ist inzwischen auch schon wieder gut abgehangen. Modern ist J2EE
> mit EJB, on-the-fly XSLT-Nutzung und SOAP.
Ich glaube ich bin froh diese ganzen Begriffe (ausser J2EE) nicht zu
kennen.
Und - ehrlich gesagt, mir gefiel die hardwarenahe Programmierung
besser. Schankere, elegante, effiziente Programme ohne Bloat...
Ciao, Hanno
--
Felix von Leitner
> >>Naja, in dem Sinne wie ein Schlag auf den Kopf einen kurzzeitig die
> >>Magenschmerzen vergessen läßt.
> > Das Argument hat was: Schau, das ist noch schlimmer.
> Ach, das ist doch bloß Fefes Art, mal eine Software zu loben. Der
> Ocaml-Compiler ist derzeit anerkannt das Abgefahrenste, was man an
> Compilertechnologie zu sehen bekommt.
ACK.
Wenn der Compiler nur noch Sprachen übersetzen konnte, mit denen man in
der Praxis etwas anfangen könnte...
Felix
Florian Weimer
>> Außerdem ist Cross-Vendor- und Cross-Version-Kompatibilität bei Ada
>> nachweislich schlechter als bei C. Für die meisten Architekturen gibt
>> es einfach keine ABI-Spezifikation.
>
> Mwaa. Sag doch sowas nicht. Ich bin gerade dabei Ada wegen
> Plattformübergreifend (für Werte von Linux+Windows) zu lernen.
Plattformübergreifend funktioniert es ja, aber nicht unbedingt
herstellerübergreifend auf derselben Plattform (im Gegensatz zu C).
Florian Weimer
> Das Reference Manual schreibt vor, was ein Ada Compiler verstehen und wie er
> es umsetzen muß. Representation Clauses gehören dazu.
Du irrst. Es gibt ein Minimal Set, das längst nicht von allen
Compilern unterstützt wird.
> Pragma Pack insbesondere.
Pragma Pack kann durchweg keinen Effekt haben, ohne daß die Norm
verletzt wird.
>>Die Chancen, daß Du einen Satz Representation Clauses durch einen anderen
>>Compiler als GNAT bekommst, sind niedriger, als Du denkst, fürchte ich.
>
> Das mag sein, wenn man sich auf die Erweiterungen verläßt. Muß man
> aber nicht.
Was Du nutzt, sind keine Erweiterungen, sondern nicht verpflichtend zu
implementierende Bestandteile der Sprachenorm.
>>>>Wenn "irgendwas" mal ein "struct xxx *" war, sehe ich nicht, wo da das
>>>>Problem sein soll.
>>>
>>> Es war ein memcpy dazwischen.
>>
>>Das macht nichts, solange es mal ein "struct xxx *" war.
>
> man Alignment.
Wenn das Alignment nicht stimmt, war schon die Konvertierung nach
"struct xxx *" undefiniert.
Florian Weimer
>> Das ist inzwischen auch schon wieder gut abgehangen. Modern ist J2EE
>> mit EJB, on-the-fly XSLT-Nutzung und SOAP.
>
> Ich glaube ich bin froh diese ganzen Begriffe (ausser J2EE) nicht zu
> kennen.
Ich hielt SOAP einige zeitlang für die größte Bedrohung, zeitlich
weitaus näher als IPv6. Glücklicherweise scheint SOAP ein ziemlicher
Flop zu sein.
Lutz Donnerhacke
Kein Problem:
$ cat configure
#! /bin/sh
echo "Don't worry. Everthing will work fine."
echo "Just try make; make install"
$
Lutz Donnerhacke
>lu...@iks-jena.de (Lutz Donnerhacke) writes:
>> Das Reference Manual schreibt vor, was ein Ada Compiler verstehen und
>> wie er es umsetzen muß. Representation Clauses gehören dazu.
>
>Du irrst. Es gibt ein Minimal Set, das längst nicht von allen
>Compilern unterstützt wird.
Ich unterliege dann dem Irrtum, daß Ada Compiler das Reference Manual
erfüllen müssen. Gut zu wissen. In dem Sinne sind dann Compiler, die das
Reference Manual ignorieren Compiler für etwas Ada ähnliches, und das muß
mich nicht scheren.
>> Pragma Pack insbesondere.
>
>Pragma Pack kann durchweg keinen Effekt haben, ohne daß die Norm verletzt
>wird.
Dann eben for ...'Size use ... ;-)
>>>Die Chancen, daß Du einen Satz Representation Clauses durch einen anderen
>>>Compiler als GNAT bekommst, sind niedriger, als Du denkst, fürchte ich.
>>
>> Das mag sein, wenn man sich auf die Erweiterungen verläßt. Muß man
>> aber nicht.
>
>Was Du nutzt, sind keine Erweiterungen, sondern nicht verpflichtend zu
>implementierende Bestandteile der Sprachenorm.
Das ist mir beim Lesen der Norm bisher entgangen. *seufz*
>Wenn das Alignment nicht stimmt, war schon die Konvertierung nach "struct
>xxx *" undefiniert.
Yep. Ich weiß auch nicht genau, wo es kracht, vermute aber, daß die
Konvertierung nur Compiletime ist.
Felix von Leitner
> weitaus näher als IPv6.
Tue ich immer noch.
> Glücklicherweise scheint SOAP ein ziemlicher Flop zu sein.
Naja, die gesamte Microsoft-Produktpalette wird gerade darauf
umgestellt. Man wird also dazu kompatibel sein müssen eines Tages.
Felix
Felix von Leitner
> > Wenn der Compiler nur noch Sprachen übersetzen konnte, mit denen man in
> > der Praxis etwas anfangen könnte...
> Ist das nicht toll?ß??
ARGH! Und das früh am Morgen auf nüchternen Magen!
Note to self: Erst nach ausführlichem Frühstück News lesen.
Andreas Bogk
>> Ja, allerdings möglichst Datenbankunabhängig. Vergleichbar
>> mit ODBC/JDBC eben.
> Dann nimm ODBC. Bindings gibt es genügend. Spontan fällt mir da
> gnade.sourceforge.net ein. (GNU Ada Database Environment).
Datenbankunabhängig, ja? Ich muß nur eine datenbankspezifische Library
linken, und schon ist es datenbankunabhängig. Toll gelöst.
ODBC unter Linux ist der direkte Import der DLL-Hölle.
Andreas Bogk
> Und - ehrlich gesagt, mir gefiel die hardwarenahe Programmierung
> besser. Schankere, elegante, effiziente Programme ohne Bloat...
Ich verstehe ja nicht, wie man dieses elende Pointergewurstel und
durch-die-Gegend-Gecaste als elegant empfinden kann.
Lutz Donnerhacke
> Hanno 'Rince' Wagner <wag...@fitug.de> writes:
>> Und - ehrlich gesagt, mir gefiel die hardwarenahe Programmierung
>> besser. Schankere, elegante, effiziente Programme ohne Bloat...
>
> Ich verstehe ja nicht, wie man dieses elende Pointergewurstel und
> durch-die-Gegend-Gecaste als elegant empfinden kann.
Hardwarenahe Programmierung heißt nicht, daß man Pointer oder Casts benötigt.
Martin Bienwald
> Note to self: Erst nach ausführlichem Frühstück News lesen.
Schlechte Idee. Zweirichtungsfrühstück ist !recovery.
... Martin
Michael Engert
wie auf ein Bitfeld zugegriffen wird. Dann lernte ich, wie verschieden
Rechner bezüglich ihrer Wortbreite sein können. Dann habe ich beschlossen,
keine Bitfelder mehr zu verwenden. Jetzt bin ich glücklicher.
Lutz Donnerhacke <lu...@iks-jena.de> wrote:
> * Felix von Leitner wrote:
>>Thus spake Lutz Donnerhacke (lu...@iks-jena.de):
>>> * Felix von Leitner wrote:
>>>> An sich ist da noch ein Cache dazwischen, und soweit ich weiß zieht
>>>> der Prozessor dann zwei 32-bit Werte und extrahiert die gewollten.
>>>> Beim Schreiben ist das natürlich etwas aufwendiger.
>>> Du weißt aber, was Hardware damit macht, ja?
>>Ich lebte unter der Vorstellung, ich spräche von der Hardware.
>
> Dann kennst Du sicher auch Hardware, die beim Lesen eines memory mapped
> Registers dieses löscht.
Der Prozessor erkennt das Misalignment vor dem 32-Bit-Zugriff und ersetzt
ihn durch zwei 16-Bit-Zugriffe bzw. den misaligned 16-Bit-Zugriff durch zwei
8-Bit-Zugriffe. Das kostet ein paar Transistoren, Steuerleitungen und Zeit
für zusätzliche Zugriffszyklen, andererseits kann man sich ein paar
(früher teure) Bytes sparen und muß sich beim Programmieren in Assembler
keine Gedanken machen. Andere Prozessoren haben diese Logik nicht und
fallen bei Misalignment gnadenlos auf die Nase. Wenn man's weiß, ist's
auch kein Problem.
Ansonsten gibt es durchaus PC-Hardware, die mit dem Gemisch aus Zugriffen
unterschiedlicher Breite und den diversen Caches gar nicht klar kommt,
deswegen zusätzliche BIOS-Optionen und Treiber-Gefrickel braucht. Ich
glaube, solche Hardware nennt man Kassenschlager.
Servus, Michi.
--
----------------------------------------------------------------------------
Michael Engert mi...@engert.org
80337 München
Michael Schwingen
Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>
>Dann kennst Du sicher auch Hardware, die beim Lesen eines memory mapped
>Registers dieses löscht.
Dann sollte man die Daten, die man lesen will, auch als "volatile"
deklarieren. Und dafür sorgen, daß dieser memory-mapped-Bereich in der PMMU
auf "non-cacheable, serialized" steht (oder wie das Äquivalent bei Intel
heißt - jetzt sag' bitte keiner, das geht dort nicht!).
cu
Michael
Michael Schwingen
Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>
>Und Watcom hat noch andere. Von Microsoft ganz zu schweigen. In GCC schreibt
>man __attribute__(packed) nach die Strukturdefinition. Erst dann darf man
>die so definierte Struktur verwenden (z.B. für typedef), muß aber immer
Nützt Dir aber auch nichts, um eine Struktur auf nicht-alignte bytestreams
abzubilden:
typedef struct
{
unsigned long a;
unsigned char b;
unsigned long c;
} __attribute__((packed)) S;
unsigned long test(S *s)
{
return s->a + s->c;
}
erzeugt für powerpc-eabi (gcc 3.0.1)
test: lwz 0,5(3)
lwz 3,0(3)
add 3,3,0
blr
Der erste Befehl dürfte wegen unaligned access knallen, oder habe ich jetzt
was übersehen?
cu
Michael
Felix von Leitner
> > besser. Schankere, elegante, effiziente Programme ohne Bloat...
> Ich verstehe ja nicht, wie man dieses elende Pointergewurstel und
> durch-die-Gegend-Gecaste als elegant empfinden kann.
Huh? Wie kommst du darauf, daß man durch die Gegend casten müsse oder
Pointergewurstel braucht?
Kein Wunder, daß du C scheiße findest, wenn so deine Vorstellung von C ist.
FElix
Andreas Bogk
>> Ich verstehe ja nicht, wie man dieses elende Pointergewurstel und
>> durch-die-Gegend-Gecaste als elegant empfinden kann.
> Huh? Wie kommst du darauf, daß man durch die Gegend casten müsse oder
> Pointergewurstel braucht?
Na gut, mach mal vor, wie's ohne geht. Nehmen wir ein fiktives Stück
Hardware. Der Bus sei 32 Bit breit, die Bits sind von 0 bis 31
durchnumeriert, 0 ist das least significant bit. Ich verwende die
Notation 3[31:24] für die 8 signifikanten Bits des vierten Wortes von
unten im Adreßbereich der Hardware.
Das Betrübssystem stellt dir folgende Informationen bereit:
void* base; // Dahin wurde die Hardware gemappt
bool bus_big_endian; // TRUE iff 0[31:24] == base
bool cpu_big_endian; // na was wohl
Aufgabe ist das Schreiben von getter- und setter-Routinen für folgende
Register:
Adresse Typ Name
0[31:16] 16-bit unsigned litte endian foo
0[15:8] 8-bit twos complement signed bar
4[13:6] 8 bit ones complement signed baz
4[5:0] Undefiniert, darf aber nur mit Werten beschrieben werden, die man
da vorher rausgelesen hat.
Jens Link
> Aber es beruhigt den Linux-root, der, wenn er sich schon einmal traut, ein
> Programm aus dem Source zu installieren,
"Source? Was ist das ueberhaupt? Wieso gibt es da kein rpm fuer
mein SuSE Linux und ueberhaupt, unter Windows ist das alles viel
einfacher."
Jens
--
I just found out that the brain is like a computer.
If that's true, then there really aren't any stupid people.
Just people running Windows.
Claus Färber
> Kaum ein C-Compiler-Hersteller wird es sich leisten, mal eben von
> Minor Release zu Minor Release die ABI zu ändern.
C hat ein ABI?
Claus
--
------------------------ http://www.faerber.muc.de/ ------------------------
OpenPGP: DSS 1024/639680F0 E7A8 AADB 6C8A 2450 67EA AF68 48A5 0E63 6396 80F0
Christoph 'Mehdorn' Weber
Felix von Leitner <usenet-...@fefe.de>:
>
> ARGH! Und das früh am Morgen auf nüchternen Magen!
>
> Note to self: Erst nach ausführlichem Frühstück News lesen.
man Magensonde. Damit kann man das Garfieldsche
Überlebensritual exakt umsetzen: Essen UND schlafen.
Zeitgleich.
Christoph
--
Use "omniscient" in your subject to bypass my spam filter
If you are not making 50 mistakes a day, you're not trying
hard enough!
Florian Weimer
> Florian Weimer <f...@deneb.enyo.de> wrote:
>> Kaum ein C-Compiler-Hersteller wird es sich leisten, mal eben von
>> Minor Release zu Minor Release die ABI zu ändern.
>
> C hat ein ABI?
Bei den größeren Plattformen gibt es ABI-Dokumente, an die sich
mehrere Hersteller halten.
Bei Ada ist das eher die Ausnahme.
Matthias Szusdziara
> man Magensonde. Damit kann man das Garfieldsche
> Überlebensritual exakt umsetzen: Essen UND schlafen.
> Zeitgleich.
Mir gefällt das von Garfield's Opa ganz gut (hab's mal vor Ur-Zeiten
irgendwo gelesen): Statt aufzustehen und zum Kühlschrank zu gehen,
hat der nur sein Gebiß zum Kühlschrank geworfen...
Auf meinem steht aber leider noch nicht "Made in Taiwan" oder Vergleich-
bares, insofern ist es für mich nicht praktikabel. ;o)
MfG
Matt
Tobias Wolter
> Ich verstehe ja nicht, wie man dieses elende Pointergewurstel und
> durch-die-Gegend-Gecaste als elegant empfinden kann.
Manche empfinden Magie einfach nur als ein Mittel, etwas zu
bewerkstellen.
Für andere wieder ist es Thaumaturgie.
-towo
--
> Then again, this is still an Internet where the appropriately named
> Domino server
It's not appropriately named; it should be called Lotus House of Cards.
- Steve Sobol, in response to Alan Brown
Holger Veit
> Florian Weimer <f...@deneb.enyo.de> wrote:
>> Kaum ein C-Compiler-Hersteller wird es sich leisten, mal eben von
>> Minor Release zu Minor Release die ABI zu ändern.
>
> C hat ein ABI?
Ordentliche (kommerzielle) Compiler haben eins, und die
entsprechenden Hersteller halten sich auch sklavisch daran.
Der beobachtbare Murks ist eigentlich ausnahmslos ein
gcc-Problem.
Holger
--
Please update your tables to my new e-mail address:
holger.veit$ais.fhg.de (replace the '$' with '@' -- spam-protection)
Gert Doering
>Und - ehrlich gesagt, mir gefiel die hardwarenahe Programmierung
>besser. Schankere, elegante, effiziente Programme ohne Bloat...
Jajaja :)
gert
--
Wege entstehen, wenn wir sie gehen. | gert doering
Vielleicht sollte ich meinen Beobachterposten | ge...@greenie.muc.de
an der Strassenkreuzung aufgeben. | 2:2480/55.4
Lutz Donnerhacke
> Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>>Und Watcom hat noch andere. Von Microsoft ganz zu schweigen. In GCC schreibt
>>man __attribute__(packed) nach die Strukturdefinition. Erst dann darf man
>>die so definierte Struktur verwenden (z.B. für typedef), muß aber immer
>
> Nützt Dir aber auch nichts, um eine Struktur auf nicht-alignte bytestreams
> abzubilden:
> Der erste Befehl dürfte wegen unaligned access knallen, oder habe ich jetzt
> was übersehen?
Nein, Du siehst das völlig korrekt. C ist für hardwarenahe Programmierung
ungeeignet.
Holger Veit
Njet. Der Vorredner hat Garbage verlangt, also hat er ihn auch bekommen.
Wenn die Plattform unaligned accesses trappt, dann ist Byte-Alignment
Pfusch des Programmierers. Typischerweise wird auf solchen Plattformen
auch nirgendwo hardwarenah (z.B. in memory-mapped-I/O) ein solcher
schiefer Access verlangt, also: was will der Programmierer auch solchen
Mist (dass der gcc-Compiler so schrottig ist, das auf einer solchen
Plattform zuzulassen, ist nicht C, sondern gcc, bzw. dessen Codefricklern
anzulasten).
Die einzige zulaessige Folgerung ist hoechstens, dass C Programme unportabel
sind, aber das gilt fuer Ada[1] und Assembler gleichermassen.
Holger
[1] Es ist besser, es kracht beim ersten Versuch, weil etwas technisch
nicht geht, als dass mir der Compiler ohne Vorwarnung irgendeinen
ineffizienten Code zurechtfrickelt, und ich dann doch wieder im
Assembler-Output rumsuchen muss, warum das Programm so fuerchterlich
lahm daher gurkt. Intelligente Compiler, die versuchen, meine Denkfehler
zu korrigieren, sind unbrauchbar. You asked for a crash, you got one.
Lutz Donnerhacke
> Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>>> Nützt Dir aber auch nichts, um eine Struktur auf nicht-alignte bytestreams
>>> abzubilden:
>> [...]
>>> Der erste Befehl dürfte wegen unaligned access knallen, oder habe ich jetzt
>>> was übersehen?
>>
>> Nein, Du siehst das völlig korrekt. C ist für hardwarenahe Programmierung
>> ungeeignet.
>
> Njet. Der Vorredner hat Garbage verlangt, also hat er ihn auch bekommen.
Nein.
> Wenn die Plattform unaligned accesses trappt, dann ist Byte-Alignment
> Pfusch des Programmierers. Typischerweise wird auf solchen Plattformen
> auch nirgendwo hardwarenah (z.B. in memory-mapped-I/O) ein solcher
> schiefer Access verlangt,
Doch: Empfange einen Frame von extern und betrachte es durch die
Strukturbrille. Du kannst den Frame gern dort lassen, wo er empfangen wurde,
damit Du keine Misalignments durch memcpy bekommst.
Du kannst alternativ auch nachsehen, wie realloc Alignments zerbröselt, wenn
Du einen strukturierten Datentyp vergrößern willst. (calloc beachtet
Alignments, wenn es passende Strukturgrößen bekommt)
> also: was will der Programmierer auch solchen Mist (dass der gcc-Compiler
> so schrottig ist, das auf einer solchen Plattform zuzulassen, ist nicht
> C, sondern gcc, bzw. dessen Codefricklern anzulasten).
C bietet keine Möglichkeit, das Constraint zu spezifizieren. Was soll der
Compiler tun? Raten?
> Die einzige zulaessige Folgerung ist hoechstens, dass C Programme unportabel
> sind, aber das gilt fuer Ada[1] und Assembler gleichermassen.
Nicht ganz. Ada weiß um die Alignments bei der Codegenerierung und bei
Assembler weiß es der Programmierer.
> [1] Es ist besser, es kracht beim ersten Versuch, weil etwas technisch
> nicht geht, als dass mir der Compiler ohne Vorwarnung irgendeinen
> ineffizienten Code zurechtfrickelt,
Das tut er nicht. IIRC wird es Exceptions beim Casten. (Nonportabel)
> und ich dann doch wieder im Assembler-Output rumsuchen muss, warum das
> Programm so fuerchterlich lahm daher gurkt. Intelligente Compiler, die
> versuchen, meine Denkfehler zu korrigieren, sind unbrauchbar. You asked
> for a crash, you got one.
C gestattet Dir keinen definierten Crash, sondern falsche Ergebnisse.
Daniel Hartmeier
> Du kannst alternativ auch nachsehen, wie realloc Alignments zerbröselt, wenn
> Du einen strukturierten Datentyp vergrößern willst. (calloc beachtet
> Alignments, wenn es passende Strukturgrößen bekommt)
Dann ist die realloc Implementation nicht-konform.
ISO 9899, 7.20.3, (ueber calloc, malloc und realloc)
The pointer returned if the allocation succeeds is suitably aligned
so that it may be assigned to a pointer to any type of object and
then used to access such an object or an array of such objects in
the space allocated (until the space is explicitely deallocated).
Beispiel, wie sich Dein realloc diesbezueglich anders als malloc/calloc
verhaelt?
Daniel
Lutz Donnerhacke
> On Thu, 17 Oct 2002 10:49:58 +0000 (UTC), Lutz Donnerhacke wrote:
>> Du kannst alternativ auch nachsehen, wie realloc Alignments zerbröselt,
>> wenn Du einen strukturierten Datentyp vergrößern willst. (calloc
>> beachtet Alignments, wenn es passende Strukturgrößen bekommt)
>
> Dann ist die realloc Implementation nicht-konform.
>
> ISO 9899, 7.20.3, (ueber calloc, malloc und realloc)
>
> The pointer returned if the allocation succeeds is suitably aligned
> so that it may be assigned to a pointer to any type of object and
> then used to access such an object or an array of such objects in
> the space allocated (until the space is explicitely deallocated).
Das würde bedeuten, daß alle zurückgelieferten Pointer 0 sind. (Oder
mindestens auf eine Pagegrenze fallen.) Die Aussage ist nur dann sinnvoll,
wenn man ein maximales Alignment (z.B. long long) vorschreibt.
Ulrich Eckhardt
> * Ulrich Eckhardt wrote:
>
>>nach 2 Tagen ok. Auf NT kämpfe ich schon seit einer Woche
> GCC 3.2 ist buggy. Mehr als buggy. Zumindest der dysfunktionale Ada Teil.
Jepp. Beim Compiliern von GtkAda 1.2 mit internal compiler error
abgeschmiert. Also jetzt gcc2.95 durchs Modem quetschen.
Kennt jemand eine gute Entziehungskur gegen Froschpillenmissbrauch
und Tischkantensüchtigkeit.
Uli (Aber unter NT funktionierts seit heute wenn auch mit GtkAda1.2)
--
Ulrich Eckhardt
http://www.uli-eckhardt.de
Daniel Hartmeier
>> ISO 9899, 7.20.3, (ueber calloc, malloc und realloc)
>>
>> The pointer returned if the allocation succeeds is suitably aligned
>> so that it may be assigned to a pointer to any type of object and
>> then used to access such an object or an array of such objects in
>> the space allocated (until the space is explicitely deallocated).
>
> Das würde bedeuten, daß alle zurückgelieferten Pointer 0 sind. (Oder
> mindestens auf eine Pagegrenze fallen.) Die Aussage ist nur dann sinnvoll,
> wenn man ein maximales Alignment (z.B. long long) vorschreibt.
Ja, man daraus auf ein maximales Alignment schliessen, obwohl der Standard
solches nicht explizit vorschreibt. Kennst Du eine Architektur ohne
max. Alignment, unter der Compilerhersteller Probleme haben, diese
Anforderung an *alloc zu erfuellen?
Daniel
Daniel Hartmeier
> Doch: Empfange einen Frame von extern und betrachte es durch die
> Strukturbrille. Du kannst den Frame gern dort lassen, wo er empfangen wurde,
> damit Du keine Misalignments durch memcpy bekommst.
Du greifst auf den Frame halt nicht direkt ueber einen Strukturzeiger
zu, der das Alignment verletzt, sondern kopierst die Inhalte der
Felder einzeln mit memcpy in ein korrekt alloziertes Strukturobjekt.
Serialisierung sollte auch einem C Programmierer bekannt sein, und
sonst faellt er beim ersten
struct foo f;
send(s, &f, sizeof(f), 0); bzw. write(d, &f, sizeof(f));
auf die Nase.
Wenn die Kopiererei zu langsam ist, kann man (mit den entsprechenden
Compiler-/Architekturspezifischen Erweiterungen) auch die Struktur
so definieren, dass sie ein festes Layout hat, so passt z.B.
struct ip/tcphdr/etc. auch direkt auf das Frame (den mbuf).
Daniel
Lutz Donnerhacke
Pagealignment braucht der Kernel häufig. Schau Dir einfach die
Datenstrukturen an, die I/O Hardware erwartet: Alignment requirement ist
hier typischerweise 2**16. Wie löst das der C-Freak?
void * pc = malloc(0x20000l);
void * realp = (void *)(((unsigned long)pc + 0xffff) & ~0xffffl);
Richtig?
Lutz Donnerhacke
> On Thu, 17 Oct 2002 10:49:58 +0000 (UTC), Lutz Donnerhacke wrote:
>> Doch: Empfange einen Frame von extern und betrachte es durch die
>> Strukturbrille. Du kannst den Frame gern dort lassen, wo er empfangen
>> wurde, damit Du keine Misalignments durch memcpy bekommst.
>
> Du greifst auf den Frame halt nicht direkt ueber einen Strukturzeiger
> zu, der das Alignment verletzt, sondern kopierst die Inhalte der
> Felder einzeln mit memcpy in ein korrekt alloziertes Strukturobjekt.
*Gna*
> Wenn die Kopiererei zu langsam ist, kann man (mit den entsprechenden
> Compiler-/Architekturspezifischen Erweiterungen) auch die Struktur
> so definieren, dass sie ein festes Layout hat, so passt z.B.
> struct ip/tcphdr/etc. auch direkt auf das Frame (den mbuf).
Schade, daß das nicht normiert ist.
> Serialisierung sollte auch einem C Programmierer bekannt sein, und
> sonst faellt er beim ersten
>
> struct foo f;
> send(s, &f, sizeof(f), 0); bzw. write(d, &f, sizeof(f));
>
> auf die Nase.
Was ist daran falsch?
Andreas Bogk
> Ich frage mich oefter, wozu C geeignet ist.
Es dient prima als schlechtes Beispiel.
Daniel Hartmeier
>> struct foo f;
>> send(s, &f, sizeof(f), 0); bzw. write(d, &f, sizeof(f));
>
> Was ist daran falsch?
Das Layout der Struktur (z.B. Padding, Byte order) ist nicht definiert,
und wenn Du die Daten spaeter aus dem Socket bzw. der Datei lesen willst,
wird es kaum zufaellig uebereinstimmen. Derselbe Compiler, in der
gleichen Version, auf der gleichen Architektur, _koennte_ evtl. das
gleiche Layout erwarten (IIRC muss er nicht mal).
Daniel
Daniel Hartmeier
> Pagealignment braucht der Kernel häufig. Schau Dir einfach die
> Datenstrukturen an, die I/O Hardware erwartet: Alignment requirement ist
> hier typischerweise 2**16. Wie löst das der C-Freak?
> void * pc = malloc(0x20000l);
> void * realp = (void *)(((unsigned long)pc + 0xffff) & ~0xffffl);
Der zitierte Abschnit besagt ja nicht, dass *alloc() die einzigen
Funktionen sind, die einen Speicherbereich mit gewuenschtem
Alignment liefern koennen. Es gibt auch noch mmap et. al.
Daniel
Holger Veit
> * Holger Veit wrote:
[...]
>> Wenn die Plattform unaligned accesses trappt, dann ist Byte-Alignment
>> Pfusch des Programmierers. Typischerweise wird auf solchen Plattformen
>> auch nirgendwo hardwarenah (z.B. in memory-mapped-I/O) ein solcher
>> schiefer Access verlangt,
>
> Doch: Empfange einen Frame von extern und betrachte es durch die
> Strukturbrille. Du kannst den Frame gern dort lassen, wo er empfangen wurde,
Seit wann garantiert der Standard, dass jeder x-beliebige Cast eines
beliebig align-ten void* auf irgendwas anderes eine Identitaets-
Operation ist? Dass das oftmals klappt, liegt zufaellig daran, dass
die meiste Software gerade auf einem System entwickelt wurde, welches
sich um misalignments nicht schert. Bei 68000 oder PPC oder gar
diversen Signalprozessoren kannst Du diesen Dreck nicht erfolgreich
in C machen.
Nicht umsonst gibt es das Sun-XDR-Gewuerge fuer solche Anwendungsfaelle.
Wer glaubt, sich darueber hinwegsetzen zu koennen und sich auf einen
unsicheren Cast zu verlassen, soll ruhig reinfallen.
> damit Du keine Misalignments durch memcpy bekommst.
memcpy ist aligment- und sogar overlap-sicher. Der Cast
void* p = irgendwas;
long x = *(long*)p;
ist nicht generell garantiert (in der Form: Bitmuster von (void*)p ==
Bitmuster (long*)p). Alternativ koennte man auch sagen:
schlampiger Compilerbau, denn in obigem Falle waere ja durchaus ein
void* p = irgendwas;
long x;
memcpy(&x,p,sizeof(long));
moeglich.
> Du kannst alternativ auch nachsehen, wie realloc Alignments zerbröselt, wenn
> Du einen strukturierten Datentyp vergrößern willst. (calloc beachtet
> Alignments, wenn es passende Strukturgrößen bekommt)
Nicht standard-konforme Implementation.
>> also: was will der Programmierer auch solchen Mist (dass der gcc-Compiler
>> so schrottig ist, das auf einer solchen Plattform zuzulassen, ist nicht
>> C, sondern gcc, bzw. dessen Codefricklern anzulasten).
>
> C bietet keine Möglichkeit, das Constraint zu spezifizieren. Was soll der
> Compiler tun? Raten?
Eben nicht raten. In dem Fall:
#pragma pack(1)
struct {
long a;
char b;
long c;
} x;
sind b und c fuer den Compiler der betreffenden Plattform misaligned. Daraus
eine misaligned move-Instruktion zu generieren, die dann kracht, ist ein Bug.
Ich muss mich korrigieren: der Sparc-gcc geht mit unaligned-Structs, die
er kennt, korrekt um, wobei er allerdings mit perversen Typecasts von
unaligned void* auf irgendwas auch bisweilen Fehler macht. Dann garantiert
das aber einen segmentation fault.
Beispiel, was Sparc macht:
#ifdef PACK
#pragma pack(1)
#endif
struct foo {
long a;
char b;
long c;
} x;
long bar(void) {
long a = x.a + x.c;
return a;
}
----------------------------
gcc -S x.c:
.file "x.c"
gcc2_compiled.:
.section ".text"
.align 4
.global bar
.type bar,#function
.proc 04
bar:
!#PROLOGUE# 0
save %sp,-120,%sp
!#PROLOGUE# 1
sethi %hi(x),%o0
sethi %hi(x),%o1
mov 8,%o2
or %o1,%lo(x),%o3
add %o2,%o3,%o1
ld [%o0+%lo(x)],%o0
ld [%o1],%o1
add %o0,%o1,%o0
st %o0,[%fp-20]
ld [%fp-20],%o0
mov %o0,%i0
b .LL1
nop
.LL1:
ret
restore
.LLfe1:
.size bar,.LLfe1-bar
.common x,12,4
.ident "GCC: (GNU) 2.8.1"
----------------------------------------
gcc -DPACK -S x.c:
.file "x.c"
gcc2_compiled.:
.section ".text"
.align 4
.global bar
.type bar,#function
.proc 04
bar:
!#PROLOGUE# 0
save %sp,-120,%sp
!#PROLOGUE# 1
sethi %hi(x),%o0
ldub [%o0+%lo(x)],%o1
and %o1,0xff,%o2
sll %o2,24,%o1
mov 1,%o2
or %o0,%lo(x),%o3
add %o2,%o3,%o2
ldub [%o2],%o3
and %o3,0xff,%o2
sll %o2,16,%o3
or %o3,%o1,%o1
mov 2,%o2
or %o0,%lo(x),%o3
add %o2,%o3,%o2
ldub [%o2],%o3
and %o3,0xff,%o2
sll %o2,8,%o3
or %o3,%o1,%o1
mov 3,%o2
or %o0,%lo(x),%o3
add %o2,%o3,%o0
ldub [%o0],%o3
and %o3,0xff,%o2
or %o2,%o1,%o0
sethi %hi(x),%o1
mov 5,%o2
or %o1,%lo(x),%o3
add %o2,%o3,%o2
ldub [%o2],%o4
and %o4,0xff,%o3
sll %o3,24,%o2
mov 6,%o3
or %o1,%lo(x),%o4
add %o3,%o4,%o3
ldub [%o3],%o4
and %o4,0xff,%o3
sll %o3,16,%o4
or %o4,%o2,%o2
mov 7,%o3
or %o1,%lo(x),%o4
add %o3,%o4,%o3
ldub [%o3],%o4
and %o4,0xff,%o3
sll %o3,8,%o4
or %o4,%o2,%o2
mov 8,%o3
or %o1,%lo(x),%o4
add %o3,%o4,%o1
ldub [%o1],%o3
and %o3,0xff,%o1
or %o1,%o2,%o2
add %o0,%o2,%o0
st %o0,[%fp-20]
ld [%fp-20],%o0
mov %o0,%i0
b .LL1
nop
.LL1:
ret
restore
.LLfe1:
.size bar,.LLfe1-bar
.common x,9,1
.ident "GCC: (GNU) 2.8.1"
Man braucht keinen Sparc-Assembler zu verstehen, um den Unterschied
festzustellen. Es gibt C- (sogar gcc-) Compiler, die sich richtig
verhalten. Ich wuerde mich nicht wundern, wenn er bei einem
potentiell unalignten Typecast ebenfalls eine Shift/And/Or-Orgie
auffuehrte, etwa bei einem
char blah[sizeof(struct foo)+1];
read(fd,blah+1,sizeof(struct foo));
struct foo* p = &blah[1];
...
struct foo* blubb = p;
Das blah[] hat er alloziert, da weiss er, dass es aligned ist.
&blah[1] ist definitiv misaligned. blurb ist moeglicherweise
misaligned (im Beispiel sieht man's, als formales Argument ist das
nicht unbedingt garantiert).
Ich bin mir uebrigens sicher, dass Ada sich da ebenfalls falsch
verhalten wuerde, sofern es ueberhaupt einen impliziten Typecast eines
abstrakten Pointers auf eine Datenstruktur erlaubt - ich meine mich
duester zu erinnern, dass man eine solche Typkonversionsfunktion
selbst per Hand stricken muss: do-it-yourself-memcpy laesst gruessen.
>> [1] Es ist besser, es kracht beim ersten Versuch, weil etwas technisch
>> nicht geht, als dass mir der Compiler ohne Vorwarnung irgendeinen
>> ineffizienten Code zurechtfrickelt,
>
> Das tut er nicht. IIRC wird es Exceptions beim Casten. (Nonportabel)
Beim Compilieren, oder vom Laufzeitsystem?
>> und ich dann doch wieder im Assembler-Output rumsuchen muss, warum das
>> Programm so fuerchterlich lahm daher gurkt. Intelligente Compiler, die
>> versuchen, meine Denkfehler zu korrigieren, sind unbrauchbar. You asked
>> for a crash, you got one.
>
> C gestattet Dir keinen definierten Crash, sondern falsche Ergebnisse.
Wieso? Auf einer alignment-toleranten Plattform kommt das heraus,
was der Programmierer *gesagt* hat, nichts anderes (ist natuerlich nicht
unbedingt das, was er *wollte*); auf einer nicht-alignment-toleranten
Plattform kracht es entweder definiert, oder das alignment ist zufaellig
gerade mal okay.
Holger
Holger Veit
Es *ist* zum hardwarenahen Programmieren geeignet (soweit nicht
Spezialinstruktionen der CPU involviert sind). Allerdings
schneidet es, wie ein gutes, scharfes Messer, einem die Kehle
durch, wenn man mit ihm jongliert, aber keine Ahnung davon hat
oder sich nicht aneignen will. Messer, C, Gabel, Schere, Licht,
sind weder fuer kleine Kinder, noch fuer inkompetente
Programmierer.
Hol "C-Fuehrerschein jetzt!" ger
Adrian Knoth
>>>nach 2 Tagen ok. Auf NT kämpfe ich schon seit einer Woche
>> GCC 3.2 ist buggy. Mehr als buggy. Zumindest der dysfunktionale Ada Teil.
> Jepp. Beim Compiliern von GtkAda 1.2 mit internal compiler error
> abgeschmiert. Also jetzt gcc2.95 durchs Modem quetschen.
Hast du schonmal GtkAda-2.0 ausprobiert? Es ist deutlich angenehmer, gut,
das Widget sieht etwas anders aus, aber UTF8-Support ist nice to have.
Kompiliert auch mit dem aktuellen GCC-co. Angeblich soll es aber in Bezug
auf Gtk-2.0 mit Windows ein paar Probleme geben, keine Ahnung.
> Uli (Aber unter NT funktionierts seit heute wenn auch mit GtkAda1.2)
Der MinGW-Mensch hat doch letztlich erst ein Update vom Stapel gelassen,
vielleicht läßt sich damit GtkAda2.0 übersetzen.
--
mail: a...@thur.de http://adi.thur.de PGP: v2-key via keyserver
Alle Kinder kamen auf die Welt, nur nicht Bernd, der wurde entfernt.
Lutz Donnerhacke
> Ich bin mir uebrigens sicher, dass Ada sich da ebenfalls falsch verhalten
> wuerde, sofern es ueberhaupt einen impliziten Typecast eines abstrakten
> Pointers auf eine Datenstruktur erlaubt
Zwei Varianten:
variable : Typ;
pragma Import(Ada, variable);
for variable'Address use xxx;
Oder eben System.Address_To_Access_Conversions, und ganz schrecklich ist
Unchecked_Conversion.
> ich meine mich duester zu erinnern, dass man eine solche
> Typkonversionsfunktion selbst per Hand stricken muss:
> do-it-yourself-memcpy laesst gruessen.
Das kann man außerdem tun. (Sollte man.)
>>> [1] Es ist besser, es kracht beim ersten Versuch, weil etwas technisch
>>> nicht geht, als dass mir der Compiler ohne Vorwarnung irgendeinen
>>> ineffizienten Code zurechtfrickelt,
>>
>> Das tut er nicht. IIRC wird es Exceptions beim Casten. (Nonportabel)
>
> Beim Compilieren, oder vom Laufzeitsystem?
Depends. ;-)
>> C gestattet Dir keinen definierten Crash, sondern falsche Ergebnisse.
>
> Wieso? Auf einer alignment-toleranten Plattform kommt das heraus,
> was der Programmierer *gesagt* hat, nichts anderes (ist natuerlich nicht
> unbedingt das, was er *wollte*);
Er sprach von einem Zugriff, nicht mehreren.
> auf einer nicht-alignment-toleranten Plattform kracht es entweder
> definiert, oder das alignment ist zufaellig gerade mal okay.
Klar.
Lutz Donnerhacke
> Patrick Piecha <pie...@micronas.com> wrote:
>> Ich frage mich oefter, wozu C geeignet ist.
>
> Es *ist* zum hardwarenahen Programmieren geeignet (soweit nicht
> Spezialinstruktionen der CPU involviert sind).
Overflow und Carry Flags sind Spezialinstruktionen?
> Allerdings schneidet es, wie ein gutes, scharfes Messer, einem die Kehle
> durch, wenn man mit ihm jongliert, aber keine Ahnung davon hat oder sich
> nicht aneignen will. Messer, C, Gabel, Schere, Licht, sind weder fuer
> kleine Kinder, noch fuer inkompetente Programmierer.
Sicher.
> Hol "C-Fuehrerschein jetzt!" ger
Aber bitte nur C99 und beim Betreten von 'undefined' gibt's einen Durchfaller.
Holger Veit
> * Holger Veit wrote:
>> Patrick Piecha <pie...@micronas.com> wrote:
>>> Ich frage mich oefter, wozu C geeignet ist.
>>
>> Es *ist* zum hardwarenahen Programmieren geeignet (soweit nicht
>> Spezialinstruktionen der CPU involviert sind).
>
> Overflow und Carry Flags sind Spezialinstruktionen?
Spezialregister (bzw. Bits davon), die Spezialinstruktionen
benoetigen, um da dran zu kommen (move status to accu, o.ae.).
BTW: die letzten Maschinen, bei denen Peripherie direkt
Statusbits gesetzt hat, die man unbedingt via dann auswerten musste,
waren PDP8-er (vom Maschinencode der HP41-CPU mal abgesehen).
Beliebter Code der 6502-Form:
xxx: tst ioreg
bvc xxx
(tst setzt bei Bit 6 das Overflow, bvc verzweigt auf OV=0,
d.h. Warte, bis das Bit 6 gesetzt ist)
lassen sich durchaus in C anders ausdruecken, allerdings
weniger effizient. Andererseits sind solche Maschinen und
Applikationen, bei denen exakt das erforderlich ist, technisch
ziemlich schwachbruestig, und eh kein Kandidat fuer
C-Programmierung. 8051 mit C-Compiler ist allein schon eine
Vergewaltigung des Programmierers.
Und dann gibt es hirnverbrannte System-APIs, welche von
geisteskranken Assemblerfreaks entworden wurden, welche
den Fehlercode in folgender Form uebergeben:
If Carry Clear:
AX enthaelt den regulaeren Returnwert
Else (Carry Set):
AX enthaelt den Fehlerstatus
(OS/2 DevHlp). Da ist dann ein ASM-Wrapper unerlaesslich.
Holger
Lutz Donnerhacke
> Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>> * Holger Veit wrote:
>>> Patrick Piecha <pie...@micronas.com> wrote:
>>>> Ich frage mich oefter, wozu C geeignet ist.
>>>
>>> Es *ist* zum hardwarenahen Programmieren geeignet (soweit nicht
>>> Spezialinstruktionen der CPU involviert sind).
>>
>> Overflow und Carry Flags sind Spezialinstruktionen?
>
> Spezialregister (bzw. Bits davon), die Spezialinstruktionen
> benoetigen, um da dran zu kommen (move status to accu, o.ae.).
Wirklich? Ich dachte immer Overflow und Carry wären dazu da,
herauszubekommen, ob man noch richtig rechnet.
> lassen sich durchaus in C anders ausdruecken, allerdings weniger
> effizient. Andererseits sind solche Maschinen und Applikationen, bei
> denen exakt das erforderlich ist, technisch ziemlich schwachbruestig, und
> eh kein Kandidat fuer C-Programmierung.
base64len = (4*len + 2)/3;
ist also nur für technisch schwachbrüstige Maschinen ...
> Und dann gibt es hirnverbrannte System-APIs, welche von geisteskranken
> Assemblerfreaks entworden wurden, welche den Fehlercode in folgender Form
> uebergeben:
>
> If Carry Clear:
> AX enthaelt den regulaeren Returnwert
> Else (Carry Set):
> AX enthaelt den Fehlerstatus
Das ist nicht geisteskrank sondern normale Out of Band Signalisierung.
Hirntot ist dagegen, einen undefinierten Bereich der Rückgabedomain für
Fehlercodes zu mißbrauchen.
Felix von Leitner
> Nein, Du siehst das völlig korrekt. C ist für hardwarenahe Programmierung
> ungeeignet.
Glücklicherweise wird Hardware nicht von bösartigen Marodeuren wie Lutz
gemacht, denen es vorrangig um die Beweisführung bei irgendwelchen
nervigen Language Wars geht, sondern von Ingenieuren, denen es vorrangig
darum geht, brauchbare Hardware zu entwickeln.
Felix
Nils Kassube
> Ich frage mich oefter, wozu C geeignet ist.
C-Kenntnisse braucht man, um Dokumentationen von Third-Party-
Libraries, Betriebssystem-APIs und ähnliches lesen zu können, damit
man dann von brauchbaren Sprachen darauf zugreifen kann.
Felix von Leitner
Ja. Gar nicht.
> wenn Du einen strukturierten Datentyp vergrößern willst. (calloc
> beachtet Alignments, wenn es passende Strukturgrößen bekommt)
Deine unzulässigen Vermutungen sind Kaffeesatzleserei vom Kirmes.
Mir ist noch kein calloc begegnet, das Alignment kaputt macht.
> > Die einzige zulaessige Folgerung ist hoechstens, dass C Programme unportabel
> > sind, aber das gilt fuer Ada[1] und Assembler gleichermassen.
> Nicht ganz. Ada weiß um die Alignments bei der Codegenerierung und bei
> Assembler weiß es der Programmierer.
Auch C benutzt Alignment. Wie es konkret aussieht, steht im ABI.
> > und ich dann doch wieder im Assembler-Output rumsuchen muss, warum das
> > Programm so fuerchterlich lahm daher gurkt. Intelligente Compiler, die
> > versuchen, meine Denkfehler zu korrigieren, sind unbrauchbar. You asked
> > for a crash, you got one.
> C gestattet Dir keinen definierten Crash, sondern falsche Ergebnisse.
Bullshit.
Lutz, warum läßt du dein unqualifiziertes Geseier nicht daheim oder an
der Uni oder wo auch immer man es dir eingeprügelt hat. Argumenten bist
du offensichtlich schon länger nicht mehr zugänglich, solange sie einen
Keil zwischen dich und dein dysfunktionales Ada treiben.
Ignatios Souvatzis
Patrick Piecha <pie...@micronas.com> writes:
> int main ( void ) {
> __asm {
> ...
> }
> return 0;
> }
Wenn schon, dann richtig.
short main[] = { ..., ..., ...
...
};
Mmm, IOCCC.
-is
Felix von Leitner
Nein. Er braucht es nur an einigen wenigen Stellen, gerade mal eine
Handvoll. Der Rest sind Performance-Überlegungen.
> Schau Dir einfach die Datenstrukturen an, die I/O Hardware erwartet:
> Alignment requirement ist hier typischerweise 2**16.
Unfug.
> Wie löst das der C-Freak?
> void * pc = malloc(0x20000l);
> void * realp = (void *)(((unsigned long)pc + 0xffff) & ~0xffffl);
Warum blubberst du hier eigentlich in der Gegend herum, wenn du
offensichtlich weder von dem Problem noch von der Lösung Ahnung hast?
Das ist ja unerträglich!
> Richtig?
Nein.
Der Quellcode zum Linux Kernel existiert. Lies ihn.
Felix von Leitner
> > Spezialinstruktionen der CPU involviert sind).
> Overflow und Carry Flags sind Spezialinstruktionen?
Ja. Nicht alle Architekturen haben sie.
Lutz, wieso gründest du nicht eine Ada-Advocacy Newsgroup?
Hier haben wir deine gesammtelten "Argumente" schon dutzende von Malen
gelesen und glaube mir: sie werden mit den Jahren nicht interessanter.