D vs. C++

Apfelbirne, ich denke nicht, dass deine Definition haltbar ist. Javascript kann man zu nativem Code kompilieren und C kann man interpretieren. Wo ziehst du die Grenze? Mit nur wenigen zusätzlichen Funktionen (z.B. readMemoryAt , writeMemoryAt ) hat JS vollen Hardwarezugriff.

Man kann sicherlich für eine gegebenen Sprache entscheiden, ob sie zum jetzigen Zeitpunkt für Systemprogrammierung geeignet ist, aber eine Schwarz-Weiß-Unterteilung in Systemprogrammiersprache oder nicht halte ich für naiv.

Zeus schrieb:

@Apfelbirne

Building and Running Singularity schrieb:

Getting Started
...
This document describes the steps to build the Singularity source code and boot your Singularity image into Virtual PC or real hardware.
...

Wenn man Gegenargumentiert sollte man, wenigstens sich mal die Sachen ansehen.

Und dazu noch etwas.

Schau mal, ob deine Spielerei, also dieses C# OS auch de nerweitereten AVX Befehlssatz nutzen tut!

Mit C, D, C++ kann ich das IMMER machen, wenn es der Compiler nicht kann, dann erlauben mir C, D und C++ Inline Assembler mit dem das geht.

Und jetzt probier das mal mit Java, C# oder Javascript, ohne auf extra APIs zuzugreifen die mithilfe von C & Co dafür programmiert wurden, um genau das zu können.

thread-leser schrieb:

Apfelbirne, ich denke nicht, dass deine Definition haltbar ist. Javascript kann man zu nativem Code kompilieren und C kann man interpretieren. Wo ziehst du die Grenze? Mit nur wenigen zusätzlichen Funktionen (z.B. readMemoryAt , writeMemoryAt ) hat JS vollen Hardwarezugriff.

Nutze AVX in Javascript ohne den Compiler dafür vorzubereiten.

dot

Apfelbirne schrieb:

Mit C, D, C++ kann ich das IMMER machen, wenn es der Compiler nicht kann, dann erlauben mir C, D und C++ Inline Assembler mit dem das geht.

Zeig mir bitte die Stelle im C++ Standard wo das steht.

Und noch etwas.

In der Systemprogrammierung muß es bei Bedarf auch möglich sein, Code zu schreiben, der eine vollständig bewiesene Fehlerfreiheit und harte echte Echtzeitfähigkeit liefern kann.

Mit C, D und C++ geht das (auch wenn ich bei Sicherheitskritischen Dingen eher Ada nehmen würde, aber es geht), bei Javascript mußt du dich auf die Javascript Laufzeitumgebung verlassen.

dot

Btw: http://en.wikipedia.org/wiki/PicoJava

dot schrieb:

Apfelbirne schrieb:

Mit C, D, C++ kann ich das IMMER machen, wenn es der Compiler nicht kann, dann erlauben mir C, D und C++ Inline Assembler mit dem das geht.

Zeig mir bitte die Stelle im C++ Standard wo das steht.

Du kannst in C++ Inline Assembler nutzen. Jeder gute C++ Compiler kann das.

In D ist das Schlüsselwort asm{} sogar Teil des Standards.

dot schrieb:

Btw: http://en.wikipedia.org/wiki/PicoJava

Hatte ich als Ausnahme schon genannt, siehe oben "Java µC".
Da inzwischen Tot, nicht der Rede wert.

Und wenn eine Sprache eine ganz spezielle HW braucht, damit man von Systemprogrammierung sprechen kann, dann ist das kein besonders gutes Zeichen, daß die Sprache zur Systemprogrammierung auszeichnen soll.

dot

Apfelbirne schrieb:

Du kannst in C++ Inline Assembler nutzen. Jeder gute C++ Compiler kann das.

Nö, MSVC z.B. kanns nur unter bestimmten Umständen. Aber inline Asm ist sowieso unwichtig.

Apfelbirne schrieb:

In D ist das Schlüsselwort asm{} sogar Teil des Standards.

Siehe auch:
http://www.d-programming-language.org/iasm.html

dot

Ja aber von AVX steht nix im Standard. Der Standard definiert nichtmal die Syntax von inline Asm, was inline Asm zu ner praktisch zu 100% unportablen Geschichte macht. Aber wie gesagt spielt inline Asm sowieso keine Rolle, also wen interessierts

dot schrieb:

Apfelbirne schrieb:

Du kannst in C++ Inline Assembler nutzen. Jeder gute C++ Compiler kann das.

Nö, MSVC z.B. kanns nur unter bestimmten Umständen. Aber inline Asm ist sowieso unwichtig.

MSVS Express Edition != MSVC Prof.

Kauf dir also mal ein richtiges und nicht abgespecktes und künstlich limitierstes MSVC.
Ich kann Inline Assembler in meinem MSVC jedenfalls nutzen.

_asm{}

http://msdn.microsoft.com/en-us/library/4ks26t93(v=vs.80).aspx

dot

Apfelbirne schrieb:

Ich kann Inline Assembler in meinem MSVC jedenfalls nutzen.

Nö kannst du nicht, lies die von dir verlinkte Seite mal aufmerksam durch...
Mit Express oder nicht hat das nix zu tun, alle Editionen von Visual Studio verwenden den selben Compiler.

dot schrieb:

Ja aber von AVX steht nix im Standard...

Warum sollte AVX im Sprachstandard stehen?

Es ist ein CPU spezifischer Befehlssatz und D erlaubt mir mit Hilfe von inline Assembler diesen Befehlssatz zu nutzen, wenn es die D Compilerimplementierung noch nicht kann.

Bei JAVA geht das z.B. nicht.
Hier rennt die JVM immer hinterher und inline Assembler ist in Java erst gar nicht möglich. (zumindest nicht ohne C Ausweichkonstrukte als API Hilfe)

Genau wegen solchen Sachen, ist C in der Systemprogrammierung ja immer noch führend und wurde nie von Java, C# und Co abgelöst.

dot schrieb:

Apfelbirne schrieb:

Ich kann Inline Assembler in meinem MSVC jedenfalls nutzen.

Nö kannst du nicht, lies die von dir verlinkte Seite mal aufmerksam durch...
Mit Express oder nicht hat das nix zu tun, alle Editionen von Visual Studio verwenden den selben Compiler.

Schön, wenn du das meinst:
"Inline assembly is not supported on the Itanium and x64 processors"

Und ich kann trotzdem immer noch einen separaten Assembler wie MASM oder NASM nehmen und dann von meinem C, C++ oder D Code den jeweiligen mit MASM oder NASM erstellten Objektcode verwenden.
Mach das mal mit Java.

dot schrieb:

Apfelbirne schrieb:

Du kannst in C++ Inline Assembler nutzen. Jeder gute C++ Compiler kann das.

Nö, MSVC z.B. kanns nur unter bestimmten Umständen. Aber inline Asm ist sowieso unwichtig.

In der Anwendungsentwicklung vielleicht, in der Systemprogrammierung ist Asm nach wie vor wichtig und manchmal sinnvoll.

dot

Apfelbirne schrieb:

dot schrieb:

Ja aber von AVX steht nix im Standard...

Warum sollte AVX im Sprachstandard stehen?

Darum gehts ja. Du läufst hier rum und behauptest du könntest mit C++ AVX nutzen, das ist aber natürlich Schwachsinn, weil AVX absolut nichts mit C++ zu tun hat. Auf die Tatsache dass nicht jeder Compiler inline Asm überhaupt erst unterstützen muss und dass es dafür schon gar keine einheitliche Syntax gibt, hab ich ja auch schon Hingewiesen. Wenn man z.B. bedenkt, dass Windows mit MSVC gebaut wird und MSVC inline Asm nur für eine einzige, mittlerweile unwichtige, Plattform unterstützt, dann fragt man sich schon wie wichtig inline Asm jetzt für diese "Systemprogrammierung" sein soll. Immerhin sitz ich vor einem 64bit Betriebssystem, das mit einem x64 MSVC gebaut wurde, der kein inline Asm unterstützt. Das bisschen ASM was man für ein OS tatsächlich braucht kann man auch gleich einfach durch nen richtigen Assembler jagen. Hat noch dazu den Vorteil dass der C++ Code portable bleibt und die richtig plattformspezifischen Dinge vom Buildsystem dazugelinked werden können...

dot schrieb:

Das bisschen ASM was man für ein OS tatsächlich braucht kann man auch gleich einfach durch nen richtigen Assembler jagen. Hat noch dazu den Vorteil dass der C++ Code portable bleibt und die richtig plattformspezifischen Dinge vom Buildsystem dazugelinked werden können...

Schön, dann nutze mal den Objekt- bzw Maschinencode der mit dem richtigen Assembler erstellt wurde, von Java aus.

dot

gern: http://de.wikipedia.org/wiki/Java_Native_Interface

Apfelbirne, du bist lustig und unseriös zugleich.

Du scheinst die Sprache D nicht über die Definition einer Systemsprache zu zu einer solchen zu machen, sondern du definierst "Systemsprache" als das was D verkörpert, was totaler Blödsinn ist.

Dir ist schon bewusst, dass man mit ein paar entsprechenden Handgriffen theoretisch in jeder Sprache Betriebssysteme bauen kann wenn man will? Und wo ziehst du die Grenze wie viele Handgriffe erlaubt sind? Du ziehst die Grenze genau da, wo D noch zu Systemsprachen gehört und Java nicht mehr. Völliger Unsinn.

Da man theoretisch alles mit jeder Sprache machen kann, ist es unsinnig über "theoretisch wäre <XYZ> möglich..." zu argumentieren.

Sinnvoller wäre es eine Systemsprache als solche dann zu bezeichnen, wenn darin (in der entsprechenden Sprache) wirklich im erwähnenswerten Ausmaß (also nicht nur Einzelfälle/einzelne Experimente) Betriebssysteme entwickelt werden.
Das wäre eine realitätsnahe Definition und frei von Grauzonen.

Und wenn man danach geht, was wirklich ist, dann endet die Suche bei C.