Kann man sich eigene Statement´s programmieren?

[str1442]

Da alles etwas aus dem Ruder gelaufen ist, fasse ich kurz nochmal zentral alles gesagte zusammen:

1. Jede Sprache kann eine API haben, auf die man zugreifen kann. Inwieweit man auf sie zugreifen kann, hängt von der Sprache ab.

2. Mithilfe von Anweisungen: Das ist möglich und kann helfen, das Aussehen der Sprache zu "generalisieren". Andererseits sind sie irgendwo einschränkend und nicht unbedingt von Sinn.

3. Ohne Anweisungen, dafür mit dieser eigenen API. Etwa durch Exception Objekte usw.

4. Diese API für die Sprache ist in dieser Sprache selber implementiert. Die Sprache, auf der diese Sprache basiert, kommt nicht ins Spiel.

Sofern das soweit richtig ist:

1. Die Sprache legt eine Struktur fest, in die sich in ihr geschriebener Quellcode einzuordnen hat. Zum Beispiel durch Funktionen, Klassen, Objekte. Keines dieser Konstrukte muss aber existieren und es kommt auf die Sprache an. Irgendwo ist üblicherweise dann ein Übergang zu der Sprache, in der diese Sprache geschrieben wurde, auf den man nur über die Sprachapi zugreift (oder Anweisungen) zugreift.

2. Logik existiert erstmal nur in den Köpfen der Entwickler. Diese muss dann in die Struktur der Sprache gebracht werden (zb indem man Funktionen definiert). Diese wiederrum kann aus anderen Konstrukten der Sprache bestehen (zb Klassen), womit sich am Ende eine Grundessenz der API der Sprache oder deren Statements ergibt.

3. Statements sind also die kleinsten Teile einer Sprache. Sie sind *nicht* außerhalb der Logik, aber die *richtige* Logik wird durch die Struktur der Sprache *und* ihren Anweisungen / ihrer API bestimmt.

Die API kann also zb soetwas wie in Io sein. Wichtig ist nur, das die API von der eigenen Sprache voll zugänglich ist.

Soweit das stimmt:

1. Anweisungen / API sind ihrerseits in der Sprache oder in der Sprache, in der die eigentliche Sprache geschrieben wurde, implementiert. Somit muss sich diese Sprache in die Struktur ihrer "Muttersprache einfügen." Diese wiederrum benutzt selber Anweisungen und / oder eine API.

2. Das geht immer so weiter, bis man auf (fast) Hardware Ebene ankommt.

3. Dort nun wiederrum muss man sich in die Struktur der CPU einfügen, die so direkt wohl nur eine sehr einfache kennt. Das Benutzen dieser Struktur mittels Maschinencode geschieht mittels Anweisungen an die CPU, die dann auf Hardwareebene ausgeführt werden.

Wäre diese Anweisung nun eine Funktion, hätte die CPU selber eine Struktur und mindestens eine Art Funktion definiert. Wo soll die herkommen? Ansonsten könnte man soetwas sogar als Funktion ansehen, die den kompletten Status der CPU erhält und verändert zurückgibt. Aber das ist wohl nur theoretisch so.

Conclusion:

1. Statements sind auf CPU Ebene vorhanden, was auch immer sie nun genau sind.

2. In höheren Sprachen sind Statements allerhöchstens dazu gut, um Sprachfeatures auf diese Art und Weise zugänglich zu machen. Alternativ kann man eine API definieren und dort auf die Sprache zugreifen. Zugriff auf die Sprache, in der die Sprache implementiert ist, ist *nicht* möglich.

3. Jede Sprache definiert eine Logikstruktur, und Funktionen sind Teil dieser Logikstruktur. Die Logik selbst ist vielseitig, und die genaue Umsetzung kann mittels verschiedener, eventuell speziellen Sprachstrukturen variieren. Den kleinsten Teil der Logik bildet die API der Sprache oder aber die Statements, mit deren Hilfe aus sie zugegriffen wird.

4. Funktionen sind Teil einer Sprache als Logikstruktur. Anweisungen sind in höheren Sprachen eher sinnlos, da man alles in ihrer eigenen Logik Struktur abbilden könnte.

5. Funktionen sind nichts allumfassendes, sondern eine Sprachstruktur und vom Sprachdesign abhängig. Anweisungen sind allerdings zumindest in niedrigeren Sprachen, weil vorgegeben durch die Hardware, da. Insofern ist die Trennung zwischen Funktion / Statement *innerhalb* einer höheren Sprache sinnlos, bei Hardwarenahen Sprachen dagegen nicht. *Auf alle Sprachen* angewandt sind Funktionen Teil der einzelnen Sprachstruktur, während zumindest die CPU Anweisungen überall vorhanden sind. Irgendwo.


Insofern habe ich meine Sichtweise auch geändert. Das man Statements klar von Funktionen trennen kann, ist wahr, wenn man alle Statements anschaut. Sind ja in vielen Sprachen vorhanden. Insofern mag es in Python nicht zutreffend sein, das man da unterscheiden kann, da es aber zb das return Statement ja auch in C gibt, stellt sich hier die Frage, wie stark in C ein Statement mit einem "Hardware-Statement" verbunden ist. Insofern habe ich falsch pauschalisiert.

Funktionen sind allerdings Strukturen einer Sprache, und solche Strukturen ändern sich von Sprache zu Sprache. Irgendwo, und sei es nur im Ausgeführten Code, sind aber die "CPU Statements".


@all

Durch die Zusammenfassung ist hoffentlich klarer geworden, inwiefern ich meine Argumentation geändert habe, und was ich mit der Logikstruktur usw meinte. Durch die langen Texte habe ich mich da ein wenig verrannt.

@Leonidas:

Also kann man sagen, das grundlegende Befehle praktisch in die CPU "reingegossen" werden? Gut, das war ja vorher klar, aber das es doch so umfangreich zu sein scheint (bisher dachte ich, rechnen mittels Dual System und "Register" seien so ziemlich das einzige), habe ich nicht erwartet. Das Dokument ist ganz gut zum (großzügig) durchblättern, um den Gesamtzusammenhang zu verstehen. Insofern ist eine CPU ja wirklich nur das direkte (und da war ich mir vorher nicht sicher) Hardware Aquivalent zu Assembler, das mittels EVA Prinzip seine vielen kleinen Transistoren an oder aus schaltet, und dabei bei Konstellation xy z auslöst. Danke.

[BlackJack]

@str1442: Du hättest mit Unternummerierungen arbeiten sollen, bei den vielen Listen die immer wieder mit 1. beginnen. Ich nummeriere die Listen in Gedanken nochmal römisch durch.

zu II.3.: Statements kann man IMHO nicht als die kleinsten Teile einer Sprache bezeichnen, da sie wie zum Beispiel ``class`` in Python sehr komplexe Dinge erzeugen können. Als kleinste Teile würde ich eher Sachen beschreiben, die man so nicht mehr in der Sprache selber schreiben könnte, also zum Beispiel die Operationen auf den Grunddatentypen wie die Rechenoperationen auf `float`\s. Also man könnte natürlich eine Klasse basteln, die `float` mit `int`\s implementiert, aber eben nicht die IEEE-Hardware-Fliesskommazahlen. Ich hoffe es ist klar was ich meine.

zu IV.2.: Es gibt durchaus Hochsprachen, bei denen man auf tiefere Schichten durchgreifen kann. Zum Beispiel kann man in (Turbo|Borland|Free)Pascal und D auch direkt im Quelltext Assembler einflechten.

CPUs sind auch nicht mehr so einfach wie sie mal waren. In modernen CISC-CPUs werden die CISC-Befehle oft intern nochmal in Mikrocode umgesetzt, der aus einem RISC-Befehlssatz besteht. Bei einigen Prozessoren kann man Mikrocodeprogramme in den Prozessor laden, beim Crusoe von Transmeta muss man das sogar tun, damit der Prozessor weiss was er tun muss/kann. Der CPU-Interne "Compiler" kann auch Befehle eigenständig in der Reihenfolge umsortieren wenn dadurch die verschiedenen Recheneinheiten besser ausgelastet werden und ein höherer Befehlssatzdurchsatz dadurch erreicht werden kann.

[Leonidas]

Also kann man sagen, das grundlegende Befehle praktisch in die CPU "reingegossen" werden?

Jein. Ab einer bestimmten Stelle schon aber das muss nicht die Maschienensprache sein. Wie BlackJack sagte betreiben viele CISC-CPUs unter anderem die üblichen Desktop-CPUs von Intel eine weitere Rekompilation intern, wobei die komplexen CISC Befehle dann gegen mehrere, einfachere RISC-Befehle ausgetauscht werden. Wenn du dir ansiehst, wie viele Möglichkeiten es gibt bestimmte Statements wie MOV zu nutzen (32-Bit Register nach Memory, Memory nach 32 Bit Register, 32 Bit Register in 32 Bit Register, das ganze nochmal mit 16 Bit und nochmal mit 8 Bit, und dann noch einige weitere Fälle) gibt das allein bei MOV schon viele Möglichkeiten. Wie es nun intern abläuft weißt du nicht und kannst darauf zumindest bei x86 keinen Einfluss haben. Die Intel-Manuals sagen dir aber dass MOV diesen und jenen Effekt hat. Wie das dann intern ausssieht, ob das jetzt in irgendeine Pipeline gesteckt wird oder ob auf den vorherigen Befehl gewartet werden muss weil du Datenabhängigkeiten hast, dass kann dir als Assembler-Programmierer egal sein. Wenn die CPU etwas in bestimmten Fällen nicht so auswertet wie angegeben ist das ein Bug.

Gut, das war ja vorher klar, aber das es doch so umfangreich zu sein scheint (bisher dachte ich, rechnen mittels Dual System und "Register" seien so ziemlich das einzige), habe ich nicht erwartet. Das Dokument ist ganz gut zum (großzügig) durchblättern, um den Gesamtzusammenhang zu verstehen.

Ja, ich wollte eigentlich das aktuelle Manual verlinken habe die aktellere Version aber auf die Schnelle nicht gefunden. Wäre aber auch unnötig komplex gewesen, da dort dann auch RAX & Co, also die x86_64-Sachen auch noch drin wären, die nur von geringem Interesse sind.

Insofern ist eine CPU ja wirklich nur das direkte (und da war ich mir vorher nicht sicher) Hardware Aquivalent zu Assembler, das mittels EVA Prinzip seine vielen kleinen Transistoren an oder aus schaltet, und dabei bei Konstellation xy z auslöst.

Sie gibt sich als sowas aus, ber mittels interner Optimizationen ist das nicht unbedingt der Fall. Das ist wie bei einem Compiler der etwa rekursive Aufrufe intern in Schleifen umwandelst, du aber davon nichts mitbekommst.

[str1442]

zu II.3.: Statements kann man IMHO nicht als die kleinsten Teile einer Sprache bezeichnen, da sie wie zum Beispiel ``class`` in Python sehr komplexe Dinge erzeugen können. Als kleinste Teile würde ich eher Sachen beschreiben, die man so nicht mehr in der Sprache selber schreiben könnte, also zum Beispiel die Operationen auf den Grunddatentypen wie die Rechenoperationen auf `float`\s. Also man könnte natürlich eine Klasse basteln, die `float` mit `int`\s implementiert, aber eben nicht die IEEE-Hardware-Fliesskommazahlen. Ich hoffe es ist klar was ich meine.

Gut, könnte man sagen. Allerdings meinte ich an der Stelle die API der Sprache (wovon man die grundlegensten Dinge, wie auch in Python, als Statements abbilden kann), habe wohl beim Schreiben zu schnell gedacht.

zu IV.2.: Es gibt durchaus Hochsprachen, bei denen man auf tiefere Schichten durchgreifen kann. Zum Beispiel kann man in (Turbo|Borland|Free)Pascal und D auch direkt im Quelltext Assembler einflechten.

Ja, aber diese Abschnitte werden ja vom jeweiligen Kompiler praktisch assembliert und "dazugelinkt". Ich meinte den Zugriff über die Struktur der Sprache hinweg. Also wenn ich in Python über ein MagicObject plötzlich auf C zugreifen könnte, und dann im Python Quellcode in einer Struktur schreibe, wie C sie festlegt (und auch C Obje... äh... Strukturen? benutzen könnte). Damit würde ich ja alle Strukturierungen von Python quasi komplett abschalten können. Deswegen muss man ja den Umweg über ctypes / Cython gehen, und erst Objekte in C designen, die sich dann in die Strukturierung von Python einfügen lassen (per import).

@CPU's: Alles klar, dank euch.

[BlackJack]

@str1442: Also mit `ctypes` kann man schon ganz gut in den Interna von CPython rumpfuschen. Man hat damit freien Zugriff auf die `libpython.(so|dll)`.

Die Beschreibung "assembliert und vom Kompiler dazugelinkt" würde ich bei den genannten Pascal-Varianten und D nicht verwenden. Das klingt nach getrennten Object-Dateien. Der Assemblerquelltext kann da aber tatsächlich mitten in einer Funktion oder Prozedur zwischen Quelltext in den Sprachen stehen und man hat auch Zugriff auf die in Pascal bzw. D deklarierten Variablen.

[str1442]

@str1442: Also mit `ctypes` kann man schon ganz gut in den Interna von CPython rumpfuschen. Man hat damit freien Zugriff auf die `libpython.(so|dll)`. Smile

Oha, gut, das ist natürlich nett. Sollte man aber sicher nicht fahrlässig nutzen

Die Beschreibung "assembliert und vom Kompiler dazugelinkt" würde ich bei den genannten Pascal-Varianten und D nicht verwenden. Das klingt nach getrennten Object-Dateien. Der Assemblerquelltext kann da aber tatsächlich mitten in einer Funktion oder Prozedur zwischen Quelltext in den Sprachen stehen und man hat auch Zugriff auf die in Pascal bzw. D deklarierten Variablen.

Joa, aber solang man nicht anfängt, wild auf zig Registern zu operieren, ist der Assemblercode recht gut abgegrenzt. Würde man das nämlich machen, würde man man mithilfe einer hardware-näheren Sprache die spracheigene Strukturierung umgehen. Das macht dann vermutlich weniger Spaß

@Io:

Hab mir die Sprache mal angeschaut, und bin ziemlich begeistert. Hab mir daraufhin mal den Guide angeschaut, und war da auch ziemlich schnell durch. Einzig manche der Methoden (bzw Message) Namen finde ich ein wenig aus der Reihe fallend bis willkürlich (zb bei Range das to(x)), aber ansonsten hört sich das alles sehr nett an. Viele der Funktionen scheinen Python Funktionen zu ähneln ('"Test String" split join("\n") println' hat auf Anhieb geklappt, oder strip etc), gibt auch ein Python Addon, wobei das undokumentiert ist. Schade nur, das sich google & co zu "Io Language" nicht bemühen lässt . Vielleicht mal mit einer Metasuchmaschine probieren.

ADD: Grade getestet: Yahoo lässt Suchen auf Wörter mit weniger als 3 Wörtern zu.

[sma]

Zu Io siehe auch meine Version in Python.

Ansonsten: Das "1 to(10)" um ein Range-Objekt zu erzeugen, stammt von Smalltalks "1 to: 10" und "1 to: 10 do: aBlock", was sich doch recht gut liest. Bei Io ist die Syntax etwas uniformer, da muss man eben Klammern benutzen.

Stefan

[Y0Gi]

Bleibt nur noch die Frage, an was du nachts um zwei gedacht hast, wenn dieses Wort den Weg in dein Posting gefunden hat Ich glaube jetzt einfach mal, dass es nur eine fehlgeleitete Übersetzung des englischen Silicone war

Freud lässt grüßen

Aber *wenn* es eine naheliegende fehlgeleitete Übersetzung eines englisches Wortes war, dann wohl von "silicon" und nicht "silicone" *in Haarspalter-Reihe anstell*


Und wo ich schon mal hier bin, gebe ich noch den Link zum Besten, wegen dem ich überhaupt in dieses Thema geschaut habe: Ingredients for building a DSL in Python (Episode I).

[lunar]

Aber *wenn* es eine naheliegende fehlgeleitete Übersetzung eines englisches Wortes war, dann wohl von "silicon" und nicht "silicone" *in Haarspalter-Reihe anstell*

D'oh ... freud'scher Verschreiber