Hexadezimal in Dezimal --> X2D

[Kampi4]

Ach so, das ist ja interresant.

Wie kann ich den Code denn jetzt änder, dass es auf Intel Maschinen funzt?

Mfg KAMPI

P.S. Sieht es bei AMD genauso wie bei Intel aus?

[kuempi von stein]

Ich verstehe gar nicht, warum das alles so kompliziert sein muss.
Computer (und damit meine ich alle PCs und auch die AS/400) sollten sowas eingentlich als "GrundTool" anbieten, ohne mit der Wimper zu zucken.
Immerhin reden wir hier vom Grundübel schlechthin, nämlich ein Zahlensystem in ein anderes konvertieren.

Aber nein, da muss man von hinten durch die Brust ins Auge irgendwie...

Anyway, back to topics:

Kenne nun die Grundanwendung bei Dir nicht, aber rechne doch den Quatsch dann auf der Kiste (Intel, AMD was immer) mit den dort gegebenen Möglichkeiten aus?
Gibt doch für so ziemlich jede Programmiersprache auf den Kisten auch ne Funktion zum Umrechnen (ausser eben auf der AS/400 scheinbar), selbst in Excel.

Als Beispiel hier mal ein Javascript
JavaScript für Alle! - HexDec-Umrechnung

was leicht zu modifizieren wäre.

kuempi

Nachtrag: für andere Sprachen siehe hier: Conversion Hexadécimal -> Décimal snippets pour c, c# 1.x, c# 2.x, c++, camllight, delphi 5, html, java, php 3, php 4, php 5, python, vb 2005, vb.net 1.x, vb6, vba, windev

[Kampi4]

Ja, ich rege mich auch seit 2 Tagen auf, dass es sowas nicht auf der AS400 gibt. Eigentlich unmöglich sowas. Das Thema hat mich bisher bestimm 10 Arbeitsstunden gekostet

In der Firma wollen wir leider am besten nur AS400 + VARPG machen und keine kleinen Zusatzprogramme haben.

Bin ja jetzt auch der Lösung relatib nah. Aufgegeben wird nicht

Mfg KAMPI

[E305GL]

..ganz einfach:
kein MOVE sondern mit Z-ADD binär nach numerisch, funktioniert bei uns im RPG400, ILE, VARPG

[Kampi4]

Auch mit Z-ADD bekomme ich keinen richtigen Wert.

Habe jetzt mal versucht den Hex-Wert an die AS400 zu übergeben und da im Programm die Umrechnung zu machen. Leider kommt da nicht der Hex Wert an, wie ich ihn im VARPG übergebe. Wie kann das denn sein?!!?

So langsam verzweifel ich. Ich meine, ich will nur zwischen zwei Zahlensystemen umrechnen. Das ist normal eine Befehl und Arbeit von 10 Sekunden!!!!


Danke für eure Hilfe!

Mfg KAMPI

[E305GL]

beim Datenaustausch mit AS/400 erfolgt bei char-Feldern eine EBCDIC ASCII konvertierung

[Fuerchau]

AMD und Intel sind da kompatibel, da sonst keine Software laufen würde (z.B. Pointer sind immer 32-Bit (bz. bei 64-Bit eben 64).
Motorola (e.g. Mac) arbeitet da wieder wie die AS/400.

Für diese Umrechnung musst du nun eben Byteweise arbeiten, da die Interpretation eine 2/4/8-Byte-Integers auf Intel eben w.o. läuft.

Also:

D DSHex DS inz
D MyInt1 3U 0
D MyInt2 3U 0

MyInt1 * 256 + MyInt2

[Kampi4]

Ok, werde das mal ausprobieren Baldur.

Aber noch mal zu deinem Z-ADD:
In der Binärzahl steht in Hex X'000000F6', aber nach dem Z-ADD in eine interger hat die einem Wert von "-72160".


@BenderD: ?? Was soll das denn heissen? Was kann ich denn dafür, dass ich von einem Drucklufttester einen Hexadezimalen Wert bekomme und den umrechnen muss? Irgendwie verstehe ich dein Posting nicht.

Mfg KAMPI


P.S. Versuche im Moment auf beiden Wegen irgendwie zur Lösung zu kommen. Also nach dem Weg von Birgitta und E305GL. Bei Birgitta habe ich nur noch das Problem wie ich den Austausch zwischen VARPG (also PC) und As400 hinbekomme.

[BenderD]

bei der Speicher Überlagerung von einem String und einer als Integer definierten Zahl geht die interne Zahlendarstellung (Prozessor abhängig) in die Umrechnung ein, was zu deinem Problem führt.
Dein Drucklufttester muss eine genaue Spezifikation haben, nach der er seine Werte liefert und genau dafür brauchst du eine Umrechnung. Wenn du an den Wert nur Binär oder Hex bekommst, dann bleibt dir in RPG halt nur der Weg über Umrechnung zu Fuss, am Besten in einer SubProcedure eines Serviceprogrammes.
Falls ihr sowas in der Schule nicht gehabt habt, suche ich dir gerne ein Beispiel raus.

mfg

Dieter Bender

@BenderD: ?? Was soll das denn heissen? Was kann ich denn dafür, dass ich von einem Drucklufttester einen Hexadezimalen Wert bekomme und den umrechnen muss? Irgendwie verstehe ich dein Posting nicht.

Mfg KAMPI

[Kampi4]

bei der Speicher Überlagerung von einem String und einer als Integer definierten Zahl geht die interne Zahlendarstellung (Prozessor abhängig) in die Umrechnung ein, was zu deinem Problem führt.
[...]
mfg

Dieter Bender

Wusste nicht, dass es da von Prozessor zu Prozessor unterschiede gibt. Aber man lernt nie aus.

Genaue Spezifikationen gibt es von dem Tester nur über die Kommunikation. Zum umrechnen von Milliampere nach Bar weiss ich aber, dass 1,6 Milliampere 1 Bar sind. Das reicht ja zum Umrechnen.

Mfg KAMPI

[Fuerchau]

Da ja bei "00F6" "F6" das höherwertige Byte ist ergibt das F600, und da das oberste Bit gesetzt ist, ist der Wert negativ.
Bei der Definition U für Unsigned, sollte das eigentlich ignoriert werden.

Um aber Prozessorneutral zu sein, muss man eben per Spezifikation (siehe Dieter) genau wissen, wie Daten zu interpretieren sind und natürlich auch über Speicherungen auf Prozessoren informiert sein.
Auch Terminologien sind da manchmal unterschiedlich.
Bei Intel (und fast allen PC'lern) werden Bits in Bytes z.B. von rechts nach links gezählt, bei IBM und somit AS/400 aber von links nach rechts.

Wo ist also Bit 0 ?

Naja, und das mit den LOWORD/HIWORD bzw LOWBYTE/HIGHBYTE stammt auch aus der C++/C-Programmierung, wo eben Makros je nach Zielsystem (also Hardware) die Interpretation zur Compilezeit auflösen.

[wwg]

Wusste nicht, dass es da von Prozessor zu Prozessor unterschiede gibt. Aber man lernt nie aus.

Eine ganz brauchbare Erklärung gibt es schon in der Wikipedia: Byte-Reihenfolge – Wikipedia

Intel hat schon bei seinem ersten 8-Bit-Prozessor, dem 8008 (1972), mit diesem Unfug angefangen; da hatten die Adress-Register schon stolze 14 Bit, die seit dem 4-Bit-Vorgänger hinzugekommenen 6 Bit wurden einfach an den alten 16-Bit Befehl des 4004 (8 Bit Befehl, 8 Bit Adresse) angehängt (das war aus Sicht der Entwickler - hard und soft -vermutlich sogar sinnvoll).

Bei dem 8080 (1974) wurden dann die 14 Bit auf 16 Bit erweitert, und man hatte ein 16-Bit Adressformat, mit dem man volle 64K(!) adressieren konnte.

Dieses verquere Format hat man dann aus Kompatibilitätsgründen bis heute beibehalten müssen.

Prozessorhersteller, die früher (IBM) oder später (Motorola) auf den Markt kamen, haben es anders gemacht.

mfg
Werner

(der noch einen Intel-Katalog von 1977 im Regal stehen hat)