Assembler

• A

  JG, JGE, JL, JLE - CMP
  • agentmulder  

  3
  0
  Stimmen
  3
  Beiträge
  794
  Aufrufe

  C

  sign ist einfach nur das vorzeichen eines ergebnisses, entspricht also immer dem höchstwertigen bit. overflow wird bei befehlen mit zwei operanden gesetzt, wenn das exakte ergebnis nicht in einen signed integer der entsprechenden grösse passt. overflow signalisiert also wrap-around am min(signed)/max(signed) ende des wertebereichs während carry bei einem wrap-around am 0/max(unsigned) ende gesetzt ist. für die reine sprungsyntax muss dich das allerdings nicht interessieren, die namen der bedingten sprünge sind eigentlich selbsterklärend (wenn einmal den unterschied zwischen less and below erkannt hat ).
• J

  Eine Frage zu Segmente
  • JnZn558  

  5
  0
  Stimmen
  5
  Beiträge
  583
  Aufrufe

  R

  Die überlappenden Segmente sind durchaus notwendig: EXE-Files werden ja so gelinkt, dass alle FAR-Adressen einen fixen Offset-Anteil haben und nur der Segmentanteil über die relocations verändert wird. Hätte man jetzt nur das erste Segment bei 0000h, das zweite bei 1000h usw., dann könnte das Programm immer nur an diesen Stellen angesiedelt werden. Oder noch schlimmer, je nach Anfangsadresse von einem Speicher- oder Codeblock könnte man immer nur eine begrenzte Anzahl von Adressen darüber ansprechen. Wenn man sich die Segmente nicht als überlappende Blöcke vorstellt, sondern als abgetrennte Blöcke mit einer Startadresse und einer Länge, finde ich das ganz gut verständlich. So werden sie ja auch tatsächlich verwendet, nur gibt's halt keinen Hardwaremechanismus, um die Länge eines Segments anzugeben, somit sind alle Segmente automatisch 64KB lang und ragen über das logische Ende hinaus. Ähnliche Mechanismen gibt's auch bei RISC-Maschinen, wo man mit manchen Befehlen nur Adressen erreichen kann, die "in der Nähe" sind - ist also vergleichbar mit "im gleichen Segment".
• S

  Protected-Mode und die Hardware
  • sevobal  

  3
  0
  Stimmen
  3
  Beiträge
  478
  Aufrufe

  S

  danke!
• ?

  byte schnell von a nach b kopieren
  • Gast  

  14
  0
  Stimmen
  14
  Beiträge
  1572
  Aufrufe

  R

  So schaut's vernünftig aus. Ich werd trotzdem mal ins Intel Manual schauen :). Man sollte ja mit mfence nicht gerade um sich werfen, weil es einfach eeeeewig dauert. Dagegen ist ein normaler Speicherzugriff ja geradezu so flink, dass er überhaupt nicht ins Gewicht fällt.
• C

  Assembler lernen! Gutes Buch?
  • curry-king  

  16
  0
  Stimmen
  16
  Beiträge
  4845
  Aufrufe

  A

  Gibt's die Bücher auch als ebook, oder weiß wer ein gutes Assembler ebook?
• S

  Problem durch zu große Zahlen
  • sevobal  

  11
  0
  Stimmen
  11
  Beiträge
  1323
  Aufrufe

  R

  Wieso willst du überhaupt in Assembler programmieren? Es sieht nicht so aus, als ob du dich damit auch nur rudimentär auskennen würdest. Es sagt ja keiner, dass du unbedingt genau dieses Register verwenden musst, wenn du's eh selber machst.
• S

  NOP
  • spjoe  

  11
  0
  Stimmen
  11
  Beiträge
  1260
  Aufrufe

  ?

  Edit and Continue Bye, TGGC (Dem beste BdT)
• T

  Anfängerprobleme mit inline ASM und FPU
  • teichgraf  

  18
  0
  Stimmen
  18
  Beiträge
  1779
  Aufrufe

  C

  sehr schön. natürlich ist noch lange nicht das ende der fahnenstange, was die optimierung betrifft, erreicht ich hätte da ein paar ideen, was man versuchen könnte: 1. sse statt fpu - da gibt es prinzipiell zwei möglichkeiten, - man arbeitet mit ungepackten daten. hier könnte man evtl. eine bessere auslastung der ausführungseinheiten des prozessors erreichen, die register sind ja nicht als stack angelegt, so dass man nicht ständig mit stackumorganisieren beschäftigt ist - mit gepackten daten: also 4 floats mit einer instruktion. nachteil ist, dass man sich hier erst einmal gedanken machen muss, wie man mit fällen zurecht kommt, bei denen nur einige aber nicht alle der punkte divergieren. hier müsste man irgendwie die punkte auf die register mappen. am besten aber erst mal eine studie in c/c++ schreiben, um das konzept zu prüfen; auf jeden fall gäbe es eine menge overhead, ein geschwindigkeitsfaktor 2 könnte aber drin sein 2. integer statt fpu. gerade beim mandelbrot set bietet sich unter umständen festkommaarithmetik an, da durch die addition des komplexen C der iterationswert ohnehin ständig normalisiert ist. es ergeben sich aber möglichweise etwas andere rundungsfehler. 3. kombiniere integer mit fpu oder sse - integer und fpu/sse-befehle können ja weitestgehend parallel und unabhängig ausgeführt werden. hier wäre also auch noch potential vorhanden.
• *

  Mauszeiger im SVGA Modus (und >640x480)
  • *Morpheus*  

  21
  0
  Stimmen
  21
  Beiträge
  2018
  Aufrufe

  N

  [Morpheus] schrieb: Ich weiss jetzt nicht, ob du das mit dem "zusammenklicken" nur auf meine Assemblercodes bezogen hast oder auf meine allgemeine Programmierung,[...] Was du sonst so in anderen Sprachen programmierst, weiss ich nicht. Ich gehe nur von dem aus, was du in diesem Thread geschrieben hast. [Morpheus] schrieb: Vielleicht sollte ich dann ja wirklich lieber bei C++ bleiben. Das kann ich wenigstens und da brauche ich nichts "zusammenklicken". Wenn du nur moeglichst schnell Resultate willst und nicht vor hattest, richtig Asm zu lernen, wird das wohl das Beste sein. Ansonsten ist das Gebastel mit Asm irgendwo einfach nur noch zu aufwaendig. [Morpheus] schrieb: Das war ja nur bei meinem VESA-Teil das Problem, dass das nicht so richtig funktioniert hat. Der Rest, den ich bisher geschrieben habe, ist ein wenig anderes ... aber das tut jetzt nichts zur Sache. Tja, das ist eben das Problem bei dieser Vorgehensweise: Irgendwann funktioniert's nunmal nicht auf Anhieb und dann bist du angesch*****. :p [Morpheus] schrieb: Okay ... dann schließe das Thema von mir aus. :p Wie du meinst, morgen mache ich's dicht... (also in ~1h :D).
• X

  Tutorial gesucht ASM2C
  • XFlorian  

  7
  0
  Stimmen
  7
  Beiträge
  770
  Aufrufe

  C

  XFlorian schrieb: Kennt jemand solch ein Tutorial, wie Schleifen usw. von ASM in C übersetzt werden. ich sags mal so: es gibt keine schleifen in asm
• ?

  VESA-Programme unter Windows ausführbar?
  • Gast  

  4
  0
  Stimmen
  4
  Beiträge
  568
  Aufrufe

  N

  Hi. Ist der Text so missverstaendlich? Verstehe irgendwie nicht, was du da hineininterpraetierst. Ich will damit eigentlich nur sagen, dass hochaufloesende VESA-Modi in WinXP&co. meist nicht funktionieren. Warum weiss ich auch nicht, aber ich nehme mal an, dass MS nicht wenig an der eingebauten DOS-Emulation gespart hat. Resultat ist, wie von dir beschrieben -> schwarzer Bildschirm. Da das mitgelieferte Bild nun ziemlich hochaufloesend ist (braucht mindestens 800x600), wird das Programm mit diesem Bild in WinXP hoechstwahrscheinlich nicht laufen. Nimm ein BitMap mit einer Aufloesung von <=320x200, nenne es wie das mitgelieferte Bild, bzw. aendere den Pfad im Quellcode, und es sollte laufen. PS: hmm... Vielleicht sollte ich ein kleineres Bild mit reinpacken. Dann sieht's zwar nicht so schoen aus, unter WinXP ist dann aber immerhin noch etwas zu sehen und der Download wird kleiner...
• S

  Mauszeiger malen
  • sevobal  

  7
  0
  Stimmen
  7
  Beiträge
  662
  Aufrufe

  N

  Ok, also so wie der Code jetzt ist, kannst du den natuerlich nicht verwenden. Mal abgesehen davon, dass der nur PS/2-Maeuse unterstuetzt, taugt der wirklich nur als Anschauungsmaterial. Aber das war dir hoffentlich sowieso schon klar. Da muesste zB. noch ein IRQ-Handler installiert werden etc. Aber das war deinem ersten Post zufolge IMHO eh nicht das Thema, sondern das Zeichnen des Mousecursors in einem VESA-GrafikModus im RM - und wie du hier BitMaps/Pixelreihen auf den Bildschirm bringst, solltest du irgendwie inzwischen begriffen haben... Ansonsten bezieht sich "[Morpheus]"s Thread momentan genau auf dieses Thema. Whatever: Wenn du nur auf der Suche nach fertigem Code fuer ein MouseTreiberSystem mit verschiedenen Grafikcursors fuer hochaufloesende Grafikmodi etc. bist, muss ich dich leider enttaeuschen: Wirst du hier hoechstwahrscheinlich nicht finden... ...Solange du nicht bereit bist, was dafuer springen zu lassen.
• H

  CPU,Temperatur
  • hmm  

  3
  0
  Stimmen
  3
  Beiträge
  706
  Aufrufe

  B

  Hi, Das Problem bei der Sache ist, dass du mit Assembler hier auch nicht viel weiter kommst, da du unter Windows / Linux (ich gehe einfach mal davon aus, dass du die Temperatur anzeigen wills während du ein Betriebssystem ausführst) keinen Zugriff auf die Hardware im Allgemeinen hast (sei es SMBus-Controller oder Supervisory-Chips, o.ä.). Daraus folgt (da nur Treiber diesen Zugriff auf die Hardware haben), dass du dafür entweder einen eigenen Treiber schreiben musst oder alternativ (falls Windows/Linux bereits einen Treiber für diese Mainboardeinheiten bereitstellt) den Treiber via WinAPI bzw. Linux API "befragen" musst.
• ?

  lol @ Nobuo
  • Gast  

  2
  0
  Stimmen
  2
  Beiträge
  466
  Aufrufe

  N

  Doch, kann ich. :p BTW: Dieser Thread hat genausowenig mit Asm zu tun, wie der, auf den du dich beziehst. Sowas regelt man normalerweise per Mail. og. Thread wird nicht mehr gebraucht (hat nichts mit Asm zu tun, neuen Thread kann Moi nun selbst in genannten Alternativforen erstellen, Fragen dazu per Mail - so.) Was geht dich das an? [closed]
• ?

  Windows herunterfahren?
  • Gast  

  4
  0
  Stimmen
  4
  Beiträge
  583
  Aufrufe

  N

  Scheint sich also erledigt zu haben...
• M

  strlen ist schneller
  • Manuelh87  

  7
  0
  Stimmen
  7
  Beiträge
  832
  Aufrufe

  C

  Darf ich da auch code posten wenn ich ein paar verbesserungsvorschläge haben will und n bissal feedback brauche oder daarf ich das irgendwem von euch schicken.... jede intelligente frage ist willkommen
• S

  Textfarbe und Schnittstellen
  • sevobal  

  4
  0
  Stimmen
  4
  Beiträge
  530
  Aufrufe

  N

  Leider bin ich kein Hellseher und kann aus den spaerlichen Infos, die du rausrueckst, nicht erkennen, wo genau nun dein Problem beim Setzen der Textfarbe ist. Ich kenne dein Interface zur Textausgabe nicht (falls ueberhaupt vorhanden, muesstest du sowieso selbst wissen, wie es funktioniert ) - waere also hilfreich, wenn du kurz erklaeren wuerdest, wie es funktioniert. Ich weiss nicht, mit welchem Bildschirmmodus du gerade arbeitest (anzunehmen waere VESA Grafik - wenn du aber schon Code zur Textausgabe selbst geschrieben, oder beim kopieren zumindest verstanden hast, verstehe ich wiederum dein Problem erst recht nicht - zur Textausgabe gehoert normalerweise automatisch auch die Festlegung der Textfarbe) Oder geht es vielleicht um ein Aendern der Palette in Modi mit <=256Farben? Fragen ueber Fragen...
• ?

  WriteFile Problem
  • Gast  

  5
  0
  Stimmen
  5
  Beiträge
  698
  Aufrufe

  R

  Dann wirst du es dir wohl irgendwo überschreiben. Schau mal im Debugger nach, ob CR_LF zum Zeitpunkt des WriteFile noch 13,10 enthält. Vermutlich nicht!
• T

  PC und große Zahlen darstellen?
  • Tauboga  

  12
  0
  Stimmen
  12
  Beiträge
  2644
  Aufrufe

  C

  dieses Beispiel da oben hab ich mal schnell getippt und übersetzt dabei darf man die zahl natürlich nicht komplett nehmen: 1011100000000001000000000000000000000000 um es besser zu erkennen mache ich mal da leerzeichen rein: 10111000 00000001 00000000 00000000 00000000 (um die übersicht zu erhöhen werde ich mal in HEX posten) lade eine 1 in EAX: mov eax,1 b8 01000000 dabei ist B8 (also 10111000) die Anweisung für den Prozessor die nächstfolgende Zahl in EAX zu laden. wie schon in meinem vorherigen Posting kurz angeschnitten, erwartet die CPU Befehle, die nach einem bestimmten Muster aufgebaut sind.Operand sagt was geschehen soll und danach folgt entweder eine Zahl die geladen/verrechnet werden soll oder die Adresse woher oder wohin geschrieben werden soll. Also: b8(10111000) ist die Anweisung die nächstfolgende Zahl in EAX Register zu laden. Jetzt warum da noch 00000001 steht und dahinter noch 3 Bytes mit nullen: Es könnte etwas verwirrend sein, aber das ist der Little-Endian prinzip: Die CPU die nach diesem Prinzip arbeitet, speichert ihre Variablen(also Speicheradressen, Zahlen usw) "verkehrt". Das heißt dass die Bytes von hinten nach vorne(oder von rechts nach links, wie mans sieht) geschrieben wernden - beispiel: die Zahl (in hex): 20d2 wird in den Speicher d2 20 geschrieben. http://de.wikipedia.org/wiki/Endian Deshalb stehen da auch 00000001 00000000 00000000 00000000 und nicht 00000000 00000000 00000000 00000001 Nicht alle CPUs machens so, z.B die von MAC (G) speichert nach Big Endian. Warum das so ist, kann ich nicht sagen... Das heißt aber für uns speziell wenn wir die Werte aus dem Speicher von unserem Pentium/Amd nehmen, müssen wir die noch umstellen, bevor wir sie nach dezimal umrechnen können. Das selbe mit der zweiten Zeile: (00000)101 11100110 00000011 00000000 00000000 die Zeile in Hex heißt: 05 e6 03 00 00 dabei ist die 05(00000101) die Anweisung ADD EAX,x und weiterhin folg die Zahl: 11100110 00000011 00000000 00000000 wenn man diese umrechnen will ohne sie vorher umzustellen dann gibt der taschenrechner natürlich 3858956288 aus.Deshalb umstellen: 00000000 00000000 00000011 11100110 jetzt umrechnen: 998 PS: woher ich weißt welcher opcode was ist: ich hab "assembler ge-packt" von Joachim rohde (schon ca. seit 3-4 Jahren) und natürlich hab ich auch OllyDbg wo man einfach die Anweisungen reinschreibt und dieser die direkt übersetzt Zu den Processorbefehlen: nicht alle befehle sind nur 8-bit groß, es gibt relativ viele die mehr belegen.Aber das ist eine ganz andere Geschichte
• ?

  Bin total verwirrt wegen Register!!!
  • Gast  

  13
  0
  Stimmen
  13
  Beiträge
  1407
  Aufrufe

  R

  Doch. Hat das irgendwer bestritten?