Programmiersprachen/Umgebungen

[Euklid]

Binwriter (interner Assembler) gibts schon für i386-linux

... und der sorgt dafür, dass unter Linux Smart Linking funktioniert?

[Socke]

Binwriter (interner Assembler) gibts schon für i386-linux

... und der sorgt dafür, dass unter Linux Smart Linking funktioniert?

ld kann zumindest Smartlinking. Für mein Lazarus (ca. 15 Megabyte) braucht es da etwa 1,7 Gigabyte RAM . Wie das hier aussieht müsste ich mal testen.

Den FPC kann man nicht bootstrappen. Man kann ihn nur kompilieren, wenn man einen FPC da hat.
Hat man keinen, könnte man es mit Delphi oder so versuchen.
Ein C Compiler wird aber immer da sein, also könnte man sich zur Sicherheit immer ein automatisch übersetztes C-Programm vom FPC aufheben, schon kann man in jede neue Plattform portieren.

Bootstrappen heißt doch soviel wie einen neuen Compiler aus den Quellen erzeugen und nicht einen Compiler mit dem gcc übersetzen. Wenn du willst kannst du mit allein mit TurboPascal zum aktuellen FPC kommen.
Und wer garantiert dir, dass immer ein C-Compiler da ist? Ich hab den bei mir auch selbst installiert und unter Windows ist gar kein Compiler dabei. Also ists am Ende wieder der Anwender, der dafür sorgen muss, dass der gewünschte Compiler da ist.

[carli]

Den FPC kann man nicht bootstrappen. Man kann ihn nur kompilieren, wenn man einen FPC da hat.
Hat man keinen, könnte man es mit Delphi oder so versuchen.
Ein C Compiler wird aber immer da sein, also könnte man sich zur Sicherheit immer ein automatisch übersetztes C-Programm vom FPC aufheben, schon kann man in jede neue Plattform portieren.

Bootstrappen heißt doch soviel wie einen neuen Compiler aus den Quellen erzeugen und nicht einen Compiler mit dem gcc übersetzen. Wenn du willst kannst du mit allein mit TurboPascal zum aktuellen FPC kommen.
Und wer garantiert dir, dass immer ein C-Compiler da ist? Ich hab den bei mir auch selbst installiert und unter Windows ist gar kein Compiler dabei. Also ists am Ende wieder der Anwender, der dafür sorgen muss, dass der gewünschte Compiler da ist.

Wenn du beim Urschleim bootstrappen willst, würdest du zuerst ein Betriebssystem von Hand in Assembler schreiben und es dann von Hand übersetzen. Anschließend wäre der C-Compiler dran.
Aber wenn du beim Urschleim anfangen willst, kannst du gleich wieder aufhören, das ist zu aufwändig.
Was ich damit sagen will: Du wirst auf einer XYZ-Plattform keinen fertigen FPC haben, um dir den FPC zu kompilieren. Die Wahrscheinlichkeit, dass eine Plattform einen C-Compiler hat ist nahezu 100% (und dass Windows keinen mitliefert, sollte in Zeiten des Internet kein Problem mehr sein)

[marcov]

würde meiner Meinung nach voll ausreichen (der einen Gesamtprogramm-C-Code erzeugt), da eine neue eingebettete Plattform meistens nur mit einem C-Compiler "begehbar" ist.

Und was wann man das Pascal programm nicht als C code ausdrucken kann?

Sowohl Pascal als auch C sind Turing-Vollstängig. FAIL

Und du hast ein Machine mit unendliches Speicher, und undendlich Zeit? FAIL!

(und das ist sowieso Quatsch, weil Turing nur ein Execution Model ist, und nichts über sagt source 2 source Konversion sagt. Es ist wie zu sagen: "man kann diese Dingen beiden in kleine Stückchen erschlagen (zb Atome), darum sind sie Äquivalent". Das ist nicht so, man muss dafür auch das wiederherstellen von B aus atomen von A beherrschen, und das kann nicht trivial sein)

Ich denke FPC bootstrappen ist einfacher als GCC bootstrappen. Also ich weiß nicht was sie hier mit meinen.

Den FPC kann man nicht bootstrappen.

Natuerlich. Habe ich schon erklärt in dieser Post. TP->alte FPC versionen -> heutige FPC Versionen.

Man kann ihn nur kompilieren, wenn man einen FPC da hat.

Wie kompilierst du denn gcc ohne eine C compiler?

Hat man keinen, könnte man es mit Delphi oder so versuchen.

Ein C Compiler wird aber immer da sein,

Ein vielleicht schon. Aber kennst du wirklich einer der gcc gebootstrapt hat mit nicht gcc? Es gibt da viel Theorien, aber wenig praktisches oder etwas was zu kontrollierbar (und nach 2000) ist.

Auch die gcc/Linux Leute nutzen Crosscompiling, nicht bootstrapping.

also könnte man sich zur Sicherheit immer ein automatisch übersetztes C-Programm vom FPC aufheben, schon kann man in jede neue Plattform portieren.

Das nur Theorie. Solche dingen funktionieren nicht als die nicht praepariert sein. Und auch die Komplexität ist ein Problem. Die bootstrap-Theorien stammen aus das frühe 1980er sogenanten Computer Mittelalter, als Compiler noch 20-30000 Zeilen waren. Jeder kennte sie, weil sie in allen Textbooks stehen. Aber keiner hat Praxis informationen. Eben mit Solaris kommt eine ganze GNU Toolchain mit, so das man so etwas nicht mit Solaris kompiler versuchen muss

[marcov]

Binwriter (interner Assembler) gibts schon für i386-linux

... und der sorgt dafür, dass unter Linux Smart Linking funktioniert?

ld kann zumindest Smartlinking. Für mein Lazarus (ca. 15 Megabyte) braucht es da etwa 1,7 Gigabyte RAM . Wie das hier aussieht müsste ich mal testen.

Das liegt etwas komplizierter:

(1)
- LD kontte "damals" (1997-1998 oder so) keines Smartlinking (kein --gc-sections usw)
- ld hatte aber ein Funktion um nicht gebrauchte "modul" (.o) Sections nicht zu linken als die nicht erreichbar sind.
- -> um effectiv Smartlinking zu nutzen macht FPC ein "modul" Section per Symbol. Das tut es immer noch.
- Die modul Sections von einem unit (viele .o's bis hunderttausend pro Unit) werden mit AR zu .a Archiv kompiliert

(2)
- Es gab kaum etwas GNU was funktionierte auf Windows.
- Der Windows Header war gigantisch groß.
- Alle FPC programma hätten ein dependancy auf _alle_ funktionen in Windows, weil es kein Smartlinking von Windows gab.
- das gab allerlei Probleme (Windows konnte keine Funktionen haben die es auf originelles Win95 nicht gab usw)
- -> Windows würde verpflicht Smartlinking gemacht im makefile

Das Problem war das das alles sehr langsam war. (und große Windows Binaries generierte). Auf Linux war das weniger ein Problem, aber auf Windows doppelt oder eben dreifach:

(1) Windows ist relativ langsam um Binaries zu starten.
(2) as --pipe funktionierte nicht -> mann muss .s alles nach Disk schreiben, und danntausende male AS anrufen, und dann alle tausende .o's pro Unit wieder lesen mit AR usw)
(3) der Windows Unit war besonders groß.

Also darum ist der Windows Binwriter geschaffen. Der macht die AS und AR Stufen innerhalb der ppc386 Binary, und das ist eine menge flotter. (kein schreiben/lesen mehr oder tausend mal as.exe starten )

Später (2005-2007) kam Lazarus richtig auf Dampf, und LD wurde immer langsamer um Lazarus zu linken. Ein bisschen logisch, weil LD nie für Millionen .o optimiert wurde. Es nutzte auch sehr viel Speicher dafür (bis 1.5 GB um ein Lazarus völlig zu smartlinken)

Da kam der interner Linker zur Tisch. Der macht das in ein drittel oder viertel der Zeit und mit nur 200MB.

(noch später)
Mit win64 dauerte es sehr lang bis es 64-bit mingw binaries gab. Jemand hat dann ein binwriter/linker für win64 gemacht, und deshalb gab es FPC früher als gcc auf win64. (das gibt auch an das der Porting/bootstrap theorie aus IT Anfänger Textbooks nicht dasselbe ist als das auch Praktisch machen, weil es ein C compiler (MSVC) auf win64 gab)

[mschnell]

einen komplett neuen Kernel plant,

Das hört sich ja hochgradig blödsinnig an. Wenn der neue Compiler die vorhandenen Kernel Sources nicht korrekt übersetzen kann, muss er überarbeitet werden und nicht der Sourcecode angepasst werden. Es wäre schon tödlich, wenn man die Make-Files ändern muss.

-Michael

[carli]

einen komplett neuen Kernel plant,

Das hört sich ja hochgradig blödsinnig an. Wenn der neue Compiler die vorhandenen Kernel Sources nicht korrekt übersetzen kann, muss er überarbeitet werden und nicht der Sourcecode angepasst werden. Es wäre schon tödlich, wenn man die Make-Files ändern muss.

-Michael

http://code.google.com/p/llvm-kernel/" onclick="window.open(this.href);return false;
lies selbst.

(und das ist sowieso Quatsch, weil Turing nur ein Execution Model ist, und nichts über sagt source 2 source Konversion sagt. Es ist wie zu sagen: "man kann diese Dingen beiden in kleine Stückchen erschlagen (zb Atome), darum sind sie Äquivalent". Das ist nicht so, man muss dafür auch das wiederherstellen von B aus atomen von A beherrschen, und das kann nicht trivial sein)

Die Turing-Maschine ist ein Berechnungsmodell und sie sagt uns lediglich, dass es keine turing-vollständige Sprache gibt, die mehr Probleme lösen kann als eine andere turing-Vollständige Sprache.
Deine Aussage war aber, dass Pascal Probleme lösen kann, die C nicht lösen kann. Du blamierst dich mit der Aussage.

Natuerlich. Habe ich schon erklärt in dieser Post. TP->alte FPC versionen -> heutige FPC Versionen.

Ja, Pascal ist nicht standardisiert und deshalb muss man versionsweise durchsteppen, um den FPC zu bootstrappen.

Wie kompilierst du denn gcc ohne eine C compiler?

Hier auch wieder: es geht nicht darum, was geht und was nicht geht, denn das mal weitergesponnen können wir gleich den FPC von Hand in Maschinencode übersetzen. Es geht aber sehr wohl darum, wie ich schnellstmöglich, wenn ich meinen Compiler mehr habe, mit fremder Hilfe den schnellstmöglichst wieder kompiliert bekomme. (oder auf eine neue Plattform gebracht). Und da ist ein C-Zwischencode seehr praktisch aus obig genannten Gründen.

[Socke]

Was ich damit sagen will: Du wirst auf einer XYZ-Plattform keinen fertigen FPC haben, um dir den FPC zu kompilieren. Die Wahrscheinlichkeit, dass eine Plattform einen C-Compiler hat ist nahezu 100% (und dass Windows keinen mitliefert, sollte in Zeiten des Internet kein Problem mehr sein)

Ich verstehe leider nicht, wo der Unterschied zwischen einen Compiler aus dem Internet herunterzuladen und einen Compiler aus dem Internet herunterzuladen.
Fakt ist: Ein Compiler gehört nicht zum Betriebssystem. Es mag zwar sein, dass es Linux-Distributionen gibt, die gcc per Standard installieren, aber er übernimmt per Definition keine Betriebssystemaufgaben (beim LLVM-Kernel mag das anders sein).
Die Wahrscheinlichkeit, dass überhaupt ein Compiler vorhanden ist, mag ich nicht abschätzen. Unter einer Windows-Standardinstallation strebt sie aber wohl gegen Null, wie du richtigerweise sagst. Wenn ein beliebiger Compiler vorhanden ist, ist natürlich die Wahrscheinlichkeit ungemein höher, dass es ein C-Compiler anstatt eines Pascal-Compilers ist. Das liegt aber nicht daran, dass es ein C-Compiler ist, sondern daran, dass er die Sprache "C" unterstützt. Sie ist eben viel weiter verbreitet als Pascal.

Natuerlich. Habe ich schon erklärt in dieser Post. TP->alte FPC versionen -> heutige FPC Versionen.

Ja, Pascal ist nicht standardisiert und deshalb muss man versionsweise durchsteppen, um den FPC zu bootstrappen.

Es gibt auch Pascal-Standards, aber keinen produktiven, modernen Compiler, der diese voll unterstützt.
Unter C habe ich aber ein ähnliches Problem, wenn ich verschiedene Sprachstandards nutze. Mit einem ANSI-C-Compiler kann ich kein Programm übersetzen, dass C99 verwendet. Also auch nichts anderes als bei Pascal.

[marcov]

(und das ist sowieso Quatsch, weil Turing nur ein Execution Model ist, und nichts über sagt source 2 source Konversion sagt. Es ist wie zu sagen: "man kann diese Dingen beiden in kleine Stückchen erschlagen (zb Atome), darum sind sie Äquivalent". Das ist nicht so, man muss dafür auch das wiederherstellen von B aus atomen von A beherrschen, und das kann nicht trivial sein)

Die Turing-Maschine ist ein Berechnungsmodell und sie sagt uns lediglich, dass es keine turing-vollständige Sprache gibt, die mehr Probleme lösen kann als eine andere turing-Vollständige Sprache.
Deine Aussage war aber, dass Pascal Probleme lösen kann, die C nicht lösen kann. Du blamierst dich mit der Aussage

Nein, das was du darin lesen willst. Pascal in C umsetzen, und mit entweder Pascal oder C dieselbe Problemen loesen die in dieselbe reducierbare Representation ablaufen sind zwei unterschiedliche dingen.

Natuerlich. Habe ich schon erklärt in dieser Post. TP->alte FPC versionen -> heutige FPC Versionen.

Ja, Pascal ist nicht standardisiert und deshalb muss man versionsweise durchsteppen, um den FPC zu bootstrappen.

C ist schon standariert, aber was ich versuche zu sagen ist das das nicht notwendig genug ist um das das einwandfrei zu lassen klappen. Auch C Compiler Leute Crosscompilen typisch, und nutzen nicht der System kompiler.

Nur in Academische Experimenten funktioniert das so.

Wie kompilierst du denn gcc ohne eine C compiler?

Hier auch wieder: es geht nicht darum, was geht und was nicht geht, denn das mal weitergesponnen können wir gleich den FPC von Hand in Maschinencode übersetzen. Es geht aber sehr wohl darum, wie ich schnellstmöglich, wenn ich meinen Compiler mehr habe, mit fremder Hilfe den schnellstmöglichst wieder kompiliert bekomme. (oder auf eine neue Plattform gebracht). Und da ist ein C-Zwischencode seehr praktisch aus obig genannten Gründen.

Ja. Aber der unterschied ist das im Praxis so nicht funktioniert. Auch nicht mit C. Als du denkst ein Kompiler suchen ist der gröbsten Aufwand, dann bist du Falsch. Aber es wird interessant wenn du etwas Beweis für deine Stellungen produciert. Also das das Heute tatsachlich so getan wird. (zb wie ich oben erwahnte das es zb mit gcc auf der damals neue x86_64 Architectur so NICHT passiert ist.

[knight]

Ich sehe es immernoch nicht kommen das Java/.net/Visual Basic jemals die Rechentechnik erobern.

http://www.golem.de/1106/83981.html" onclick="window.open(this.href);return false;

Da ist Christian wohl nicht der einzige.

knight

[marcov]

Ich sehe es immernoch nicht kommen das Java/.net/Visual Basic jemals die Rechentechnik erobern.

http://www.golem.de/1106/83981.html" onclick="window.open(this.href);return false;

Da ist Christian wohl nicht der einzige.

knight

Das ganze Windows 8 hoert sich an ob es nur ein Rewrite von der Sidebar ist mit was modieuzen Techniken wie Javascript und Touch* herein gemischt.

Und wer nutzt den Sidebar wirklich?

[MAC]

Ich, ich hab 1 einziges, aber nützliche CPU-Last anzeige

Wobei das ganze Java-zeug ja einfach viel zu stark von der Umgebung abhängig ist.
Man muss sicherstellen, dass Java installiert ist,welche version...

[Socke]

Ich, ich hab 1 einziges, aber nützliche CPU-Last anzeige

Wobei man das in der Regel nicht sieht, wenn die sechs Kerne wirklich ausgelastet sind , viel interessanter finde ich eh die GPU-Temperatur, aber dazu gibts keine Anzeige (außer irgendwo versteckt im Treiber)

Wobei das ganze Java-zeug ja einfach viel zu stark von der Umgebung abhängig ist.
Man muss sicherstellen, dass Java installiert ist,welche version...

Ich habs bisher bis auf zwei drei Einzelfälle nicht geschafft, beliebige Java-Anwendungen unter Windows auszuführen, und unter Linux ist das auch so eine Sache mit den verschiedenen Implementierungen.

[carli]

Ich, ich hab 1 einziges, aber nützliche CPU-Last anzeige

Wobei man das in der Regel nicht sieht, wenn die sechs Kerne wirklich ausgelastet sind , viel interessanter finde ich eh die GPU-Temperatur, aber dazu gibts keine Anzeige (außer irgendwo versteckt im Treiber)

Also bei mir ist die GPU-Temperatur ganz normal bei den Sensoren dabei und ich lasse mir die Temperatur auch im Panel anzeigen.

[mschnell]

http://www.golem.de/1106/83981.html

Die letzten Zuckungen eine sterbenden OS.

-Michael