000
28.06.2025, 22:54 Uhr
Early8Bitz
|
Ich lehne mich jetzt mal aus dem Fenster und halse mir für die nächsten Wochen etwas Arbeit auf, um Wort zu halten.
2025 tauchten in einem Diskettenkonvolut drei UDOS Disketten mit einem C-Compiler für UDOS auf.
RT Beitrag https://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=22806 von alberich
Ich habe mich intensiv mit dem Compiler beschäftigt und einiges damit programmiert und will hier in loser Folge meine Erkenntnisse zu Fehlern, Fallen und meinen Korrekturen dazu mitteilen.
Heute: Bestandsaufnahme
Die drei Disketten sind im Diskettenformat 80 Spuren, 2 Köpfe, 16 Sektoren pro Kopf und Seite, Sektorlänge 256 Byte (640kB pro Diskette).
Dieses Format wird von UDOS 5 bzw. P8000 UDOS verarbeitet (Treiber $NDOS oder $DDOS).
Die Disketten (im weiteren dann immer mit Kurzform D1, D2 und D3 referenziert) identifizieren sich wie folgt:
| Quellcode: |
D1 Label: MUTTERSYSTEM
D2 Label: CC ZUR NACHNUTZUNG
D3 Label: C - Programme
|
D1 ist zugleich eine UDOS 1715 Systemdiskette mit den gängigen UDOS Dienstprogrammen.
Hier erstmal die C relevanten Dateien auf den jeweiligen Disketten
| Quellcode: |
Dateiname D1 D2 D3 Bemerkung
=====================================================================================
Binaries:
CC X X UDOS-C-Compiler V 8.11 Hauptprogramm
CC1 X X C-Compiler Overlay Pass 1
CC2 X X X! C-Compiler Overlay Pass 2+3
LL X Library Link Utility V 8.9
OML X Object Module Librarian V 8.9
CCF Gleitkommamodul für Direktausführung (fehlt!)
Object Files:
C.INT.OBJ X Interger Arithmetik und Basisfunktionen
C.STR.OBJ X Stringfunktionen
C.IO.OB X C- und UDOS-spezifische I/O-Funktionen
C.FLOAT4.OBJ X X 4 Byte Floating Point Artihmetik
C.FLOAT3.OBJ X X 3 Byte Floating Point Artihmetik
TERM.OBJ X Vermutlich PC1715 Bildschirmfunktionen
Libraries:
libc.a X
Header Files:
assert.h X X
attr.h X X
errno.h X X X!
math.h X X Headerfile für 4 Byte Floating Point Artihmetik
math3.h X X Headerfile für 3 Byte Floating Point Artihmetik
stdio.h X X X!
stdlib.h X X
tinit.h X Headerfile für gerätespezifische Bildschirm und Tastatursteuerung
Sonstige Dateien:
CLINK X X Commandfile zum Linken gegen die libc
UDOSC.B X Dokumentation V 8.10
Demoprogramme (C-Source):
SAMP[1..5].C X
TASTENTEST.C X
diverse X
CC2 Sources X!
|
CC, CC1 und CC2 sind auf den Disketten D1 und D2 binär identisch.
Das Hauptprogramm CC beinhaltet die Laufzeitumgebung ab Ladeadresse 0xC000, die auch von den Overlays CC1 und CC2 referenziert wird.
Die binär identische Laufzeitumgebung erhält man, wenn man die C.IO.OBJ, C.INT.OBJ und C.STR.OBJ (in dieser Reihenfolge) auf Adresse 0xC000 linkt.
Auf Diskette D3 sind mehrere Quellprogrammmodule für das Overlay CC2 zu finden. Anhand eines Commandfiles zum Linken von CC2 sieht man, dass
die Overlays gegen die drei Objektfiles der Laufzeitumgebung gelinkt werden. Allerdings ist das Binary von CC2 auf D3 nicht identisch mit
CC2 von den Disketten D1 und D2. Stichproben ergaben, dass Funktionsaufrufe, die CC2 zum Laufzeitpart in CC tätigt, bei der CC2 Version von Diskette D3
nicht zu den richtigen Adressen führen. CC2 von D3 ist daher nicht fähig, mit CC und CC1 aus D1 und D2 zusammen zu laufen.
Versucht man, auf D3 CC2 mit dem vorhandenen drei Objektfiles der Laufzeitumgebung (von Diskette D2) zu linken, meckert der Linker sowohl
über doppelt definierte GLOBALS als auch nicht nicht aufgelöste EXTERNALS.
Die beiden Headerfiles stdio.h und errno.h auf D3 unterscheiden sich auch von denen auf D1 und D2.
Es sind in errno.h weniger Fehlercodes definiert und der in der stdio.h ist der Datentyp long als int definiert, was in der Kompilerversion auf D1/D2 und den Laufzeitmodulen aber definitv getrennt behandelt wird.
int = 16bit, long = 32bit
Es ist daher anzunehmen, dass der CC2 Quellcode auf D3 aus einer anderen, wahrscheinlich älteren Versionsschiene stammt.
C.FLOAT3.OBJ und C.FLOAT4.OBJ unterscheiden sich auf D1 und D2 während die zugehörigen Headerfiles math3.h und math.h auf beiden Disketten identisch sind. Die Analyse dazu steht auf der ToDo Liste
Es fehlt eine Datei CCF, das ist ein gelinktes FloatingPoint Modul, welches von CC aufgerufen wird, wenn man beim Kompilieren eines Anwenderprogramms die direkte Ausführung wählt (Kompileroption -R (Run)) und das Programm Gleitkommaarithmetik benutzt.
Man findet in dem ganzen Dateisalat keinerlei Hinweise auf einen Entwickler, weder als Personenname noch eine Firmenbezeichnung.
Allerdings benutzt der ganze Compiler weder selbst, in der Laufzeitumgebung noch in den damit erstellten Programmen den Alternativregistersatz oder die Indexregister.
Ausnahme: UDOS spezifische I/O-Funktionen in der Laufzeitumgebung verwenden IY für den I/O-Vector und IX als Index für das Feld mit den Dateieigenschaften, welches beim open() vom Dateidescriptor eingelesen wird.
Ich gehe daher davon aus, das dieser Compiler eine Vorgeschichte in der i8080 Welt hat (ob CP/M oder was proprietäres lässt sich nicht erkennen) und auf UDOS portiert wurde.
Wer anhand der heutigen oder den folgenden Beschreibungen einen Wiedererkennungseffekt verspürt, um welchen ursprünglichen C-Compiler es sich handeln könnte, der hebe die Hand.
Ebenso bin ich an weiteren Disketten(-images) interessiert, wenn darauf etwas zu finden ist, was mit dem C-Compiler in Zusammenhang stehen könnte.
--
Gruß
Ralf
Ist ein alter Schaltkreis ein Schaltgreis?
Dieser Beitrag wurde am 28.06.2025 um 22:58 Uhr von Early8Bitz editiert. |
