Fixed-width types

Nathan

Die Typedefs für int32_t und Co sind ja nur dann verfügbar, wenn es Typen dieser Größe gibt.
Gibt es irgendwelche relevanten Architekturen, bei denen die fixed Typedefs nicht verfügbar sind?
Und darüber hinaus: Gibt es irgendwelche relevanten Architekturen, bei denen floats nicht 32Bit groß sind bzw. double 64?
Und ja: Ich brauche die exakten Größengarantien, ein Workaround wird die Sache schon drastisch verkomplizieren.
Es wäre möglich, aber komplex, und bevor ich das schreibe, frag ich lieber nach.
Und nein: Es geht nicht um binäres Speichern von Daten, die interne Repräsentation ist wurscht, nur die Größen (und Alignment) müssen stimmen.

Marthog

Fuer welche Architekturen willst du denn entwickeln?
Bei normalen Anwendungen kann man ja davon ausgehen, dass man nur fuer x86 und ARM entwickelt und selbst z.B. PowerPC bereits Exot ist.

Es geht hier mehr darum, future-proof zu coden und die Anforderungen genau zu dokumentieren.

Stell dir vor, du hast ein paar Jahrzehnte altes Programm in dem überall int16_t verwendet weil es 16 Bit braucht (nehmen wir mal hypothetisch an int hätte weniger Bits garantiert). Das macht den heute Code unnötig langsam, weil 16 Bit emulieren langsam ist, sowie redundant und unschön weil überall die 16 steht.

Gleiches Problem hast du mit int32_t: Das mag auf einem zukünftigen 64-Bit-Prozessor langsamer sein als 64 Bit.

Schau dir alle Integer-Typen an: uintX_t für Modulo-Arithmetik. uint_leastX_t und int_leastX_t für Speicheroptimierung. (Wozu intX_t da ist weiss ich nicht. Wüsste nicht wo das Padding eine Rolle spielen sollte.)

Lösung sind typedefs. size_t für Grössen. int_fastXX_t für Berechnungen die eine Mindestgrösse erfordern.

using nint = int_fast32_t; // nint: Nathan's int

Von mir aus auch int32, auch wenn das mMn hässlich aussieht.

Wenn du gewisse Architekturen gar nicht unterstützen willst, kannst du auch ein

static_assert(std::numeric_limits<int>::min() >= 1ull<<31-1,
              "run sed -i 's/int/long long/g' to compile this program on your platform /s");

schreiben.

Nathan

Ich frage nur aus Neugier, die Plattformen hab ich noch gar nicht genau festgelegt.
Und es geht mir nicht um die Menge an Zahlen, die da reinpassen; nur um die Bitgröße.
Ich arbeite aktuell an einer Scriptsprache. Die wird offline in virtuellen, von mir designten Assemblercode compiliert und dann (evtl. auf einer anderen Plattform) in ei.er von mir entwickelten VM ausgeführt.
Adressen von Variablen werden einfach als Offset auf drm Stack angegeben und da ist das Problem: wenn mein uint32_t beim Compiler 32 Bit groß ist und beim Ausführer nicht mehr, sind alle Adrrssen falsch.
Ich kann da rum workarounden, indem der Compiler Zwischencode generiert, der keine Offsets verwendet u.d die dann beim Laden berechnet, aber das find ich nicht schön.
Deshalb frage ich, ob es irgendwelche relevanten Architekturen gibt, die das nicht anbieten.

Swordfish

Nathan schrieb:

Gibt es irgendwelche relevanten Architekturen, bei denen die fixed Typedefs nicht verfügbar sind?
Und darüber hinaus: Gibt es irgendwelche relevanten Architekturen, bei denen floats nicht 32Bit groß sind bzw. double 64?

Was (zum Teufel) sind die für Dich relevanten Architekturen!?

Marthog

Die Adresse muessen doch nicht absolut angegeben werden. Die lokalen Variablen koennen einfach mit Stackspitze - offset angegeben werden und da koennte man sich z.B. im Bytecode auf 16 bit beschraenken und kann dann halt nur maximal soundsoviele Variablen in einer Funktion addressieren (lua ist z.B. auf 200 lokale Variablen gecapped).

Nathan

Swordfish schrieb:

Nathan schrieb:

Gibt es irgendwelche relevanten Architekturen, bei denen die fixed Typedefs nicht verfügbar sind?
Und darüber hinaus: Gibt es irgendwelche relevanten Architekturen, bei denen floats nicht 32Bit groß sind bzw. double 64?

Was (zum Teufel) sind die für Dich relevanten Architekturen!?

Architekturen, die von einer größeren Menge an Menschen verwendet werden und ausreichend Power bieten, dass Scripting in Frage kommt.*
Darüber hinaus bin ich auch neugierig.

@Marthog:
Aber mit dem offset hab ich doch wieder das Problem der Größe!?

*Also nicht SeppJ's wasserbetriebener Bambusrechner.

TyRoXx

Nathan schrieb:

Ich arbeite aktuell an einer Scriptsprache. Die wird offline in virtuellen, von mir designten Assemblercode compiliert und dann (evtl. auf einer anderen Plattform) in ei.er von mir entwickelten VM ausgeführt.
Adressen von Variablen werden einfach als Offset auf drm Stack angegeben und da ist das Problem: wenn mein uint32_t beim Compiler 32 Bit groß ist und beim Ausführer nicht mehr, sind alle Adrrssen falsch.
Ich kann da rum workarounden, indem der Compiler Zwischencode generiert, der keine Offsets verwendet u.d die dann beim Laden berechnet, aber das find ich nicht schön.

Du musst konkreter werden. Ich habe keine Ahnung, was du damit meinst, dass uint32_t plötzlich nicht mehr 32 Bit haben könnte. Oder warum du unbedingt uint32_t verwenden willst, wenn du es eigentlich doch nicht willst wegen der Portabilität.

Poste einfach den Link zu deinem Code und stelle dann konkrete Fragen.

Columbo

Also nicht SeppJ's wasserbetriebener Bambusrechner.

Kein Wort gegen SeppJ's wasserbetriebenen Bambusrechner.

Swordfish

Nathan schrieb:

Swordfish schrieb:

Nathan schrieb:

Gibt es irgendwelche relevanten Architekturen, bei denen die fixed Typedefs nicht verfügbar sind?
Und darüber hinaus: Gibt es irgendwelche relevanten Architekturen, bei denen floats nicht 32Bit groß sind bzw. double 64?

Was (zum Teufel) sind die für Dich relevanten Architekturen!?

Architekturen, die von einer größeren Menge an Menschen verwendet werden und ausreichend Power bieten, dass Scripting in Frage kommt.

Gut. Dann sind wir bei x86, x86-64 und ARM ...

SeppJ

Arcoth schrieb:

Also nicht SeppJ's wasserbetriebener Bambusrechner.

Kein Wort gegen SeppJ's wasserbetriebenen Bambusrechner.

Die Idee kommt übrigens ursprünglich von volkard.

Nathan

TyRoXx schrieb:

Nathan schrieb:

Ich arbeite aktuell an einer Scriptsprache. Die wird offline in virtuellen, von mir designten Assemblercode compiliert und dann (evtl. auf einer anderen Plattform) in ei.er von mir entwickelten VM ausgeführt.
Adressen von Variablen werden einfach als Offset auf drm Stack angegeben und da ist das Problem: wenn mein uint32_t beim Compiler 32 Bit groß ist und beim Ausführer nicht mehr, sind alle Adrrssen falsch.
Ich kann da rum workarounden, indem der Compiler Zwischencode generiert, der keine Offsets verwendet u.d die dann beim Laden berechnet, aber das find ich nicht schön.

Du musst konkreter werden. Ich habe keine Ahnung, was du damit meinst, dass uint32_t plötzlich nicht mehr 32 Bit haben könnte. Oder warum du unbedingt uint32_t verwenden willst, wenn du es eigentlich doch nicht willst wegen der Portabilität.

Poste einfach den Link zu deinem Code und stelle dann konkrete Fragen.

Gut, das scheint dann doch mehr XY-Problem zu sein als ich dachte.
Also nehmen wir mal an ich unterstütze zwei Architekturen A und B. B bietet intxx_t nicht an, weswegen ich int_leastxx_t verwende.
Nun erzeuge ich auf Architektur A folgenden virtuellen Assemblercode:

push int32 1 // erzeuge ein int32 mit Wert 1; Offset 0, da Stack aligned.
push int32 2 // " mit Wert 2; offset 32
add int32 0 32 // addiere die beiden int32, einer an Adresse 0, der andere an Offset 32

Wenn ich diese Script nun auf B ausführe, wird höchstwahrscheinlich der zweite Offset falsch sein und das Programm nicht laufen.
Um das zu vermeiden, könnte ich im virtuellen Assemblercode die Typen bspw. indexieren, müsste dann aber beim Laden manuell die Offsets berechnen,
und das würd ich nur ungern machen.

@Swordfish:
Das heißt also ja, die sind verfügbar? Gut, danke.

@Arcoth/SeppJ:
Entschuldigung, nichts gegen volkards wasserbetriebenen Bambusrechner.

hustbaer

SeppJ schrieb:

Arcoth schrieb:

Also nicht SeppJ's wasserbetriebener Bambusrechner.

Kein Wort gegen SeppJ's wasserbetriebenen Bambusrechner.

Die Idee kommt übrigens ursprünglich von volkard.

Du hast nen wasserbetriebenen Bambusrechner? Zeig Bilder!

Marthog

Nathan schrieb:

Nun erzeuge ich auf Architektur A folgenden virtuellen Assemblercode:

push int32 1 // erzeuge ein int32 mit Wert 1; Offset 0, da Stack aligned.
push int32 2 // " mit Wert 2; offset 32
add int32 0 32 // addiere die beiden int32, einer an Adresse 0, der andere an Offset 32

Offset in bit angeben ist albern. Normalerweise verwendet man in richtigem Assembler byte und in Interpretern gibt man nur die Speicherzelle an und der Inhalt ist egal.

volkard

SeppJ schrieb:

Arcoth schrieb:

Also nicht SeppJ's wasserbetriebener Bambusrechner.

Kein Wort gegen SeppJ's wasserbetriebenen Bambusrechner.

Die Idee kommt übrigens ursprünglich von volkard.

Ich glaube eher, die Idee kommt von Bashar.