Nachrichten

1

Lowlevel-Coding / Re: ARM Timer-IRQ

« am: 30. August 2013, 21:33 »

Bei anderen Exceptions mit dem selben Befehl, aber anderem op2.
#8 bei Data Abort, #4 bei FIQs u. IRQs und #0 bei Prefetch Abort und Undefined instruction.
Wegen der Pipeline muss man ggf. eine oder zwei Befehle abziehen, das S-bit des Befehls kümmert sich darum,
dass mov cpsr, spsr GLEICHZEITIG stattfindet.
Mit einem Debugger kannst du ja mal an 0x18 einen Breakpoint setzen und dir SPSR anschauen.

Edit:

- Wenn ein IRQ auftritt, werden R15 (PC) nach R14 und CPSR nach SPSR gesichert.

Genauer: lr des Prozessormodus. Bei IRQ R14_irq, bei FIQ R14_fiq, bei Undefines Instruction R14_und usw.

- In CPSR wird das I-Flag deaktiviert, d.h. IRQs abgeschaltet, und dann in die ISR gesprungen.

Und bei FIQs zusätzlich noch FIQs abgeschaltet.

2

Lowlevel-Coding / Re: ARM Timer-IRQ

« am: 30. August 2013, 14:20 »

Nein, bloß nicht!
Wenn der IRQ zu schnell kommt schmierts ab.
Auch macht es keinen Sinn einen IRQ nur halb zu behandeln, was passiert wenn der interrupt ausgelöst wird während die CPU sich noch im Handler befindet.
Wenn der Handler mehr Zeit braucht als der IRQ ist deine CPU zu lahm für das, was du tun willst.
Ganz sicher, dass du nicht vergessen hast, den IRQ auch zu acken?

3

Lowlevel-Coding / Re: ARM Timer-IRQ

« am: 29. August 2013, 14:35 »

Ich aktiviere IRQs erst wieder, wenn ich aus dem Handler herausspringe.
subs pc, lr, #4 kopiert spsr ja wieder in cpsr. Da IRQs vor dem IRQ ja aktiviert waren werden sie so wieder aktiviert.
Wenn du es dem Prozessor ermöglichst, den IRQ-Handler während des IRQ Handlers aufzurufen, wirst du nie mehr zu deinem Programm zurückkehren können, da lr dann überschrieben wurde.

4

Lowlevel-Coding / Re: ARM Timer-IRQ

« am: 24. August 2013, 16:45 »

Es gibt mehrere Möglichkeiten, 0xc00 zu assemblieren. Immediate values dürfen maximal 0xFF sein, allerdings können sie nach belieben geshiftet werden. Um das zu bestätigen, probier mal mov r0, #0x1ff aus. Da 0x1ff nicht in die 32 bit der Instruktion reinpasst, gibts zwei Möglichkeiten den Wert in r0 zu bekommen:
mov r0, #0x1f LSL 4
orr r0, r0, #0xf
oder auch:
ldr r0, =0x1ff
was allerdings eine Abkürzung für folgendes ist:
.word wert=0x1ff (meistens in .text)
ldr r0, wert
Sollte der Wert aber, wie 0xc00 mit anderen Möglichkeiten in einem Befehl dekodiert werden können, gibts folgendes:
orr r1, r1, #0xc0 LSL 4
orr r1, r1, #0x0c LSL 8
orr r1, r1, #0x0c ROR 24
orr r1, r1, #0xc0 ROR 28
orr r1, r1, #0x0c ASR 24
orr r1, r1, #0xc0 ASR 28
Siehe http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cihbeage.html

Welche nun dein Assembler nimmt, ist ihm überlassen.

Verstehe deine Frage nicht?
Habe es so abgeschrieben, wie es bei mir auf dem Bildschirm steht.
C ist außerdem nicht mein Ding

Bei 4210A0E3 ist E3 das höchstwertigste Byte.
Du schreibst ja auch 100 und nicht 001 für hundert.

5

Lowlevel-Coding / Re: ARM Timer-IRQ

« am: 23. August 2013, 20:46 »

24 ist mov r1, #0x42
28 ist orr r1, r1, #0xc00
Aber warum schreibst du die Instruktionen in Big-Endian?
24 wäre 0xE3A01042 in C.

6

Lowlevel-Coding / Re: Qemu-Bug und Ideen

« am: 04. October 2012, 18:01 »

Falls sie es mal nicht sein sollten, wirst du weniger Speicher nutzen können, als tatsächlich vorhanden ist. Wenn du das irgendwann besser lösen willst, solltest du prüfen, ob mmap->base > 4GB, und wenn ja den Eintrag verwerfen. Und außerdem prüfen, ob mmap->base + mmap->length > 4 GB ist, und wenn ja, dann statt mmap->length den Wert 4 GB - mmap->base nutzen. Das Ganze natürlich mit 64-Bit Adressen.

Ja, das geht natürlich auch. Ich hatte gestern eh nur eine Art Notlösung zum Testen, und es war schon spät 

Das worauf ich mich bezog, war eher, dass es problematisch ist, wenn der Kernel dem Modul ein paar Pointer auf Funktionen zurückgibt, und der Userprozess dann diese Funktionen aufruft. Das Problem ist ja, dass der Userprozess im Ring 3 läuft, und deswegen nicht auf Speicherbereiche zugreifen kann, die für den Kernel (Ring 0) gemappt sind. Das heißt, du kriegst einen Page Fault, wenn der User Prozess eine Funktion aufruft, die versucht Kernel Speicher zu modifizieren. Wenn du versuchst, das zu umgehen, indem du den Kernelspeicher beschreibbar machst, dann versaust du (im Allgemeinen) das gesamte Konzept der Trennung von User Mode und Kernel Mode. Deswegen solltest du weiterhin privilgierte Operationen dem Kernel vorbehalten. Aber zum Beispiel I/O kannst du im User Mode machen. Die verzwickten Sachen (und da ist dann dein Konzept gefragt) sind eher: Wie kommt ein Prozess an Speicher und wie kommuniziert ein Prozess mit anderen Prozessen. Wenn du dir da was cleveres einfallen lässt, dann sollte die Performance brauchbar sein.

Mit IPC muss ich mich eh auseinandersetzen, wenn ich Multitasking im Userspace einigermaßen sinnvol benutzen möchte.
Die Pinzipien der Ringe habe ich schon verstanden, wusste aber noch nicht, dass man auch IO machen kann.

Diese ganze Geschichte mit mmap++ vs. mmap += 28 ist auch der Grund, warum ich in meinem Code mmap auf paddr_t caste und danach wieder auf multiboot_mmap_t* zurückcaste. paddr_t ist bei mir unsigned int.

Exakt deshalb hatte ich auch

Warum funktioniert mmap++ (also mmap += sizeof(struct multiboot_mmap)), aber nicht mmap += 24 Bytes, obwohl sizeof(struct multiboot_mmap) = 24 ist?

geschrieben. Sonst hätte ich auch einfach zu wenige mmaps statt einfach falschen Werten.

Ich glaube, da hast du was falsch verstanden. I/O ist pure Langsamkeit. Für die Zeit, die du mit einem Portzugriff verbrätst, könntest du wohl einige Male vom Userspace in den Kernel und wieder zurückwechseln...

Also kann es für ein Modul praktisch von der Performance egal sein, in welchem Ring es läuft.
Aber ich denke, ein Modul im Userspace ist zwar sicherer, aber ersteinmal zu kompliziert und unnötig.
Vllt. schreib ich den Kernel auch ohne Module, ich nenn den einfach mal Gigakernel

Öhm, und hast du auch einen Plan dafür, wie du das erreichst? Soll dein OS linuxkompatibel werden oder sowas? Sowas sind ja durchaus Ziele, die man von Anfang an berücksichtigen muss, wenn man sie wirklich umsetzen will.

Mein Ziel hab ich extra so geplant, dass ich es nie erreiche, sonst bin ich ja irgendwann fertig und hab dann nix mehr zu tun 
Am sinnvollsten wär es wohl, Qemu zu porten und darunter Linux zu starten.
Aber darüber mache ich mir noch keine Gedanken, ich schreib gerade nur meinen Kernel zum rumtesten, das was da gerade drin steht, will ich noch keinem echten PC antun 

7

Lowlevel-Coding / Re: Qemu-Bug und Ideen

« am: 03. October 2012, 22:55 »

Die Memory Map gibt den freien RAM an. Jedes gängige System sollte den Bereich ab 0 als frei markieren, nicht nur QEMU. Auf jedem System ist es außerdem möglich auf die Adresse 0 zuzugreifen. Dass es einen Absturz gibt, muss an etwas anderem liegen.

Ok, da schaue ich nochmal.

Ein weiterer Punkt, den auch beachten solltest, ist, dass die Adressen in der Memory Map 64-Bit groß sind. Falls du nur die unteren 32-Bit auswertest, könnte es durchaus zu Problemen kommen, wenn du ein System mit 4 GB oder mehr startest.

Wenn ich überprüfe, ob mmap->base plötzlich kleiner geworden ist und ich dann einfach abbreche, sollte das keine Probleme geben.

Das ist möglich. Du solltest nur bedenken, dass es dazu erforderlich ist, dass das Modul im Kernel Mode laufen muss. Dann kann das durchaus den Linux Kernelmodulen sehr ähnlich sein. Wenn das Modul im User Mode läuft, solltest du nicht einfach Pointer aus dem Kernel in den User Space übergeben. Der User Space sollte (im Allgemeinen) mit dem Kernel nur über Systemaufrufe kommunizieren.

IO über Syscalls machen zu müssen klingt für mich nach purer Langsamkeit. Memory-Mapped-IO könnte noch funktionieren, aber bei VGA z.b. braucht man da schon mehr als 30 outw/outp.

Das sollte so dann in etwa der Fall sein, wenn du einen Webbrowser oder so drauf laufen lässt.  Dann kannst du anfangen Messungen zu machen um festzustellen, wie lange Speicheranfragen dauern, wie groß die Fragmentierung tatsächlich ist, wie gut die Cacheausnutzung ist, etc. Bis dahin gilt: Je einfacher, desto besser.

Werd` ich machen.
Mein entgültiges Ziel (also bis ich ein besseres/einfacheres gefunden habe) ist es, Opera zum laufen zu kriegen.
Könnte sehr spaßig werden, der Quellcode ist schließlich nicht offen 

Ich überspringe immer noch 4 zusätzliche Bytes (= sizeof(mmap->size)).

Warum funktioniert mmap++ (also mmap += sizeof(struct multiboot_mmap)), aber nicht mmap += 24 Bytes, obwohl sizeof(struct multiboot_mmap) = 24 ist?
Mit 28 Bytes scheint es ja laut dir zu funktionieren, warum auch immer..

8

Lowlevel-Coding / Qemu-Bug und Ideen

« am: 03. October 2012, 21:44 »

Hallo, ich hab` da mal ein paar Fragen:

Ich habe jetzt einmal eine eigene physische Speicherverwaltung geschrieben, die auch soweit alles macht, wie ich es will,
nur die Initialisierung funktioniertr nicht, ich hatte immer einen Nullpointer zurückbekommen, es wird phys_free(0) aufgerufen.
Diesen Fehler konnte ich nun dadurch beseitigen, dass ich

Code: [Auswählen]

if (mmap->type == 1 && mmap->base != 0)geschrieben habe, aber woran kann es liegen, dass der Bootloader von Qemu einen Bereich ab 0 als frei markiert?
Wirklich frei ist er nicht, denn Qemu schmiert ab, wenn ich nach 0 etwas schreibe (Nullpointer sind auch einfach böse )

Dann habe ich noch eine Frage bezgl. Modulen:
Würde es funktionieren, wenn am Anfang eines Modules (als flache Binary wahrscheinlich) eine Funktion ist, die einen Kernel-Interrupt aufruft,
die einen Pointer auf eine Tabelle mit Kernel-Funktionen zurückgibt (darunter auch eine, die das Modul aufruft, um sich selbst zu registrieren)?
Oder kann es sein, dass ich gerade das Modulsystem von Linux beschrieben habe? 

Eine Idee, wie man eine Speicher-/Heapverwaltung umsetzen könnte, habe ich auch noch:
Am Anfang ist der ganze Speicher ein Bereich, am Anfang jedes Bereiches liegt ein uint32_t (vllt. überdimensioniert),
der die Größe des Bereiches angibt und ob er frei/belegt ist.
Will man nun zuerst Speicher allozieren, so setzt man den Anfang des ersten freien Bereiches, der groß genug ist,
die Größe des belegten Platzes und dass er belegt ist, geschrieben und hinter diesen Bereich die Größe des restlichen freien Speichers.
Um einen Bereich wieder frei zu geben, markiert man diesen wieder als frei und verbindet ihn wenn möglich mit dem freien Speicher dahinter.
Damit die Performance nicht auf der Strecke bleibt, wäre ein Array(begrenzter Größe, also eher Cache) der/einiger freien Bereiche ratsam,
sonst müsste man im schlimmsten Fall alle Bereiche durchgehen, bis man am Ende merkt, dass überhaupt kein Speicher mehr frei ist.
Kann man das so umsetzen?
Dass ich bei meiner Methode eine hohe Fragmentierung erzeuge, weiß ich, auch dass ich pro Bereich 4 Byte zusätzlich brauche.
Wenn man die maximale Größe eines Bereiches auf 2^16 Bytes begrenzt und auch freien Speicher teilt, lässt sich das verbessern.
Alle malloc(), die ich bis jetzt gesehen habe, waren viel komplizierter, oder hat meine Methode einen großen Denkfehler, man weiß ja nie  ?

Edit: Ich hab noch was vergessen:
Warum funktioniert es nicht, wenn ich (wie von der Multiboot-Spez. vorgeschlagen) zur nächsten mmap wechsle, indem ich mmap->size Bytes überspringe?
Bei den ersten beiden mmap´s stimmts noch mit sizeof(struct multiboot) überein, aber danach kommen nur noch komische Werte, einer reicht ja schon, um rauszukommen.

9

Lowlevel-Coding / Re: Kernel mit GCJ

« am: 21. September 2012, 23:04 »

Strings funktionieren auch schon, kann aber noch ein bisschen dauern, bis man die auch benutzen kann.
Die ganzen Funktionen müssen ja ersteinmal implementiert werden.

10

Lowlevel-Coding / Re: Kernel mit GCJ

« am: 14. September 2012, 19:37 »

Ja, hier, auf Dropbox:
http://dl.dropbox.com/u/105478372/gcj-kernel.zip

Wenn dir der Constructor eines globalen C++-Objects nicht aufgerufen wird, iterierst du vermutlich nicht durch die Constructor Liste zu begin... siehe: http://www.lowlevel.eu/wiki/C%2B%2B#globale.2Fstatische_Objekte

Doch, tu ich.
Funktioniert ja.

Die RWTH-Firewall sperrt dyndns.biz oder was du da hast....

Kenne ich irgendwoher, unsere Firewall in der Schule hatte auch dyndns gesperrt, sogar die IPs (entweder Cache oder reverse DNS).
Aber jetzt ist das anders, jetzt darf ich das Netzwerk dort (mit-) verwalten

11

Lowlevel-Coding / Re: Kernel mit GCJ

« am: 14. September 2012, 18:29 »

Ich nutze g++ 4.7, mit etwa "-c -O3 -flto -funsigned-bitfields -fno-stack-protector -fno-builtin -std=c++0x -fno-exceptions"

Endlich gehts..
Ich weiß zwar nicht, woran das lag, aber mit deinen Parametern funktionierts endlich und ich habe eine Section .init_array, in der die static_iniirgendwas aufgerufen wird!
Hab ich einfach im Linkerscript eingesetzt und - es geht!
DANKE, DANKE, DANKE! 

12

Lowlevel-Coding / Re: Kernel mit GCJ

« am: 14. September 2012, 14:36 »

Wart mal, versuchst du hier, eine Java-Klasse aus C++-Code heraus auf dem Stack zu instanzieren? Das klingt leicht kriminell...

Nein, eine ganz normale C++ Klasse.
Zur dunklen Seite bin ich nicht übergetreten, auch wenn es garantiert ohne weiteres möglich ist, aus C++ heraus ein Java-Objekt zu instanzieren (frag mich nur nicht wie, ich werds bald herausfinden).

Falls du dir nicht sicher bist, ob die Funktionen referenziert werden, lass gjc und ld mal Testweise mit -flto laufen.
Wenn du in der Binary das Dingen dann noch immer findest, übersiehst du nur die Referenz

Danke für den Tipp, das Symbol ist immer noch drin 
Aber es werden mit einem "objump -D main.o | grep Z41 -B10" nur die Funktion selbst und eine andere, die "_GLOBAL__sub_I_screen" (die vermutlich den Konstruktor von Console für "Console screen" aufruft), ausgegeben 
Die funktionen referenzieren sich also nur gegenseitig, also muss eine davon manuell aufgerufen werden.
Ich habe aber keine Ahnung, warum die beiden dann beim Linken nicht rausgekürzt werden.
"start_ctors" und "end_ctors" haben auch immer die exakt gleiche Adresse im kernel.
Außer einer neuen Funktion, "__gnu_lto_v1" bewirkt der Parameter "-flto" irgendwie nix.

Evtl. hilft die ja der zweite treffer von Google weiter: g++ __static_initialization_and_destruction_0(int, int) - what is it

Dadrin ist mir sofort das folgene ins Auge gesprungen:

g++ does have a -fno-use-cxa-atexit command line option but I don't think that'll help. It looks like it just causes atexit() to be used instead of cxa_atexit(). Perhaps the better question to ask is why g++ generates __static_initialization_and_destruction_0() to begin with instead of placing constructor and destructor calls in the .ctors and .dtors ELF sections. Presumably there's a good reason for it.

Auf Deutsch: Anscheinend bringt -fno-use-cxa-atexit nix mehr, denn g++ hat aus einem wahrscheinlich "guten Grund" darauf verzichtet, die Sections .ctors und .dtors zu verwenden. 
Was jetzt?
Ich denke ich muss die __static_initialization_and_destruction_0(int, int) Manuell aufrufen, aber
1. Mit welchen Parametern?
2. Das Symbol heißt dann doch in jeder Objekt-Datei mit statischen/globalen C++-Variablen gleich, das gibt doch Kollisionen!

Das einzige (halbwegs brauchbare) im Netz was ich sonst noch so gefunden habe, ist http://gcc.gnu.org/ml/gcc/2003-11/msg01211.html,
aber in dem Thread gehts nur um eine fehlende Funktion.
Ich bin mit meinem Latein am Ende..
Soll ich es mal mit einer älteren gcc-Version ausprobieren?
Ich hab noch die 4.5.1 (opensuse 11.4) auf meinem Server.

13

Lowlevel-Coding / Re: Kernel mit GCJ

« am: 13. September 2012, 22:48 »

Ich bin jetzt schon einmal weiter gekommen, Init.java kann ich schon instanzieren und eine private Methode aufrufen.

Allerdings habe ich jetzt das Problem, dass z.B.

Code: [Auswählen]

Console screen;nicht funktioniert. Der Konstruktor wird wahrscheinlich nicht aufgerufen.

Code: [Auswählen]

Console* screen;

void foo() { screen = new Console(); }funktioniert aber einwandfrei.

Mit ld --print-map und zahlreichen nm foo.o Aufrufen habe ich rausgefunden, dass es keine Section .ctors oder .dtors gibt!
Stattdessen erscheint immer, wenn ich eine solche benötige, eine Funktion "_Z41__static_initialization_and_destruction_0ii" bzw. "__static_initialization_and_destruction_0(int, int)".
Anscheinend wird diese nicht richtig gelinkt oder sonst irgendetwas anderes, das ich mir nicht erklären kann.
Sowohl mein eigenes Linkerscript als auch das von http://www.lowlevel.eu/wiki/C%2B%2B-Kernel_mit_GRUB funktionieren nicht.
Hat jemand eine Ahnung, woran das liegen könnte?
Version von ld ist: 2.22 (openSUSE 12.2).
GCC: 4.7.1 (ebenfalls openSUSE 12.2)

14

Lowlevel-Coding / Re: Kernel mit GCJ

« am: 13. September 2012, 12:19 »

Das stand aber ziemlich genau exakt so auch in meinem Patch. Hast du dir nur einzelne Zeilen rausgepickt?

Stimmt 
Da war ich entweder zu blind oder zu blöd 

15

Lowlevel-Coding / Re: Kernel mit GCJ

« am: 13. September 2012, 12:06 »

Öhm, was? CVS braucht für jede einzelne Aktion Netzwerkzugriff, das ist lahm und behindert mich beim Arbeiten. Was den ersten Checkout angeht, hat MNemo über die Datenmenge ja schon was gesagt, aber ehrlichgesagt kommt mir da in den meisten Fällen git trotzdem sogar schneller vor.

Ist ja auch völlig egal was schneller ist, solange es funktioniert und man alte Versionen zurückspielen kann, ist alles in Ordnung.

Ich schätze, es ist kein besonders verbreitetes Hobby, Java-Standardbibliotheken zu schreiben...

Zum Glück, sonst gäb es ja tausende SDKs für jede noch so unwichtige Sache..

Die Warnung kommt in deinem ursprünglichen Code mit dem manuell gemangelten Namen nicht (weil der Compiler dann halt nicht blickt, was du vorhast), aber wenn du Init::write_char schreiben willst, dann brauchst du auch das extern "Java" und dann kommt die Meldung.

Code: [Auswählen]

$ gcj --version
gcj (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2)
Die Definition habe ich so in gcj/javaprims.h gefunden. Wenn __java_char bei dir nicht tut, kannst du ja mal schauen, was da bei dir steht.

Den Header habe ich jetzt einfach mal inkludiert (er verweist zum Glück nicht auf andere Header ).
Da steht nämlich so in etwa:

Code: [Auswählen]

extern "Java" {
typedef __java_char jchar;
}
An dem "extern 'Java'" (ich kann es jetzt schon nicht mehr hören  ) scheint es wohl gelegen zu haben.
Auf jeden Fall sieht der Code jetzt schon mal viel schöner aus, so komplett ohne manuelles Mangling 
Dann kommt wohl als nächster Schritt, Umwandlungsfunktionen zu basteln.
Einfach nur casten ist zu unsauber (aber funktioniert  )

16

Lowlevel-Coding / Re: Kernel mit GCJ

« am: 12. September 2012, 21:08 »

Dass du mit git nicht klarkommst, solltest du bei Gelegenheit mal ändern. Mit CVS kommt nämlich der Rest der Welt nicht klar.

Ich komme mit git in der Konsole schon halbwegs gut klar, nur mein Server und eclipse nicht.
Und es ist im Verhältnis zu cvs so lahm, das ist unglaublich.
Während git die Dateien zählt, ist mit cvs schon alles angekommen...

Ich gehe davon aus, dass extern "Java" aus einem bestimmten Grund besteht und dass man es dann auch verwenden sollte. Was es genau ändert, weiß ich nicht, aber deine unterschiedlich gemangelten Namen sprechen ja auch dafür. Ansonsten, Aufrufkonventionen usw. könnten theoretisch auch unterschiedlich sein und sich darauf zu verlassen, dass es zufällig auch anders tut, halte ich für keine gute Idee.

Seltsam, ich finde im Internet kaum irgendetwas über 'extern "Java"'..
Aber solange es funktioniert, ist mir das egal 

Code: [Auswählen]

main.cpp:27:43: Fehler: Java-Methode »void Init::write_char(char)« hat Nicht-Java-Parametertyp »char«

Bei mir kompiliert das ganze sogar ohne Warnungen..
Welche Version benutzt du?
Mein GCC beschwert sich mit __java_char über einen unbekannten Typ..

17

Lowlevel-Coding / Re: Kernel mit GCJ

« am: 12. September 2012, 16:13 »

Ui! Aber keinen öffentlichen, oder? Egal, ich fühl mich trotzdem ins letzte Jahrtausend zurückversetzt.

Kein öffentlicher. Ich kann mit git überhaupt nicht und der svn-Support in Eclipse ist einfach nur krank.
Und eclipse mag ich

Besonders schön ist das ja alles noch nicht. Bevor du mit Speicherverwaltung anfängst (von der ich möglichst viel auch in Java schreiben würde), wäre es vielleicht nett, erstmal den vorhandenen Code aufzuräumen. Solche Sachen wie...

Speicherverwaltung in Java schreiben? Geht nicht. Java-Objekte (keine einfachen Datentypen wie int, char, float, double) werden erst zur Laufzeit erstellt und von irgendwo muss der Speicherplatz ja kommen.
Zumindest nehme ich das mal an, denn wenn ich ein Array erstellen will, brauche ich eine _Jv_alloc(oder so ähnlich)-Funktion.
Was man natürlich machen könnte, ist das Array als native Funktionen zu Java durchzureichen, aber dann kann man auch die ganze Speicherverwaltung in C++ coden. Und Pointer überhaupt könnten ein kleines Problem werden, da wäre eine lowlevel-Klasse für Java wohl angebracht, um wenigstens Ansatzweise mit Pointern arbeiten zu können.

"extern 'Java'" kannte ich noch nicht. Mangelt GCC die Namen dann anders? GCJ hält sich doch an GCC-Regeln?
Was ist denn bitteschön __java_char? Wird intern in der libgcj verwendet, ich weiß aber nicht, wo das herkommt.
Und den Unterschied zw. "_ZGAN4Init10write_charEJvw"(GCJ) und "_ZN4Init10write_charEw"(G++) verstehe ich nicht. besonders das am Ende reingeschmissene "Jv".

Und im Moment ist das ganze eh nur ein Test, bis da was wirklich brauchbares (und sauberes) am Besten komplett ohne Stubs rauskommt, kann das noch ein Weilchen dauern. Am Ende braucht man ja eine minimale GCJ-Runtime im Kernel. (Ohne Exceptions, die sind im Kernel bis zu einem bestimmten Punkt sinnlos).

18

Lowlevel-Coding / Re: Kernel mit GCJ

« am: 12. September 2012, 13:12 »

Habs hochgeladen.
http://ritter-vogt.dyndns.biz/lowlevel/
Einen CVS-Server hab ich auch mal aufgesetzt.
Im Moment passiert aber noch nicht viel besonderes, es wird einfach mit C++ eine (statische) Java-Funktion aufgerufen, die dann eine (als nativ deklarierte und mit C++ erstellte) Funktion mehrfach aufruft.
Ich hätte nicht gedacht, dass sich GCJ auch mit Stubs zufrieden gibt.
Aber das ist ersteinmal egal, hauptsache es Funktioniert.

19

Lowlevel-Coding / Re: Kernel mit GCJ

« am: 11. September 2012, 21:36 »

Doch, komplett freistehend (qemu -kernel kernel).
"kernel" ist in etwa 11 kib groß.

Komplett freistehend halt im Sinne von mit noch ein paar Zeilen ASM, C und C++.

20

Lowlevel-Coding / Re: Kernel mit GCJ

« am: 11. September 2012, 20:29 »

So, ich habs jetzt zumindest mal geschafft, mit einer statischen Java-Funktion "Hello World!" auszugeben...
Jetzt gehts wohl los mit dem Durchreichen der Speicherverwaltung für Java.
Ich bin mal gespannt, obs was wird.