mikrocontroller.net

Forum: PC-Programmierung Neue Assembler Worte in Forth (FPC/TCOM) definieren


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Asterix (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Liebes Forum, wie vielleicht der ein oder andere bemerkt har, 
beschäftige ich mich derzeit mit PC Programmierung unter DOS. Einfach 
weil man da so nah an der Hardware ist und im ganzen Speicher 
umeinanderpointern kann, soweit man ihn denn adressieren kann.

Mittlerweile hab ich einen PnP Hardware Scanner in Turbo C++ 
(Beitrag "Speicherdump mithilfe von C unter DOS erstellen") und einen PCIe Bus 
Scanner mit SmallerC (Beitrag "PCI Express Memory Mapping") 
geschrieben. Jetzt versuche ich mithilfe von Forth über die IO-Ports 
(0xcf8 und 0xcfc) auf meine PCI Hardware zuzugreifen.

Es kommt ja immer irgendwann die Qual der Wahl eines Compilers. Hier ist 
meine Wahl auf FPC bzw. TCOM von Tom Zimmer gefallen und zwar deshalb, 
weil sich mit TCOM Ausführbare Dateien im COM Format erstellen lassen. 
Das Erstellen von standalone Programmen mit Forth ist ja leider nicht 
ganz trivial.

Der Haken an der Sache ist nur, dass FPC und TCOM für 8086 geschrieben 
wurden und der Zugriff auf PCI via Ports ein 32-Bit AX bzw. EAX Register 
zu brauchen scheint. Deshalb habe ich, bis jetzt leider erfolglos, 
versucht das Operand Size Override Prefix 0x66 ins Wörterbuch zu 
pfriemeln. Es scheint mir allerdings so, als dass das einfach eine 
Konstante geworden ist. Zur Verwendung von CREATE DOES> hab ich leider 
auch nur Beispiele für Variablen, Konstanten und Arrays gefunden. Hier 
mal mein Versuch, der auf das was ich in FPCs PASM.SEQ gefunden habe 
aufbaut:
: outz32 ( x -- ) create c, does> c@ ;

$66 outz32 oute32

code sendport   ( -- ) mov dx, $cf8 ret end-code

code senddata   ( -- ) mov ax, $80000000 ret end-code

code outx32   ( -- ) oute32 out dx, ax ret end-code

: main   ( -- ) sendport senddata outx32 ;

Disassembled dann, gekürzt auf die Worte, ohne "Vorspann" und "Abspann":
; OUTZ32
        01DC    DEC   SI                    4E
        01DD    DEC   SI                    4E
        01DE    MOV   0 [SI], BX            891C
        01E0    MOV   BX, AX                8BD8
        01E2    MOV   BL, 0 [BX]            8A1F
        01E4    SUB   BH, BH                28FF
        01E6    RET                         C3
; OUTE32
        01E7    MOV   AX, # 14              B81400
        01EA    JMP   OUTZ32                E9EFFF
; SENDPORT
        01ED    MOV   DX, [CF8 ]            8B16F80C
        01F1    RET                         C3
; SENDDATA
        01F2    MOV   AX, DP                A10000
        01F5    RET                         C3
; OUTX32
        01F6    OUT   DX, AX                EF
        01F7    RET                         C3
; MAIN
        01F8    CALL  SENDPORT              E8F2FF
        01FB    CALL  SENDDATA              E8F4FF
        01FE    CALL  OUTX32                E8F5FF
        0201    RET                         C3
        0202    ADD   0 [BX+SI], AL         0000
        0204    ADD   0 [BX+SI], AL         0000
        0206    ADD   0 [BX+SI], AL         0000
        0208    ADD   0 [BX+SI], AL         0000
        020A    ADD   0 [BX+SI], AL         0000
        020C    ADD   0 [BX+SI], AL         0000
        020E    ADD   0 [BX+SI], AL         0000
        0210    ADC   AX, # DP              150000

Der Compiler sagt auch es bleiben Daten am Stack, also genau mein 0x66. 
Wie  könnte ich die Definition von OUTX32 ändern, so das in Zeile 0x01f6 
anstelle von 0xef ein 0x66ef steht?

Vielen Dank für Euere Hilfe.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Asterix schrieb:

> Es kommt ja immer irgendwann die Qual der Wahl eines Compilers.
[...]

> Deshalb habe ich, bis jetzt leider erfolglos,
> versucht das Operand Size Override Prefix 0x66 ins Wörterbuch zu
> pfriemeln.

Spätestens, wenn man bemerkt, dass es unverhältnismäßig aufwendig wird, 
mit dem gewählten Tool sein Ziel zu erreichen, sollte man die Wahl 
dieses Tools noch einmal hinterfragen (und ggf. revidieren...)

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja wie wäre es mit mov eax,$80000000 ?
Zusätzlich bin ich mir nicht so sicher ob eax generell unter dos 
Realmode überhaupt  funktionieren kann. Das musst du selber prüfen.

Thomas

Autor: Asterix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas schrieb:
> Naja wie wäre es mit mov eax,$80000000 ?
> Zusätzlich bin ich mir nicht so sicher ob eax generell unter dos
> Realmode überhaupt  funktionieren kann. Das musst du selber prüfen.
>
> Thomas

Genau das hab ich für IN, OUT und MOV vor. Um das zu bewerkstelligen 
muss man, soweit ich weiß, nur das Operand Size Override Prefix 
voranstellen.

c-hater schrieb:
> Asterix schrieb:
>
>> Es kommt ja immer irgendwann die Qual der Wahl eines Compilers.
> [...]
>
>> Deshalb habe ich, bis jetzt leider erfolglos,
>> versucht das Operand Size Override Prefix 0x66 ins Wörterbuch zu
>> pfriemeln.
>
> Spätestens, wenn man bemerkt, dass es unverhältnismäßig aufwendig wird,
> mit dem gewählten Tool sein Ziel zu erreichen, sollte man die Wahl
> dieses Tools noch einmal hinterfragen (und ggf. revidieren...)

Eigentlich dachte ich, dass es für Forth Profis ein Kinderspiel sei, ein 
weiteres Byte in den Ausführungskanal zu bekommen. Im Grunde gehts mir 
da auch um CREATE DOES> – weils ja die Essenz von Forth genannt wird. 
Was mir als Neuling gerade nicht gelingt, ist es ein Wort zu definieren, 
dass in seinem Codefeld 0x66efc3 stehen hat. Also OUT DX, EAX RET. Das 
Prinzip dürfte sich dann hoffentlich auch auf IN und MOV Anwenden 
lassen.

Autor: c-hater (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Asterix schrieb:

> Eigentlich dachte ich, dass es für Forth Profis ein Kinderspiel sei, ein
> weiteres Byte in den Ausführungskanal zu bekommen. Im Grunde gehts mir
> da auch um CREATE DOES> – weils ja die Essenz von Forth genannt wird.
> Was mir als Neuling gerade nicht gelingt, ist es ein Wort zu definieren,
> dass in seinem Codefeld 0x66efc3 stehen hat. Also OUT DX, EAX RET. Das
> Prinzip dürfte sich dann hoffentlich auch auf IN und MOV Anwenden
> lassen.

Also, du kannst offensichtlich nicht "hinter den Zeilen" lesen. Also 
deutlicher: Forth ist historisch. Kein Schwein interessiert das heute 
noch ernsthaft.

Allenfalls im akademischen Umfeld (und dort auch nur bei den "Frischen") 
poppt dieser Kram gelegentlich nochmal hoch. Alle anderen wissen nach 
drei Jahrzehnten der "praktischen Anwendung": das braucht man echt 
nicht.

Autor: leo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Asterix schrieb:
> PC Programmierung unter DOS.
> ... 8086 ...

Ich denke mal du bist unter 16-bit 8086 (Realmodus) unterwegs. Da gab es 
schlichtwegs noch kein EAX (32-bit) Register.

leo

Autor: cppbert3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
leo schrieb:
> Asterix schrieb:
>> PC Programmierung unter DOS.
>> ... 8086 ...
>
> Ich denke mal du bist unter 16-bit 8086 (Realmodus) unterwegs. Da gab es
> schlichtwegs noch kein EAX (32-bit) Register.
>
> leo

Du vermischt Memorymodel und 386 Opcode support des compilers

Autor: cppbert3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Asterix schrieb:
>
>> Es kommt ja immer irgendwann die Qual der Wahl eines Compilers.
> [...]
>
>> Deshalb habe ich, bis jetzt leider erfolglos,
>> versucht das Operand Size Override Prefix 0x66 ins Wörterbuch zu
>> pfriemeln.
>
> Spätestens, wenn man bemerkt, dass es unverhältnismäßig aufwendig wird,
> mit dem gewählten Tool sein Ziel zu erreichen, sollte man die Wahl
> dieses Tools noch einmal hinterfragen (und ggf. revidieren...)

Die anderen Tools von ihm sind ja in C geschrieben, ich denke Forth will 
er einfach nur so zum spielen benutzen

Autor: cppbert3 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Asterix schrieb:
>
>> Es kommt ja immer irgendwann die Qual der Wahl eines Compilers.
> [...]
>
>> Deshalb habe ich, bis jetzt leider erfolglos,
>> versucht das Operand Size Override Prefix 0x66 ins Wörterbuch zu
>> pfriemeln.
>
> Spätestens, wenn man bemerkt, dass es unverhältnismäßig aufwendig wird,
> mit dem gewählten Tool sein Ziel zu erreichen, sollte man die Wahl
> dieses Tools noch einmal hinterfragen (und ggf. revidieren...)

Die anderen Tools von ihm sind ja in C geschrieben, ich denke Forth will 
er einfach nur so zum spielen benutzen
^

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
c-hater schrieb:
> Forth ist historisch. Kein Schwein interessiert das heute
> noch ernsthaft.

DOS ist genauso historisch, real mode x86 ausserhalb von BIOS und 
Bootloadern ebenfalls. Und ihn interessiert es offenbar.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
cppbert3 schrieb:
> Du vermischt Memorymodel und 386 Opcode support des compilers

Im Realmode geht der prefix einfach nicht das werden also nie 32 Bit 
Befehle.

Thomas

Autor: Schnauze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das stimmt nicht,  man kann 32 Bit Register im Real Mode benutzen. Dazu 
dient ja das Operand Size Prefix. Man kann aber nicht einfach so (geht 
schon, aber nicht einfach so) z.B. über EDI mehr als 64k Speicher 
adressieren, da grob gesagt per default Addressen grösser 64k maskiert 
werden.

Das könnte evtl. auch ein Problem mit in/out und EDX als Operand werden, 
aber bin nicht sicher.

Lang ist's her.

Autor: Asterix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas schrieb:
> cppbert3 schrieb:
>> Du vermischt Memorymodel und 386 Opcode support des compilers
>
> Im Realmode geht der prefix einfach nicht das werden also nie 32 Bit
> Befehle.
>
> Thomas

Das wird hier 
https://wiki.osdev.org/X86-64_Instruction_Encoding#Operand-size_and_address-size_override_prefix 
und hier 
https://stackoverflow.com/questions/13173138/operand-size-prefix-in-16-bit-mode#14660027 
anders beschrieben.

Autor: A. K. (prx)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nicht nur da.

Autor: Asterix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Allenfalls im akademischen Umfeld (und dort auch nur bei den "Frischen")
> poppt dieser Kram gelegentlich nochmal hoch. Alle anderen wissen nach
> drei Jahrzehnten der "praktischen Anwendung": das braucht man echt
> nicht.

Da du dich – ausgerechnet hier – c-hater nennst würde mich echt brennend 
interessieren in welchen Sprachen du programmierst. Mit deiner 
Einschätzung zu mir liegst du jedenfalls richtig, ich bin Student.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Asterix schrieb:

> Da du dich – ausgerechnet hier – c-hater nennst würde mich echt brennend
> interessieren in welchen Sprachen du programmierst.

In der Reihenfolge der Häufigkeit (nach rein dienstlich geschreibenen 
Programmzeilen) im letzen Jahr:

VB.net
T-SQL
C#
C
Assembler
Java
C++
PostGre-SQL
Perl
(weitere 10 Sprachen...)

Tja, im Job kann man nicht immer seinen Vorlieben frönen, da taucht dann 
C schonmal an 4. Stelle auf, selbst wenn man die Sprache (aus guten 
Gründen) hasst wie die Pest. Nur was man wirklich kennt, kann man so 
dermaßen abgrundtief hassen lernen, vor allem, wenn man auch Besseres 
kennt...

Privat sieht das deshalb auch etwas anders aus:

VB.net
Assembler
T-SQL
bash-Scripting
(ansonsten nix in nennenswertem Umfang...)

Autor: Max (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Haha vb als #1^^
Disqualifiziert!

Autor: Matthias K. (kannichauch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde sagen, Deine code, end-code Zeilen müssen sich in einer 
Wortdefinition befinden, sonst werden sie nur in der compile-time 
ausgeführt oder so. Ist aber schon länger her bei mir.
Beim Inline Assembler in Forth sind die Argumente umgetauscht.
(Operand, Operator, wie hieß das andere noch mal?)
Also aus mov a,b wird mov b,a oder z.B. b,a mov.
Ich weiß auch keinen Grund, warum in einer code,end-code Zeile keine 
simplen Bytes stehen können.

Die von mir erwähnten Sachen solltest Du mal kontrollieren.
Versuche auch erst einmal, das Problem zu isolieren.
Einen Haufen Komplexitäten kannst Du auch behalten.

Was findest Du nicht in der Dokumentation, oder gibt es gar keine?
Empfehlung dazu: Wenn Du gut in C schreiben kannst, nimm davon den 
Inline Assembler.
Im übrigen kannst Du ohne protected mode bei einem X386 und aufwärts 
durchaus
 32bit Code verwenden.

Übrigens ratet mal, was mir bei der Suche nach "TCOM" ins Auge springt. 
FPC ergibt auch nichts sinnvolles(Free Pascal Compiler?).

Autor: Asterix (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Matthias K. schrieb:
> Übrigens ratet mal, was mir bei der Suche nach "TCOM" ins Auge springt.
> FPC ergibt auch nichts sinnvolles(Free Pascal Compiler?).

Dank Dir hab ich diese Seite gefunden http://forth.org/eforth.html 
vorher war ich nur dort http://forth.org/compilers.html unterwegs. 
Lesson 3 von Richard E. Haskell scheint mir den Weg zum Ziel zu deuten. 
Da werd ich mal ansetzen.

c-hater schrieb:
> Asterix schrieb:
>
>> Da du dich – ausgerechnet hier – c-hater nennst würde mich echt brennend
>> interessieren in welchen Sprachen du programmierst.
>
> In der Reihenfolge der Häufigkeit (nach rein dienstlich geschreibenen
> Programmzeilen) im letzen Jahr:

An der Uni brauch ich nur MATLAB. Früher an der Schule wurde mal C# 
gelehrt. Naja, und die alten TI BASIC Programme fürn Taschenrechner kann 
man hier noch mitzählen. Das wurde zwar nicht gelehrt, hatte allerdings 
seine Vorteile. Grad in Anbetracht dessen, dass die Lehrer den 
Taschenrechner nicht begriffen haben.

Privat steht C an erster Stelle. Shell Skripten nehmen auch viel mehr 
Raum ein als ich zuerst dachte. Dann wohl C++, Scheme, Forth, Fortran, 
Ada.

Am besten kann ich C. Da es im Vergleich ja doch noch überschaubar ist. 
Um mal eine Anektode zu erzählen – als junger Mensch dachte ich noch, 
dass das Programmieren einfach viel mit Klammern zu tun hat. Wegen all 
der runden, geschweiften, eckigen und spitzen Klammern in C, Java, C++, 
C#, D und wie sie sonst noch heißen in der C Sprachfamilie. Eigentlich 
hab ich das was ich sah und mir beigebracht wurde als lineare 
Entwicklung aufgefasst. Ganz früher Assembler, dann C, danach C++ und 
heut C# um das mal vereinfacht darzustellen.

Sprachen wie Scheme und Forth musste ich erst entdecken, da sie 
heutzutage an der "Oberfläche" gar nicht mehr zu sehen sind. Dabei ist, 
zumindest für mich, die Einheitlichkeit von Scheme Code mit großer 
Ästethik verbunden. Forth hingegen gibt mir die Freiheit meine Worte 
x-beliebig zu nennen. Es kennt nur Worte und Zahlen. Klammern sind dort 
auch nur Worte. Sogar das alte TCOM hat mir schon ein UTF-8 codiertes 
'ä' ohne zu murren in einen Wortnamen kompiliert.

Es ist einfach Schade, dass Konzepte wie call/cc in Scheme oder CREATE 
DOES> in Forth nur mit ihren einfachsten Beispielen einer breiteren 
Öffentlichkeit vorgestellt werden. Da ich wohl auch nicht der hellste 
Stern am Nachthimmel bin, ist mir die beschworene Mächtigkeit von 
call/cc anhand von setjmp(), longjmp() oder CREATE DOES> was als 
Hilfsmittel zur Deklaration von Konstanten, Variablen und Arrays 
dargestellt wird, nicht klar geworden.

Dabei hat mir Forth schon am ersten Tag den Gendanken beschert, man 
könne in dieser Sprache seine Programme in Gedichtform verfassen.

Autor: c-hater (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Max schrieb:

> Haha vb als #1^^
> Disqualifiziert!

Idiot!

1) VB.net != VB
2) VB.net == C# abgesehen von einer wesentlich angenehmeren Syntax, 
nicht
                nur für den Programmierer, sondern vor allem auch für 
die
                Kontext-bezogenen Hilfsmittel des VS, insbesondere
                IntelliSense kann dank der höheren Redundanz der Sprache 
sehr
                viel schneller und treffsicherer arbeiten.

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.

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