Programme sind alle bei 8000 hex soweit ich weiss. Und zwar auch 'gleichzeitig'
also beim Multitasking, da werden nämlich dem Prozessor von der MMU die Seiten
aus dem physikalischen Speicher untergeschoben, wenn der Task gewechselt wird.
Der Vorteil ist, das das Programm denkt es wäre allein im Speicher, andere
Programme kann es gar nicht erreichen wenn es ab 8000 hex bleibt und hantiert.
Früher durfte es in sämtlichem Speicher schreiben den die MMU bereitstellt, da
wurde aber die zero - Page letztens herausgenommen, um die Stabilität zu
verbessern.
Bei Relocatable modules ist das mit der 8000 nicht der Fall, die müssen so
geschrieben werden dass sie verschiebbar(=relocatable) bleiben, alle Befehle
müssen relative Adressierung aufweisen. Damit meine ich die Assemblerbefehle,
die der Prozessor später ausführt. Der C-compiler muss das für die
Codeerstellung wissen, sonst macht er keinen relocatable code.
Das das Betriebssystem einem das so vorschreibt ist eine Konvention die
getroffen wird, um das System sauber programmierbar und bedienbar zu machen. So
ähnlich wie die Konvention den Wimp Poll aufzurufen damit das Multitasking
sauber funzt und nix hakelt. Muss man aber nicht so machen wenn man unbedingt
nicht will.
Ich habe allerdings festgestellt, daß die meisten Konventionen in RiscOS sehr
intelligent, sinnvoll und meist mit Optimierungsgedanken verknüpft sind.
Dann noch eben den Unterschied zwischen Basic und C beim RiscOS: die sind
ablauftechnisch gar nicht sooooo weit voneinander entfernt: das Basic wird
nämlich zumindest 'Vorübersetzt' (tokenized) falls es in textform vorliegt. So
ein bißchen wie compilieren. Sonst sind Basic Files im Editor nämlich auch kein
ASCII Text.
Libraries kann Basic auch (Dr Wimp z.b.) und muss die auch 'linken'
Aber Basic ist halt doch ganz schön eingeschränkt gegenüber C/C++. Man kann
sich zum Beispiel keine Datentypen deklarieren, ich bin ja ein großer Freund
von Skalar- und Vektoroperationen auf Tabellenspalten...In C++ wird das n
Einzeiler..
Ich hoffe ich habe ein bißchen Klarheit Reinigungen können..
Schöne Grüße,
Uwe
---- Carlos Michael Santillan schrieb ----
On 4 Mar 2017 Alexander Ausserstorfer <bavariasound@xxxxxxxxxxxxxxx> wrote:
Das scheint mir ein wenig kompliziert zu sein. Woher kennt man jetzt die
Ich sehe in der Sache nicht den Unterschied zwischen C und BASIC und
tatsächlich haben nur die Kommandos/Funktionen andere Namen und
verhalten sich etwas anders. Zusächlich ist die Methode irgendwelche
Bytes in den Speicher zu schreiben um das dann auszuführen nicht gerade
transparent. Was macht eigentlich der Wert 123 oder 85? Da ist es besser
Assembler zu benutzen das beim BBC BASIC schon vorbereitet ist. In BASIC
schreibst Du das ab der Adresse 49192. Das kann man in C genauso und
schon hast Du die Startadresse.
Anfangsadresse eines Programms oder wo die einzelnen Unterroutinen
liegen, damit die richtig angesprungen werden können? Ich könnte mir
denken, dass da das Betriebssystem irgendwas machen muss.
Soweit ich mich erinnere haben Programme immer die gleiche Startadresse.
War irgenwas mit 800 oder so. Das ist zu lange her und ich habe damit
nie hantiert. Beim 64 läuft genau ein Anwendungsprogramm das dann den
gesamten Speicher nutzen kann. Bei RISC OS immer mehrere Programme
(Prozesse). Ich meinen das steht recht am Anfang der PRMs. Die wissen
das auch viel besser als ich aus dem Gedächnis und der nie damit
gearbeitet hat.
Eine API wie die SWIs sind da besser. Offenbar hat es beim 64 und Co.
nie Updates gegeben und darf es dann ja auch nicht.
Deshalb hat auch immer so gut wie alles funktioniert. Probleme gab es
eigentlich nur gelegentlich bei den verschiedenen C64-Modellen.
Genau das ist das Problem wenn man feste Adressen anspringt. Wenn man
SWIs nutzt regelt das RISC OS und spring dann die richtige Adresse an.
Mit DATA hinterlegt man die Dezimalwerte, welche ein Programm oder Daten
beschreiben, also z. B.
100 DATA 123, 85, 38, 3, 80, 89, ...
usw.
READ liest diese Daten nacheinander aus.
POKE schreibt Daten in den Speicher. PEEK liest Daten aus dem Speicher
aus.
Will man z. B. ab Adresse 49192 ein Programm oder Daten in den Speicher
klopfen, macht man folgendes:
10 FOR a = 49192 TO ...
20 READ d
30 POKE 49192 + a
Das sollte wohl nur a stehen. :-)
40 NEXT a
100 DATA 123, 85, 38, 3, 80, 89, ...
BTW: Man muss für die FOR Schleife wissen wieviele Daten in DATA liegen.
Muss man bei C aber auch.
Man könnte vielleicht hergehen und mit Hilfe von C einen Datenblock in
den Speicher klopfen, der Entsprechendes enthält (Code + Daten).
int a[2000];
a[0] = 123;
a[1] = 85;
[a2] = 38;
Das wäre eine Lösungsmöglichkeit. Ein Array ist nur einen andere
Schreibweise für Zeiger. Nebenbei gilt das auch für BASIC.
Dann weiß ich aber immer noch nicht, was der C-Compiler tatsächlich
macht. Denn vermutlich macht er mehr. Wo startet also das Programm? Und
Bei BASIC weiß ich es auch nicht.
was ist mit der Main-Schleife (welche der Compiler anscheinend
blödsinnigerweise erwartet, obwohl die kein Mensch braucht, denn sonst
bricht er ab)? Die Main-Schleife ist auch ein Hauptproblem bei den
Modulen; denn diese kennen keine.
C Programme besteht aus Funktionen und main() ist halt die wo alles
anfängt. Das Module kein main() haben ist durchaus richtig. Es sind
keine Programme, sondern nur einen Samlung von Funktionen. Das
eingentliche Programm hat die Funktion main() und ruft die eine oder
andere Funktion aus dem einen oder anderen Modul auf.
Wenn ich die Daten mit Hilfe von C in den Speicher klopfe, dann aber mit
Hilfe eines Editors wie StrongEd den übersetzten Code von überflüssigem
Zeug "bereinigen" muss, dann kann ich auch hergehen und den Code gleich
mit Hilfe von StrongEd direkt einklopfen. Das ist nicht sinnvoll.
Du meinst direkt Maschinensprache?
Weil ich nicht weiß, wie ich dort die entsprechenden
Programm-Bibliotheken nutzen kann. Neue Programm-Bibliotheken zu
portieren dürfte auch etwas schwierig sein. Die meisten Bibliotheken
sind leider nur im grauenhaften C-Quellcode verfügbar. Dies ist der
einzige Grund. Sonst würde ich mir C gar nicht erst antun.
Problem ist, dass man heutzutage nicht mehr alles neu schreibt, sondern
auf Bestehendes zurückgreifen muss. Weil man bei der Komplexität der
Programme sonst nicht mehr fertig wird. Siehe Webbrowser. Andernfalls
hätte ich auch !POP3S und !SMTPS nicht fertig gebracht.
Warum soll man auch immer wieder das Rad neu erfinden, wenn es schon
erfunden wurde. Warum schreibt nicht jeder für ein Programm ein neues
Betriebssystem?
*) Hinweis: Bei moderneren Betriebsystemen als das vom C64 kann man
nicht im gesamten Speicher lesen und schreiben.
Jow. Da sagt einem der Rechner, was man machen soll und darf. Habe ich
aba nicht so gerne... weil, ich bin ja ein Dickschädel. Und lasse mir
nicht gerne etwas sagen. Sondern möchte dem Rechner sagen, was er zu tun
hat.
Viel Spaß wenn Du in Deinen Programm in dem Speicher eines anderen
Programms rumschreibst. War das nicht das Problem von Windows bis Me?
Bei NT ging das nicht und schon war Windows stabiler - wenn auch immer
noch sch....
Herrliche neue Zeit.
Ich habe genug PHP Code von anderen Leuten gesehen um sagen zu können:
Nicht jeder der seine Finger auf einen Tastatur hauen kann, sollte
Programme schreiben. Diese würden auch hemmungslos Mist in den Speicher
eines anderen Programms schreiben und als Anwender flucht man dann über
das Betriebssystem und überhaupt.
Ich hoffe das Du nicht Informatik studiert hast. Wenn ja, wie heißt die
Hochschule?
Carlos Michael Santillán
--
http://www.arcsite.de/
http://www.risc-os.de/
Ein Staat, in dem alle verdächtig sind, ist selbst verdächtig
A state that suspects everyone is itself suspicious
