Typumwandlung: int -> char[4]

[groovemaster]

TactX schrieb:

Vertexwahn schrieb:

Ein int besteht aus sizeof(int) * 8 Bits

Ein char besteht aus sizeof(char) * 8 Bits

Nörgler würden sagen, dass ein char nicht zwingend aus 8 Bits besteht. Das betrifft aber nur absolute Exoten.

Naja, der Standard würde es eher so schreiben:
Ein int besteht aus 'sizeof(int) * CHAR_BIT' Bits.
Ein char besteht aus 'sizeof(char) * CHAR_BIT' bzw. 'CHAR_BIT' Bits.

Vertexwahn schrieb:

müsste man mal testen ob Shiften um 4 Bits schneller oder langsammer ist als die Multiplikation mit 16

Sehr unwahrscheinlich, dass Shiften langsamer ist, vielleicht auf irgendwelchen Exoten.

Vertexwahn schrieb:

Angenommen ein int ist 32 Bit groß und ein char 8 Bit – dann werden die Bits 32 bis 9 vom Integer verworfen und nur die Bits von 8 bis 0 in den char übertragen

Nicht ganz. Da int hier nur 32 Bits hat, wird ein gängiger Prozessor Bit 0 bis 7 ins char kopieren und Bit 8 bis 31 verwerfen. Abhängig davon, ob char signed oder unsigned ist, werden noch entsprechende Anpassungen vorgenommen.

@Vertexwahn
Könntest du dir mal bitte angewöhnen, ordentlich zu quoten?

[Vertexwahn]

C99:

Values stored in non-bit-field objects of any other object type consist of n * CHAR_BIT bits, where n is the size of an object of that type, in bytes.

Ich dachte eine Byte hat immer 8 Bit

Könntest du dir mal bitte angewöhnen, ordentlich zu quoten?

ich versuchs - wie ersetze ich "Zitat" durch einen Namen?

[Gast]

groovemaster schrieb:

Vertexwahn schrieb:

müsste man mal testen ob Shiften um 4 Bits schneller oder langsammer ist als die Multiplikation mit 16

Sehr unwahrscheinlich, dass Shiften langsamer ist, vielleicht auf irgendwelchen Exoten.

Der P4 ist ein Exot?

Der P4 hat keinen Barrel Shifter. Viele Leute sagen, dass er auch deswegen so lahm ist...

[groovemaster]

Vertexwahn schrieb:

ich versuchs - wie ersetze ich "Zitat" durch einen Namen?

Indem du in das Editfeld hinter dem Quote Button einen Namen reinschreibst.

TactX schrieb:

Der P4 hat keinen Barrel Shifter. Viele Leute sagen, dass er auch deswegen so lahm ist...

Whoa, das hört sich ja ziemlich übel an. Naja, dazu kann ich leider nix sagen, weil ich meinen letzten Pentium '00 zu Grabe getragen hab. Aber normalerweise sollte sich Shiften auf Hardwareebene schon schneller realisieren lassen wie Multiplikationen, oder zumindest nicht langsamer.

[Gast]

groovemaster schrieb:

TactX schrieb:

Der P4 hat keinen Barrel Shifter. Viele Leute sagen, dass er auch deswegen so lahm ist...

Whoa, das hört sich ja ziemlich übel an. Naja, dazu kann ich leider nix sagen, weil ich meinen letzten Pentium '00 zu Grabe getragen hab. Aber normalerweise sollte sich Shiften auf Hardwareebene schon schneller realisieren lassen wie Multiplikationen, oder zumindest nicht langsamer.

Google mal nach "p4 barrel shifter". Kommen einige Links dazu. Auf die Gefahr, dass das jetzt zu sehr OT wird, aber intel sollte die P4-Kacke endlich einstampfen...

[Vertexwahn]

groovemaster schrieb: schrieb:

Whoa, das hört sich ja ziemlich übel an. Naja, dazu kann ich leider nix sagen, weil ich meinen letzten Pentium '00 zu Grabe getragen hab. Aber normalerweise sollte sich Shiften auf Hardwareebene schon schneller realisieren lassen wie Multiplikationen, oder zumindest nicht langsamer.

Früher war es in Programmiererkreisen üblich, Ganzzahlmultiplikationen mit 2 bzw. Ganzzahldivisionen durch 2 mit Hilfe der entsprechenden Shift-Operationen durchzuführen, da dies einen kleinen Performancegewinn im Vergleich zur "echten" mathematischen Operation darstellte. Heutzutage ist dieser Performancegewinn nicht mehr vorhanden, da alle
derzeitigen Architekturen auf solche Operationen optimiert sind. Aus Gründen der Leserlichkeit sollte man also heutzutage nicht mehr auf diese Art der trickreichen Programmierung zurückgreifen. Darüber hinaus optimiert der Compiler in den meisten Fällen solche Dinge automatisch.

[groovemaster]

Vertexwahn schrieb:

Darüber hinaus optimiert der Compiler in den meisten Fällen solche Dinge automatisch.

Das ist schon klar. Ist auch der Hauptgrund, warum man auf solche Shift Tricks heutzutage verzichten kann.
Nur sind die CPU's heutzutage wirklich so effizient? Hab leider nur einen "alten" Athlon Barton, und weiss, dass dort Multiplikationen sehr schnell sind. Aber schneller oder zumindest genauso schnell wie Shifts? Hört sich zumindest ungewohnt an. Aber das ist jetzt zu sehr OT.

[Gast]

Vielleicht hilft dir folgende Funktion welche ich mal geschrieben habe:
(ich verstehe jetzt nicht ganz den Unterschied zwischen char[4] und String, hab jetzt auch nicht das komplette Topic gelesen, aber vielleicht nutzt dir der Code ja trotzdem was)

unsigned char *int_to_ascii(int punkte)
{
	static unsigned char temp[4]={'\0','\0','\0', '\0'};
  //punkte darf maximal 3stellen haben

  if(((punkte-punkte%100)/100)!=0 )
	 temp[0]=((punkte-punkte%100)/100)+'0';	
	else
	 temp[0]=' ';

	if((((punkte%100-punkte%10)/10)!=0) || (temp[0]!=' ') )
   temp[1]=((punkte%100-punkte%10)/10)+'0';
  else
   temp[1]=' ';

  if((punkte%10)!=0 || (temp[1]!=' ') )
	 temp[2]=(punkte%10)+'0';
	else
	 temp[2]=' ';  

	temp[3]='\0';

	return temp;
}

Grüße,
Harri

[groovemaster]

DailyWTF?

harry3 schrieb:

hab jetzt auch nicht das komplette Topic gelesen

Wäre aber vielleicht besser gewesen.

[Vertexwahn]

@harry3:

Deine Funktion wandelt die letzten vier stellen einer int Zahl in einen "String" um - das war nicht gesucht und bringt den fragenden nicht weiter

harry3 schrieb:

temp[0]=((punkte-punkte%100)/100)+'0';

das funktioniert zwar auf den meisten Rechnern ist, aber nicht besonders schön - ich will dir ja nicht viel zu programmierstill sagen - aber für größere Projekte (z. B. kleine Computerspiele) solltest du erst ein wenig etwas über allgemeine Prinzipien von Softwareentwicklung lernen - macht sich später vielleicht einmal bezahlt

[net 0]

Vertexwahn schrieb:

Deine Funktion wandelt die letzten vier stellen einer int Zahl in einen "String" um - das war nicht gesucht und bringt den fragenden nicht weiter

ausserdem gibts 'itoa' und 'sprintf'....

[Gast]

groovemaster schrieb:

DailyWTF?

harry3 schrieb:

hab jetzt auch nicht das komplette Topic gelesen

Wäre aber vielleicht besser gewesen.

Aus dem ersten Beitrag ist nicht gerade gut herauslesbar gewesen, was wirklich gewünscht ist.
Und man kann nicht verlangen, dass man 2 Seiten liest und erst dann postet.
Deshalb hab ich auch dazugeschrieben dass ich mir nicht sicher bin. (also KEEP COOL, nicht gleich wegen jedem Blödsinn aufregen wenns denn gut gemein ist :p )

@Vertexwahn: Was würdest du vorschlagen um den Code optisch aufzupeppen?
Allerdings sollte er gleichschnell bleiben und gleich klein(im Speicher), also keine Schleifen etc.(mit zusätzlichen Variablen) einbauen!!!(ist nämlich nicht für einen PC geschrieben->wenig Speicher, wenig Power).

@net: Aufm PC schon, aber nicht für das Kastl(Texas Instruments 200), für den ich programmiere.
sprintf() gäbs zwar schon, aber das braucht knapp 100byte an Speicher!!! Während meine Funktion wohl nur ein paar bytes braucht. Warm ich um jedes byte kämpfe? Siehe oben!

Grüße,
Harri

[Vertexwahn]

harry3 schrieb:

@Vertexwahn: Was würdest du vorschlagen um den Code optisch aufzupeppen?

Konsequentes Einrücken
ich konnte ja nicht wissen das du auf einer Umgebung arbeitest, die nicht den vollen sprachumfang unterstützt und das du versuchst auf geschwindigkeit zu optimieren und nicht auf sauberen, wartbaren code

harry3 schrieb:

Und man kann nicht verlangen, dass man 2 Seiten liest und erst dann postet

doch - kann man - ansonsten könnte es ja passieren, dass man glatt am problem vorbeiredet

[Gast]

Sie unterstützt schon fast den gesamten Sprachumfang von Ansi C, aber das problem ist eben, das viele C-typische Befehle zwar nutzbar sind, aber eben langsam sind und vor allem viel Speicher brauchen.

Wegen den Zeileneinrückungen: In der IDE passts, aber scheinbar übernimmt das Forum die Tabs nicht 1:1 von dem IDE Text-Editor.

doch - kann man - ansonsten könnte es ja passieren, dass man glatt am problem vorbeiredet

Ja, kann man, aber ich hab gestern noch einiges zu tun gehabt, und ich dachte ich stell mal schnell den Code online, vielleicht hilfts ja, und wenn nicht, naja, kann man ja auch drüber hinwegsehen. War ja gut gemeint.

Nur keine Angst, ansonsten lese ich schon wenn möglich alles.

Grüße,
Harri

[net 0]

harry3 schrieb:

@net:
sprintf() gäbs zwar schon, aber das braucht knapp 100byte an Speicher!!!

das ist aber ein sparsames printf
biste sicher das das nicht irgendwo im rom steckt?

[Gast]

Hab gerade "nachgemessen": printf("") braucht doch ganze 206bytes.(ist aber für PC Verhältnisse immer noch winzig)
Der Compiler optimiert sehr gut in Bezug auf Größe, mein Spiel "Memory" hat z.B. nur knapp 5kbytes. Das ist sehr klein, allerdings ist das auch notwendig bei einer RAM Größe von 256kb und einem Archivspeicher von 2.5mb, wovon 1.5mb nutzbar sind.

Im ROM ist printf nicht vorhanden. Der TI200 hat im Rom primitivere Funktionen gespeichert, wie z.B. DrawStr(...) um Strings auszugeben oder DrawChar(...) für ein einzelnes Zeichen.

Die printf Funktion ist erst aus den verschiedenen Rom-Funktionen zusammengebastelt worden.
Wenn man nun nur eine einfache Aufgabe zu lösen hat, so ist es besser, man verwendet eine eigene Funktion als (s)printf(), weil man damit doch sehr viel Speicher spart.

Wenns interessiert: http://tigcc.ticalc.org/

Grüße,
Harri

[groovemaster]

harry3 schrieb:

Aus dem ersten Beitrag ist nicht gerade gut herauslesbar gewesen, was wirklich gewünscht ist.

Tja, dann hättest du einfach mal 2 Beiträge weiterlesen sollen.

harry3 schrieb:

Und man kann nicht verlangen, dass man 2 Seiten liest und erst dann postet.

Doch, entweder man postet ontopic oder lässt es bleiben. Und du musst auch nicht alles im Detail durchlesen, aber zumindest überfliegen sollte schon drin sein.

harry3 schrieb:

also KEEP COOL, nicht gleich wegen jedem Blödsinn aufregen

Keine Sorge, mach ich schon nicht.

harry3 schrieb:

Allerdings sollte er gleichschnell bleiben und gleich klein(im Speicher), also keine Schleifen etc.

Klein und Schleifen stehen aber grundsätzlich in keinem Widerspruch zueinander.

harry3 schrieb:

sprintf() gäbs zwar schon, aber das braucht knapp 100byte an Speicher!!!

harry3 schrieb:

Hab gerade "nachgemessen": printf("") braucht doch ganze 206bytes.

Hehe, sehr schön. Mit Sicherheit sind das aber keine Implementationen, die die volle Funktionalität unterstützen. Und was hast du da eigentlich gemessen? Die Funktion selber? Was ist mit den ganzen Funktionen, die in ...printf() aufgerufen werden?

[Gast]

@groovemaster :
Klein und Schleifen stehen aber grundsätzlich in keinem Widerspruch zueinander.

Ich habs zwar jetzt nicht ausprobiert, aber ich glaube, dass eine Schleife etwas mehr Speicher braucht. Man braucht nämlich im Gegensatz zu meiner Variante mindestens 1 Laufvariable, und dann noch eine Bedingung fürn Schleifenabbruch.

Hehe, sehr schön. Mit Sicherheit sind das aber keine Implementationen, die die volle Funktionalität unterstützen. Und was hast du da eigentlich gemessen? Die Funktion selber? Was ist mit den ganzen Funktionen, die in ...printf() aufgerufen werden?*

Die volle Funktionalität wird eh nicht unterstützt. Aus dem Manual:
"printf is nearly full implementation of standard ANSI C printf function, which sends the formatted output to the screen in terminal (TTY) mode. In fact, it does the following: ..."
Das einzige, was soweit ich weiß nicht vorhanden ist, sind Streams(stdout, stdin, stderr) und all damit verbundenen Dinge.

Wegen der Größe:
Ich hab einmal ein Programm ohne Inhalt geschrieben:

#include <tigcclib.h>

// Main Function
void _main(void)//keine Sorge, beim TI ist die _main Fkt. wirklich void!!!
{
	//hier geschieht nix
}

Und einmal mit printf:

#include <tigcclib.h>

// Main Function
void _main(void)
{
	printf("");
}

Der Unterschied der Größen beträgt 206byte. Dies sollte also die Größe von printf darstellen.

Grüße,
Harri

[groovemaster]

harry3 schrieb:

Ich habs zwar jetzt nicht ausprobiert, aber ich glaube, dass eine Schleife etwas mehr Speicher braucht.

Glauben und wissen sind immer noch zwei Sachen. Grundsätzlich verkürzen Schleifen die Schreibarbeit und damit auch die Codegrösse. Sie wirken sich eher negativ auf die Laufzeit aus. Ohne genau zu messen, kannst du bei so kleinen Sachen nichts konkretes sagen. Und du darfst nicht vergessen, dass ein Compiler auch in der Lage ist zu optimieren. So muss für eine Laufvariable kein zusätzlicher Speicher benötigt werden. Genauso gut kann diese in einem Register gehalten werden. Und selbst mit zusätzlichem Speicher - der ist lokal und liegt damit vermutlich auf dem Stack. Und der steht nach dem Verlassen der Funktion 'eh wieder zur Verfügung.

harry3 schrieb:

Das einzige, was soweit ich weiß nicht vorhanden ist, sind Streams(stdout, stdin, stderr) und all damit verbundenen Dinge.

Das versteh ich nicht. Du hast printf aber keine Streams?

C Standard schrieb:

The printf function is equivalent to fprintf with the argument stdout interposed
before the arguments to printf.

stdout muss es in irgendeiner Form dann doch geben.

harry3 schrieb:

Und einmal mit printf:

#include <tigcclib.h>

// Main Function
void _main(void)
{
	printf("");
}

Der Unterschied der Größen beträgt 206byte. Dies sollte also die Größe von printf darstellen.

So kannst du die Grösse aber nicht bestimmen. Mal abgesehen davon, dass du hier noch den Code beachten musst, der beim Aufruf in main entsteht (Parameterübergabe, Stackhandling, etc.), weisst du trotzdem nicht, was zu printf gehört und was nicht.

[Gast]

Das versteh ich nicht. Du hast printf aber keine Streams?

Standardein/ausgabe Kanäle meinte ich. Ich verwechsle das Wort immer mit Streams...obwohl das AFAIK C++ ist.(bin kein c++er, also korrigiert mich wenns nicht stimmt)

stdout muss es in irgendeiner Form dann doch geben.
*

Nicht so wie man es z.B. von Turbo C++ oder so gewohnt ist. Man kann also nicht die Ausgabekanäle ändern.
stdout,-in,-err ist laut Entwicklern nicht dabei.

So kannst du die Grösse aber nicht bestimmen. Mal abgesehen davon, dass du hier noch den Code beachten musst, der beim Aufruf in main entsteht (Parameterübergabe, Stackhandling, etc.), weisst du trotzdem nicht, was zu printf gehört und was nicht.

Es ist mir auch egal ob die Funktion jetzt 206 oder 210 bytes hat. Was ich weiß ist dass die Funktion riesig im Vergleich zu DrawStr ist, und ich sie daher nicht verwende.
Wird sogar von den Entwicklern empfohlen auf printf zu verzichten, v.a. bei einfachen Texten!

*Glauben und wissen sind immer noch zwei Sachen. Grundsätzlich verkürzen Schleifen die Schreibarbeit und damit auch die Codegrösse. Sie wirken sich eher negativ auf die Laufzeit aus. Ohne genau zu messen, kannst du bei so kleinen Sachen nichts konkretes sagen. Und du darfst nicht vergessen, dass ein Compiler auch in der Lage ist zu optimieren. So muss für eine Laufvariable kein zusätzlicher Speicher benötigt werden. Genauso gut kann diese in einem Register gehalten werden. Und selbst mit zusätzlichem Speicher - der ist lokal und liegt damit vermutlich auf dem Stack. Und der steht nach dem Verlassen der Funktion 'eh wieder zur Verfügung.
*

So viel kürzer ist die Schreibarbeit nicht, dafür ist d. Programm jetzt um ca. 100bytes größer als zuerst.(unter anderem auch deswegen, weil ich pow() verwenden muss. Ich werd morgen mal probieren das ganze ohne dem pow() zu machen um einen wirkluchen Vergleichswert zu haben.
Allerdings traue ich mich zu wetten dass die Schleifenversion trotzdem größer ist.
Ich belasse es also bei meinem Code, der ist klein und außerdem auch nicht so wahnsinnig aufwendig.

Grüße,
Harri