www.mikrocontroller.net

Forum: Compiler & IDEs Was genau ist UL?


Autor: Daniel Schillinger (enton)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute

Muss euch leider schon wieder nerven.
Hab hier im Forum gelesen, das UL für unsigned Long steht. Leider hab 
ich nirgends gefunden, wie ein unsigned long definiert ist. Nun meine 
Fragen:

1) Wie ist ein unsigned long definiert( wie viele Stellen hat er)?
2) Wo kann ich so was nachlesen
3) Bei dem Beispiel,das ich gesehen hatte, wurde an die Konstanten bei 
einer Rechnung mit uint32_t das UL angehängt, gilt das auch für 
Rechnungen mit uint64_t oder muss man dort was anderes anhängen, weil 
unsigned long zu klein ist( keine 20 Stellen hat)?

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du solltest genauer angeben welchen Compiler bzw welchen Controller du 
meinst. Long ist nicht gleich Long. Je nach System kann Long 32 oder 64 
Bit groß sein.

Weder Integer noch Long oder Word sind in ihrer Größe fest definiert

Autor: RyouArashi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1.)
Der Datentyp "long" ist normalerweise ein Integer mit 32bit.
(Zahlen von 0 - 4.2nochwas*10^9)
"unsigned" heißt "ohne Vorzeichen", d.h. nur positive Zahlen und die 
Null.

3.)
UL noch einer Konstante kennzeichnet den Datentyp als "unsigned long".
"10UL" sollte gleichbedeutend sein mit "(unsigned long)10".
Bei 64bit-Integern würde ich vermuten, dass man ein "LL" bzw. "ULL"
anhängen muss, (z.B. "10ULL")

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau dir vielleicht die Includedatei stdint.h bei deiner 
Compiler-Toolchain an. Darin stehen Makros für die maximalen und 
minimalen Zahlen der ZahlenTypen.

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus wrote:
> Weder Integer noch Long oder Word sind in ihrer Größe fest definiert

Allerings gibt es Mindestlängen im Standard: short und int sind 
mindestens 16, long mindestens 32 Bit lang.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Detlev T. (detlevt)

>> Weder Integer noch Long oder Word sind in ihrer Größe fest definiert

Was eine Glanzleistung der Informatik war . . . :-(

>Allerings gibt es Mindestlängen im Standard: short und int sind
>mindestens 16, long mindestens 32 Bit lang.

Ich nutze auf uCs nur intXX_t, da weiss man was man hat.

MFG
Falk

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
>>> Weder Integer noch Long oder Word sind in ihrer Größe fest definiert
>
> Was eine Glanzleistung der Informatik war . . . :-(

Wieso diese Ironie? Das Ganze bekommt dann einen Sinn, wenn man an die 
Sourcecode-Portabilität von C-Code denkt. Das gibt dem Compiler mehr 
Freiheit, einen an das jeweilige System angepassten Code zu erzeugen.

Stelle dir einmal vor, man hätte damals die Länge von int zwingend auf 
die Registerlänge einer PDP-1 festgelegt. Das waren 18 Bit. Das müsste 
heute auf 32- und 64-Bit Rechnern leistungszehrend emuliert werden. In 
Hinblick auf die Zukunft ist es häufig besser, nicht immer alles 
festlegen zu wollen.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Detlev T. (detlevt)

>> Was eine Glanzleistung der Informatik war . . . :-(

>Wieso diese Ironie? Das Ganze bekommt dann einen Sinn, wenn man an die
>Sourcecode-Portabilität von C-Code denkt. Das gibt dem Compiler mehr
>Freiheit, einen an das jeweilige System angepassten Code zu erzeugen.

Und was ist mit den Problemen/Seiteneffekten, die aus diesem Ansatz 
entstehen?

>Stelle dir einmal vor, man hätte damals die Länge von int zwingend auf
>die Registerlänge einer PDP-1 festgelegt. Das waren 18 Bit. Das müsste

Naja, das hätte sich auch irgendwann mal sinnvoll eingependet, auf dem 
heute gültigen 8er Schema.

>Hinblick auf die Zukunft ist es häufig besser, nicht immer alles
>festlegen zu wollen.

Aber solche schwammigen Definitionen machen allzuoft auch mehr Probleme 
als sie lösen. Und warum hat man die Fliesskommazahlen sauber und fest 
definiert, Integer aber nicht?

MFG
Falk

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:

> Und was ist mit den Problemen/Seiteneffekten, die aus diesem Ansatz
> entstehen?

Welche?

>>Stelle dir einmal vor, man hätte damals die Länge von int zwingend auf
>>die Registerlänge einer PDP-1 festgelegt. Das waren 18 Bit. Das müsste
>
> Naja, das hätte sich auch irgendwann mal sinnvoll eingependet, auf dem
> heute gültigen 8er Schema.

Eben nicht! Das wäre dann ja nicht mehr möglich gewesen.

>>Hinblick auf die Zukunft ist es häufig besser, nicht immer alles
>>festlegen zu wollen.
>
> Aber solche schwammigen Definitionen machen allzuoft auch mehr Probleme
> als sie lösen. Und warum hat man die Fliesskommazahlen sauber und fest
> definiert, Integer aber nicht?

Welche? Und auch bei Gleitkommazahlen war nicht immer von Anfang an 
alles "sauber und fest definiert": Guckst du hier:
http://home.earthlink.net/~mrob/pub/math/floatformats.html

Und selbst die IEEE 754 Norm,auf die du dich wahrscheinlich beziehst, 
definiert "extended"-Formate, die lediglich die Mindestbitzahl 
vorschreiben. Guckst du hier:
http://de.wikipedia.org/wiki/IEEE_754#Zahlenformat...

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich nutze auf uCs nur intXX_t, da weiss man was man hat.

Wenn man direkt mit Hardware-Registern arbeitet, ist das auf jeden Fall 
sinnvoll. Aber sonst bieten sich eher die int_fastXX_t oder 
int_leastXX_t an. Diese sind die schnellsten bzw. kleinsten Typen, die 
noch mindestens so viele Bits haben, wie angegeben. Damit schränkt man 
es nicht auf eine feste Bitzahl ein, sondern auf das, was groß genug und 
trotzdem für den Anwendungsfall optimal ist - die fast-Typen, wenn man 
möglichst schnellen Code will, die least-Typen, wenn man Platz sparen 
muß.

>>Stelle dir einmal vor, man hätte damals die Länge von int zwingend auf
>>die Registerlänge einer PDP-1 festgelegt. Das waren 18 Bit. Das müsste
>
> Naja, das hätte sich auch irgendwann mal sinnvoll eingependet, auf dem
> heute gültigen 8er Schema.

Und doch hat sich diese Definition immer noch als zu restriktiv 
erwiesen. Eigentlich sollte int der native Typ der Architektur sein, 
also z.B. 16 Bits auf einen 16-Bit-Prozessor, 32 Bits auf einem 
32-Bit-Prozessor. Auf 8-Bit-Prozessoren darf er aber nicht 8 Bits breit 
sein, da er auf mindestens 16 Bits eingeschränkt ist. Auf 
64-Bit-Systemen ist er meistens auch nicht 64 Bits breit, da nur char 
und short kleiner sein dürfen und das nicht ausreicht für 8-, 16- und 32 
Bit-Typen.
Es gibt auch DSPs, die nur mit vielfachen von 24 Bits umgehen können. 
Wer würde denn einen Compiler benutzen, der darauf dann umständliche und 
langsame 8-, 16- und 32-Bit-Typen anbietet, aber eben nicht die 
optimialen mit 24 oder 48 Bits?

>Hinblick auf die Zukunft ist es häufig besser, nicht immer alles
>festlegen zu wollen.

Ack.

> Aber solche schwammigen Definitionen machen allzuoft auch mehr Probleme
> als sie lösen.

Zu enge Festlegungen machen in der Regel viel mehr Probleme. Es gibt 
sehr viele Hard- und Software-Spezifikationen, bei denen nachträgtlich 
mit unglaublich üblen Tricks gearbeitet wird, um die bei der 
ursprünglichen Definition festgelegten Enschränkungen zu umgehen.

> Und warum hat man die Fliesskommazahlen sauber und fest definiert,
> Integer aber nicht?

Wie kommst du darauf, daß das der Fall sei?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Detlev T. (detlevt)

>> Und was ist mit den Problemen/Seiteneffekten, die aus diesem Ansatz
>> entstehen?

>Welche?

Wenn man z.B. ein Array von int nutzt, hat das mal 2*N und mal 4*N bytes 
Speicherplatz. Was bei bestimmten Portierungen zu Problemen führt, vor 
allem auf kleinen uCs. Oder wenn ich irgendwelche feste Structs brauche, 
z.B. um Sektoren eines FATs abzubilden. etc.

>Eben nicht! Das wäre dann ja nicht mehr möglich gewesen.

Wieso? Weil PDP-11 der unumstössliche Standard ist? C'mon.

>Welche? Und auch bei Gleitkommazahlen war nicht immer von Anfang an
>alles "sauber und fest definiert": Guckst du hier:
>http://home.earthlink.net/~mrob/pub/math/floatformats.html

Mag sein, mittlerweil ist es AFAIK aber schon recht klar definiert, 
oder?
32/64/80 Bit Float.

@ Rolf Magnus (Gast)

>> Ich nutze auf uCs nur intXX_t, da weiss man was man hat.

>Wenn man direkt mit Hardware-Registern arbeitet, ist das auf jeden Fall
>sinnvoll. Aber sonst bieten sich eher die int_fastXX_t oder

Nicht nur dort, auch für Variablen.

>trotzdem für den Anwendungsfall optimal ist - die fast-Typen, wenn man
>möglichst schnellen Code will, die least-Typen, wenn man Platz sparen
>muß.

Na mal ehrlich, sind diese Fast-Typen WIRKLICH schneller als "normale" 
intxx_t oder ist das eher akademische Spielerei?

>Und doch hat sich diese Definition immer noch als zu restriktiv
>erwiesen.

???
Verstehe ich nicht.
Wenn ich ein Programm schreibe, dann überlege ich mir, welche Zahlen 
verarbeitet werden müssen und wähle entsprechende Datentypen. Warum in 
aller Welt müssen die dann so schwammig definiert sein? Ein Byte ist ein 
Byte ist ein Byte, egal auf welcher Machine. Dito mit 32 Bit Werten. Und 
damit ist auch das logische Verhalten vollkommen maschinenunabhängig. 
Dass ein 8-bitter bei 32 Bit nicht so flott wie ein 32 Bitter ist ist 
dabei vollkommen logisch und auch egal.

>Es gibt auch DSPs, die nur mit vielfachen von 24 Bits umgehen können.

Ausnahmen. Als C entwickelt wurde war an DSPs noch nie und nimmer zu 
denken.

>Wer würde denn einen Compiler benutzen, der darauf dann umständliche und
>langsame 8-, 16- und 32-Bit-Typen anbietet, aber eben nicht die
>optimialen mit 24 oder 48 Bits?

So ein Code ist meist wenig portabel, da kann man sich auch einen 
int24_t vorstellen.

>> Aber solche schwammigen Definitionen machen allzuoft auch mehr Probleme
>> als sie lösen.

>Zu enge Festlegungen machen in der Regel viel mehr Probleme.

Naja, hier wirds philosophisch. Schau dir mal an, was die ganzen 
"offenen" Standards an "schönen" Dingen so mitbringen. Wenn da nicht 
bissel ne straffe Hand (=Standard) regiert, wird Larifari draus.

>sehr viele Hard- und Software-Spezifikationen, bei denen nachträgtlich
>mit unglaublich üblen Tricks gearbeitet wird, um die bei der
>ursprünglichen Definition festgelegten Enschränkungen zu umgehen.

Das ist ein GANZ anderes Thema. Wenn ich was übermässig aufbohren will 
passiert sowas nun mal. Und die heilige Kuh der Abwärtskompatibilität 
muss halt ab und zu dran glauben.

>> Und warum hat man die Fliesskommazahlen sauber und fest definiert,
>> Integer aber nicht?

>Wie kommst du darauf, daß das der Fall sei?

Hab ich in meiner jugendlichen Naivität mal so angenommen, dass 32/64/80 
Bit Floats in C recht klar standardisiert sind. ;-)

MFG
Falk

P.S. Man erinnere sich an die Zeit in Deutschland, als Kleinstaaterei 
gross geschrieben wurde (ist ja teilweise noch heute so, nennst sich nur 
P.C. Förderalismus). Dutzende Masse und Gewichte, etc. P.P. Die 
Vereinheitlichung , später S.I. waren da ein Segen. (Jaja, Äpfel und 
Birnen)

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
 > Wenn man z.B. ein Array von int nutzt, hat das mal 2*N und mal 4*N 
bytes
> Speicherplatz. Was bei bestimmten Portierungen zu Problemen führt, vor
> allem auf kleinen uCs. Oder wenn ich irgendwelche feste Structs brauche,
> z.B. um Sektoren eines FATs abzubilden. etc.

Das ist ziemlich philosophisch. Denn diese Probleme treten ja dann auf, 
wenn man nicht portablen Code portiert, bei dem man z.B sich auf 
int=16Bit verlässt, was der Standard nicht garantiert. Wer ist dann 
Schuld, der Standard oder der Programmierer? Man muss sich in solchen 
Fällen auf jedem System halt eine Umgebung mit Typendefinitionen 
schaffen, wo die Bit-Längen garantiert sind. Das ist möglich, ohne dass 
dies bei den Standard(!)-Typen   sein muss. Genau dafür gibt es ja 
MAX_INT etc, wo man das überprüfen kann.

>>Eben nicht! Das wäre dann ja nicht mehr möglich gewesen.
>
> Wieso? Weil PDP-11 der unumstössliche Standard ist? C'mon.

Nein, weil 18-Bit dann der Standard gewesen wäre. Wie willst du das 
nachträglich ändern? Jeder Compiler, der das anders handhabt, wäre nicht 
mehr standard-konform und würde daher nicht benutzt. Schon mal vom 
A20-Gate gehört? 
(http://de.wikipedia.org/wiki/A20-Gate#Zukunft_des_A20-Gates) Selbst die 
allermodernsten x86-Prozessoren haben es noch, um standard-konform zu 
sein. Dabei wäre das AFAIK nur nötig, wenn jemand damit MS-DOS 1.0 
benutzen wollte. Blödsinnig, aber einmal so festgelegt.

> Dass ein 8-bitter bei 32 Bit nicht so flott wie ein 32 Bitter ist ist
> dabei vollkommen logisch und auch egal.

Umgekehrt sind aber viele 32-Bitter bei 8- & 16-Bit nicht so flott wie 
bei 32-Bit (Stichwort Busbreite, Missalignment). Deshalb hat man es ja 
gerade dem Compiler überlassen, die für diese Umgebung passende 
Bit-Länge auszuwählen, und nur Mindestwerte für die Standardtypen 
vorgegeben. Es steht dir ja frei, deine eigenen Typen zu definieren, die 
auf allen Systemen, mit denen du zu tun hast, die gleiche Größe haben. 
Das muss deswegen ja nicht Teil des Standards sein.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Eben nicht! Das wäre dann ja nicht mehr möglich gewesen.
>
> Wieso? Weil PDP-11 der unumstössliche Standard ist? C'mon.

Nein, aber als C definiert wurde, wußte man nicht, was mal der 
unumstößliche Standard wird bzw. ob es überhaupt jemals einen geben 
würde.

>>trotzdem für den Anwendungsfall optimal ist - die fast-Typen, wenn man
>>möglichst schnellen Code will, die least-Typen, wenn man Platz sparen
>>muß.
>
> Na mal ehrlich, sind diese Fast-Typen WIRKLICH schneller als "normale"
> intxx_t oder ist das eher akademische Spielerei?

Sie sind wie die intXX_t auch einfach nur typedefs auf die eigentlichen 
Integer-Typen.
Die Idee, zu sagen, daß int der native Typ sein sollte, war, daß man 
dann einfach int nehmen kann, und es wird der Typ verwendet, der auf der 
Plattform am effizientesten ist. Meistens braucht man aber doch einen 
gewissen mindest-Wertebereich. Dazu sind dann die fast- und least-Typen 
da. Man braucht eigentlich selten einen Typ mit exakt 16 Bits. Meistens 
tut es einer, der nur mindestens soviele Bits hat. Und z.B. auf dem x86 
im 32-Bit-Modus ist ein 32-Bit-Zugriff tatsächlich schneller als einer 
mit 16 Bits.

>>Und doch hat sich diese Definition immer noch als zu restriktiv
>>erwiesen.
>
>???
> Verstehe ich nicht.

Hättest nur meine weitere Erklärung dazu lesen müssen.

>>Es gibt auch DSPs, die nur mit vielfachen von 24 Bits umgehen können.
>
> Ausnahmen. Als C entwickelt wurde war an DSPs noch nie und nimmer zu
> denken.

Ja eben, das ist genau das, was ich meine. Damit C universell bleibt und 
auch auf Plattformen implementiert werden kann, an die man zum Zeitpunkt 
der Definition noch gar nicht denken konnte, darf man diese Definition 
nicht zu restriktiv machen.

>>Wer würde denn einen Compiler benutzen, der darauf dann umständliche
>>und langsame 8-, 16- und 32-Bit-Typen anbietet, aber eben nicht die
>>optimialen mit 24 oder 48 Bits?
>
> So ein Code ist meist wenig portabel, da kann man sich auch einen
> int24_t vorstellen.

Manche Teile können schon portabel sein.

> Hab ich in meiner jugendlichen Naivität mal so angenommen, dass
> 32/64/80 Bit Floats in C recht klar standardisiert sind. ;-)

Nein. Es gibt auch hier nur Mindestanforderungen. float muß mindestens 6 
Dezimalstellen korrekt darstellen können, double und long double 10. Und 
80 Bits für long double sind z.B. schon unter Windows nicht üblich. Da 
sind double und long double beide 64 Bit breit. Unter Linux auf dem PC 
ist long double 128 Bit breit, benutzt aber nur 80 Bits davon für die 
Wertrepräsentation.

Autor: Daniel Schillinger (enton)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für alle die es interresiert: Bei uint64_t muss man bei der Konstanten 
ULL anhängen( Bei AVR GCC).

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.