Pascal ist jetzt doch überhaupt nicht dafür bekannt, daß man damit irgend etwas maschinennahes machen könnte. Da stellt sich die Frage nicht, außer, da gibt es irgend einen in Assembler programmierten Teil, der ASX-Befehle verwendet.
Kann man das Programm einfach umstricken, damit es bei mir auch
funktioniert?
Das kommt drauf an, was macht denn das Programm? Wenn es nur Pseudocode ist, oder so ähnlich, dann kann man das natürlich schnell umstricken.
Etwas anderes ist, wenn es um Parametereinsatz und weite Bitbreiten geht.
Zuerstmal das: Wie die Paramenterübergabe abzulaufen hat, sollte man entweder in der Compilerdoku, oder eben bei der Programmiersprachendoku finden.
Ein recht stark pascallisches ASM-Buch kam mal von Trutz Eike Podschun
(ISBN 10: 3893198539 / ISBN 13: 9783893198535)
Das ist zwar alt, aber eventuell gibt es da irgendwo auch passende Hinweise zu Übergabekonventionen.
Die Parameterübergabe selber lief früher typischerweise über den Stack. Da gibt es aber erstmal kein MMX, oder drüber (auch wenn MMX selber gestackt ist).
DA wäre dann auch der Ansatzpunkt. Zuerst sollte man aber erstmal schauen, was das Assembler-Programm macht (sofern es was macht) - über die Parameterübergabekonvention müsste man die Übergabe statt x mal eben y mal machen.
(mir fällt gerade ein, man kann z.B. beim Flatassembler (fasm) direkt im Asm-Code die MMX bzw. AVX - Bitbreite als Datenformat angeben. Ist echt geil, aber wie genau das tatsächlich abläuft, habe ich mir noch gar nicht angesehen. Müsste man im Debugger machen.)
WENN neuere Funktionen bei AVX im Einsatz sind, sieht die Sache schwieriger aus.
Grundsätzlich geht es aber (so grob) um Parallelverarbeitung - wie gesagt, da muss man zuerst mal schauen, was das Programm selber macht.
Da Grafikkarten ganz gut hinsichtlich Parallelrechnereien sind, kann man auch schauen, ob es nicht eine passende Schnittstelle dafür gibt (Cuda z.B.)
Wenn ich in die Foren schaue, was dort zu Pascal rund um MMX,SSE oder AVX geschrieben wurde - würde ich sagen:
Stelle diese Frage im Lazarus Forum, da sind sehr viele Lazarus Entwickler unterwegs, die sehr tiefe Erfahrung mit Pascal haben und die können sehr gut helfen:
http://www.lazarusforum.de/
Danke @db1uq für die Erwähnung 04.01.2024 09:56.
Gerne habe ich die {z. B. bei heise publizierten} Interviews mit Niklaus Wirth nochmals gelesen.
(Die linguistisch -philosophischen etc. Diskussionen möchte ich hier nicht erwähnen, nur 2 Anekdoten 1985, welche der Leistung Wirths sicher nicht gerecht werden, aus dem Betrieb damals.)
Da erinner ich mich gerne an den Saal, in dem die {gegen 64k gepimpten} Apple][ mit ihren {kleinen CRTs &} 2 floppy -Laufwerken standen. Wir lernten MODULA-2, so quasi als 1. Generation.
Ein Kommilitone -Student {ET} zeigte mir sein Pascal Programm: da er aus dem Tessin, schrieb er "PROCEDURA" anstatt "PROCEDURE". Ich wies ihn hin, dies sei nicht das Schlüsselwort. Dennoch frass der UCLA compiler dies genüsslich. Ab da wusste ich, dass dieser compilatore die Schlüsselworte auf 8 Zeichen abschnitt.
Eine Biologie Studentin fragte uns, wie sie in PASCAL "y^x" schreiben kann.
Wir sagten "den hoch Operator gibts nicht, aber exp(x*ln(y)) sollte gehen" {nicht ohne den Hinweis auf Performanz -Einbusse}.
Dann funktionierte ihr Programm & sie hatte die Populations -Grafik auf dem Schirm {die performance war ihr egal}.
Ja, so war das damals mit den Datenstrukturen & Algorithmen {und er hat immer noch Recht: die beiden gehören zusammen & in dieser Reihenfolge}.
hab eben gerade im TV auf ZDFneo mal wieder "Apollo 13" gesehen, auch ein interessantes Stück Technikgeschichte. "Wir brauchen eine Prozedur" ist darin ein Schlüsselsatz.
Ich hatte mit Pascal oder Modula nie zu tun, aber der Name Niklaus Wirth fiel mir vorhin auf Wikipedia auf, daher habe ich den neusten Thread hier mit "Pascal" gesucht. Zwei AppleII-Nachbauten habe ich noch hier im Keller liegen. Damit habe ich damals meine ersten Packet-Radio-Signale dekodiert.
Dasselbe Packet-Programm lief später auf dem Commodore64. Ich hatte es nur als ausführbares Programm auf Diskette bekommen und mit einem Disassembler mal in Quelltext zurückverwandelt. Den Ausdruck muss ich noch irgendwo hier liegen haben.
Dazu war ein Portbaustein auf AppleII-Steckkarte nötig, mit dem VIA6522. Modemchip war ein AMD Am7910 oder 7911. Den TCM3105 gab es erst später.
https://pdf1.alldatasheet.com/datasheet-pdf/view/124524/AMD/AM7910.html
Ich habe zwei fernöstliche Kopien der AppleII-Platine vom Flohmarkt. Auf der einen war auch noch die Z80-Karte für CP/M integriert. Irgendwann habe ich mal untersucht, wieso die nicht funktionierte. Der Nachbauer hatte in der Logik ein Gatter vergessen (ich hatte eine Kopie des Schaltplans). Es fand sich noch ein unbenutztes Gatter, damit lief es.
Der Vorbesitzer hatte einen falschen Quarzoszillator eingebaut (14,7456 MHz statt 14,31818 MHz), daher konnte ich zunächst nur sehr kurze Pakete mitlesen.
Ein Funkamateur hier hatte unter CP/M das "Adventure"-Spiel auf Apple-Diskette untergebracht und ließ es über Funkfernschreiben laufen. Ein anderer spielte es so über fast 100km Entfernung im 2m-Band.
https://de.wikipedia.org/wiki/Adventure_(Computerspiel,_1976)
Ja, es war UCSD (nicht "UCLA", wie ich 04.01.2024 19:10 fälschlicherweise schrieb).
Wow, das Spiel hatten wir auch gespielt (allerdings nicht über 100 km Entfernung).
UCSD-Pascal auf dem Apple II. Urg. Das war der Grund, warum ich mir Pascal erst zwei Jahre später genauer angesehen habe; das ständige Durchrotieren von fünf Disketten durch das Diskettenlaufwerk ging mir so gründlich auf die Nerven, daß es mich gründlich abschreckte. (Vielleicht waren es auch nicht fünf, aber der Vorgang "Quellcode schreiben - compilieren" erforderte definitiv mehrere Diskettenwechsel. Beim kleinsten Tippfehler natürlich auch. Immer wieder.
Mein etwas späterer (selbtsbau-) Computer hatte einen Pascalcompiler in einer ROM-Disk, da war das Arbeiten damit dann ein Luxus ...
das ständige
Durchrotieren von fünf Disketten durch das Diskettenlaufwerk ging mir so
gründlich auf die Nerven, daß es mich gründlich abschreckte. (Vielleicht
waren es auch nicht fünf, aber der Vorgang "Quellcode schreiben -
compilieren" erforderte definitiv mehrere Diskettenwechsel.
Darum hatte man ja auch zwei Diskettenlaufwerk angeschlossen.
Darum hatte man ja auch zwei Diskettenlaufwerk angeschlossen.
Das war bei den alten Apple-II-Rechnern in der "Informatik-AG" meiner Schule nicht der Fall. Erst etwas später wurden Apple IIe mit schickem "Duodisk"-Doppellaufwerk und passend dazu designtem Monitor beschafft, da aber hatte mich der Elan, mir in der AG Pascal beibringen zu lassen, bereits verlassen.
Der kam dann (vorübergehend) etwas später mit Prof. Schacht an der TU und dem Pascalcompiler auf der Romdisk meines Selbstbaucomputers wieder zum Vorschein.
Der Compiler hieß Omegasoft und kam von einer Firma namens CSC.
Ja, es war UCSD (nicht "UCLA", wie ich 04.01.2024 19:10
fälschlicherweise schrieb).
Ich hatte lange Jahre (als merkwürdig) USCD-Pascal im Hinterkopf, und war dankbar, dass man z.B. bei Wikipedia den richtigen Begriff finden konnte.
So ganz ohne Internet war man diesbezüglich aufgeschmissen.
Aufgefallen war dieser seltsame Begriff mal (am Ende der 80er wohl) bei einer Softwaresammlung für Atari-Computer.
Ich wusste doch, dass ich das Handbuch irgendwo habe. Aber selbst habe
ich nie mit Pascal gearbeitet.
Mit UCSD-Pascal auf dem Apple habe ich damals Pascal als dritte Sprache
nach Basic und Assembler gelernt und viel Spaß damit gehabt. Auch wenn
sich das Ganze Jahre später als Sackgasse herausgestellt hat, konnte ich
damit wertvolle Erfahrungen in der goto-freien Programmierung und in der
Verwendung zusammengesetzter Datentypen sammeln. Als netten Nebeneffekt
konnte ich die Pascal-Vorlesungen im Studium schwänzen und die Zeit für
konkrete (kleinere) Softwareprojekte nutzen.
Ja, Flex auf 6809. Nein, kein Eurocom, reiner Selbstbau, auf Lochraster gefädelt (sehr vage angelehnt an den Exorciser von Motorola). Mehrere Europakarten im Rack, eine für CPU und das normale RAM, eine für eine kombinierte RAM- und ROM-Disk, eine für einen FDC (1772) ...
War 'ne geile Kiste, damals. Mit 2 MHz Takt (also einem 68B09 und entsprechenden B-Peripheriebausteinen).
Im Selbstbau-Textterminal werkelte dann ein 68B09E, um sich mit einem 68B45 den Bildschirmspeicher teilen zu können.
War der Witz an der Eltec Kiste, 6809 und Grafikspeicher haben sich den
Zugriff 1:1 geteilt und nebenbei noch den Refresh übernommen.
Mein Terminal hat zwar keine Graphik gemacht und keinen Refresh gebraucht, aber den Speicherzugriff haben sich 6809 und 6845 genauso geteilt. Das war ja einer der Vorzüge des 68xx-Busses, daß der Bus nur bei aktivem E wirklich benötigt wurde, so daß man den gemeinsamen Zugriff mit irgendwas anderem sehr simpel konstruieren konnte - die einzige Voraussetzung dafür war, daß der Speicher (und Adressdecodierung etc.) schnell genug waren, um in der Hälfte der Zykluszeit zu funktionieren. Bei 2 MHz Takt blieben also für einen solchen effektiven Zyklus noch sehr großzügige 250 nsec übrig.
(Hätte es eine D-Version des 6809 und der Peripherie gegeben, ich hätte damit gerne einen Rechner aufgebaut ... 4 MHz! Yeah!)