Nachrichten

41

Softwareentwicklung / Re: Meine Programmiersprache - Haze

« am: 13. March 2010, 17:14 »

Jo 

42

Softwareentwicklung / Re: Meine Programmiersprache - Haze

« am: 13. March 2010, 16:48 »

Es könnte sinnvoll sein nur ein Frontend für deine Sprache zu schreiben und LLVM den Rest übernehmen zu lassen. LLVM soll besser optimieren können als der gcc. Außerdem soll er gut designt und dokumentiert sein.

Mh müsste ich mir mal anschauen. Mal gucken. Wobei ich es denke ich mal zumindest testweise auch gerne mal selbst probieren würde.

Mal ne andere Frage: Hat der Name "haze" was zu bedeuten, oder wie bist du auf den Namen gekommen?

Eine direkte Bedeutung hat der Name nicht (bis auf die deutsche Übersetzung). Soll maximal soetwas wie eine Andeutung auf den Umfang der Sprache sein. 

43

Softwareentwicklung / Re: Meine Programmiersprache - Haze

« am: 13. March 2010, 16:42 »

Ja wie gesagt, so ein paar kleinere Optimierungen werden schon drin sein^^
Aber erwartet keinen hochoptimierten Code von meinem Compiler^^

Das funktionierender Code Ziel jedes Compilers ist, ist klar 
Damit wollte ich nur sagen, dass ich nicht vorhatte so viel Energie in die Optimierung zu stecken 

44

Softwareentwicklung / Re: Meine Programmiersprache - Haze

« am: 13. March 2010, 15:48 »

Was ich schon immer vermisst hab ist eine saubere Unterstützung für mehrere Rückgabewerte, planst Du sowas?

Geplant war es bisher nicht, aber es wäre mal eine Überlegung wert. 

Bei dem Inline-Assembler würde ich mir die gcc-Syntax mit (Assembler-Code : Eingabe : Ausgabe : Änderungen) wünschen. Das finde ich persönlich recht gut.

Ich kenne die gcc Syntax leider nicht. Kannst du mal ein Beispiel posten?

Wie gut kann/soll den Dein Compiler optimieren?

Ich denke es wird nicht besonders viel Optimierung geben. Zum einen, weil ich befürchte, dass ich dafür nicht das erforderliche Wissen/Können besitze und zum anderen weil die Sprache eigentlich nie dafür gedacht war besonders optimierten Code zu erzeugen, sondern in erster Linie einfach nur funktionierenden Code. Die ein oder anderen geringfügigen Optimierungen wird es schon geben, aber in der Richtung ist vorerst nicht so viel zu erwarten.

45

Softwareentwicklung / Re: Meine Programmiersprache - Haze

« am: 13. March 2010, 15:12 »

wie siehts mit AT&T syntax für den Inline ASM aus?

Nunja der Compiler wird an dem inline ASM Code nicht viel ändern. er wird nur (lokale) Variablen und Parameter ersetzen.

Z.B.

Code: [Auswählen]

mov si, Str
in

Code: [Auswählen]

mov si, [ebp+0x04]
oder so.

Sagen wir es so. Zur Zeit ist die Unterstützung von AT&T Syntax nicht geplant aber ich denke es wäre evtl nicht so schwer AT&T nachträglich dann zu unterstützen. Mal schauen 

sieht aber schon seehr schick aus respekt

Danke 

46

Softwareentwicklung / Re: Meine Programmiersprache - Haze

« am: 13. March 2010, 14:58 »

wie siehts mit inlineassembler aus?
isses ne strukturierte oder ne prozeduale sprache?

Schonmal den Beispielcode angeschaut?

http://pastebin.com/1bWXx1Zm

Es ist eine prozedurale Sprache

47

Softwareentwicklung / Meine Programmiersprache - Haze

« am: 13. March 2010, 14:45 »

Hi,

Also ich habe ja versprochen ein paar Infos über meine werdende Programmiersprache zu posten. Hier sind sie!

Die Syntax von "Haze" ähnelt der von Pascal SEHR, was ihr auch gleich sehen werdet. Der Grund dafür ist einfach, dass ich mit dieser Art von Syntax "aufgewachsen" bin und damit am besten zurecht komme.
Einige Syntaxelemente sind allerdings an die Syntax von C angelehnt. Z.B. die Art wie Arrays deklariert werden oder die Darstellung von Hex-Zahlen.

Hier ein kleines (mehr oder weniger sinnvolles) Codebeispiel. Dieser Code ist zurzeit alles andere als compilierbar. Der Code soll nur einen Eindruck vermitteln, wie es später mal ungefähr aussehen wird.
Große Teile der Syntax die zu sehen ist, habe ich bereits per EBNF festgehalten. Einige Dinge muss ich noch ergänzen.

Der Beispiel-Code: http://pastebin.com/1bWXx1Zm

Die bisherige (unfertige!) EBNF:
(Meine EBNF-Syntax weicht minimal von der offiziellen ab, aber ich denke man kann es trotzdem lesen)


Die EBNF ist sicher auch in ihrer bisherigen Form alles andere als minimal oder perfekt. Aber ich arbeite daran

Den Compiler inkl. Scanner und Parser schreibe ich komplett selbst in Delphi. Der Scanner ist soweit fertig. Mit dem Parser fange ich an, sobald die EBNF reif genug ist. Der Compiler wird Assemblercode (NASM) erzeugen und dann NASM die Umwandlung in Machinencode überlassen.

Meine Sprache wird (wie schon anhand der EBNF zu erahnen) ein ähnliches Unit-System unterstützen wie Pascal und Delphi es tun.

Mehr fällt mir jetzt auf Anhieb nicht ein. Wenn ihr irgendwelche Fragen habt, dann stellt sie ruhig und ich versuche eine Antwort darauf zu geben 

48

Softwareentwicklung / Re: Turbo C - COM Datei erstellen

« am: 13. March 2010, 11:53 »

@Svenska: Ich werde um C rumkommen   

Wegen Delphi und Zeiger... Glaub mir, ich liebe Zeiger und ich kann auch in Delphi oder Pascal den größten Blödsinn damit veranstalten   

Wenn dein Problem ist, dass du keinen vernünftig handhabbaren 16-Bit-Pascalcompiler hast, hast du schonmal über Protected Mode nachgedacht? GRUB läuft, soweit ich das weiß, auch grundsätzlich im PM und schaltet nur für die BIOS-Interrupts (also im Wesentlichen Plattenzugriff) in den RM zurück. Das dürfte im Vergleich zum Rest ein relativ kurzes Codestück sein, das man locker in Assembler schreiben könnte.

In den PM wollte ich eigentlich erst kurz vor dem Laden des Betriebssystems springen. Ich werde meinen Ansatz mal weiterverfolgen und schauen ob was vernünftiges bei rumkommt 

Eine Programmiersprache als "Zwischenprojekt" ist mutig.

Trotzdem eine interessante Sache. Du kannst ja auch mal ein paar Ansätze hier posten, da diskutieren sicher einige gern drüber mit dir.

Naja sagen wir es so: Ich mache mir keinen Zeitdruck. Alles dauert halt solange es dauern muss. Von daher passt das mit dem "Zwischenprojekt" schon^^

Ich werde mal ein paar Infos über meine Sprache zusammentragen und sie dann nachher in einem eigenen Thread vorstellen 

49

Softwareentwicklung / Re: Turbo C - COM Datei erstellen

« am: 13. March 2010, 01:25 »

Bei 3. kommt es natürlich drauf an, was für eine Art Bootloader es werden soll. [...]

Ja ich habe schon vor etwas richtiges hinzubekommen. Für einen 08/15 "Bootloader" der einfach die nächsten 512 Bytes lädt und "Hallo Welt" ausgibt o.ä. würde ich sicherlich nicht so einen Aufwand betreiben
An GRUB wird mein Bootloader sicherlich nicht rankommen aber das ist auch nicht mein Ziel^^

zu 1.) ich sagte nicht das C die Sprache aller Sprachen wäre...aber wenn man ein OS in C programmieren will sollte man C können, mehr wollte ich nicht aussagen

Nun gut, da kann ich dir dann schon zustimmen  Allerdings hatte ich nie vor ein Betriebssystem in C zu schreiben. Für das Betriebssystem selbst hätte ich Pascal genommen. Für den Bootloader hätte dann halt notfalls z.T. C herhalten müssen, weil ich keinen Pascal Compiler kenne, der Code ausspuckt, der in dieser Situation verwendbar wäre 

Aber das hat sich ja erledigt. Jetzt versuche ich mich als "kleines" Zwischenprojekt an einer kleinen aber hoffentlich feinen Programmiersprache  Mal schauen obs was wird 

Das GRUB nicht die einzige gute alternative ist wurde mir hier nun auch schon ausgeredet^^

Ja das meine ich nichtmal unbedingt... Es nervt nur etwas, dass von allen Seiten die "GRUB"-Schreie ertönen, sobald man das Wort "Bootloader" in den Mund nimmt (Um mal ein wenig zu übertreiben). Wenn man dann noch davon spricht sich an einem eigenen Bootloader versuchen zu wollen dann ist's ganz aus 

Deswegen reagiere ich auf GRUB z.T. etwas allergisch 

50

Softwareentwicklung / Re: Turbo C - COM Datei erstellen

« am: 12. March 2010, 19:31 »

Oh hab ja gar nicht mehr gemerkt dass hier Antworten kamen.

@AGGROStar1991:

1) Ich muss dich enttäuschen aber C ist immer noch nicht die Sprache aller Sprachen. Auch wenn manche Leute das glauben. Ich bin mit Pascal/Delphi aufgewachsen und beherrsche diese Sprache(n) mittlerweile auch. Mit C oder C++ hatte ich bisher sogut wie nichts zu tun und ich bereue das auch nicht.

2) Ich hab die GRUB Parolen schon oft genug gehört - Danke. Dein Argument, dass es unsinnig ist etwas neu zu erfinden, was es schon gibt ist etwas Schwachsinnig. Was tust du denn wenn du ein Betriebssystem entwickelst? Das ist genau das gleiche. Was ist also das Problem einen Bootloader zu programmieren, wenn ich Interesse und Spaß daran habe?

3) Jo da hast du mehr oder weniger Recht. Aber eben auch weil einem nicht viel anderes übrig bleibt. Ist ja nicht so, dass ich kein Assembler könnte, aber sowas wie FAT-Treiber in Assembler zu schreiben ist halt ziemlich unübersichtlich...

4) Ich entwickele gerade eine eigene kleine Sprache mit der ich solche Sachen leicht und vorallem übersichtlich programmieren kann. Wenn sie fertig ist, werde ich sie auch wahrscheinlich hier vorstellen.

51

Softwareentwicklung / Turbo C - COM Datei erstellen

« am: 28. February 2010, 21:16 »

Hi,

Ich versuche gerade mit einer alten 16-Bit Turbo C Version eine 16-Bit COM-Datei zu erstellen, die ich auch für meinen Bootloader benutzen kann.

Habe dazu erstmal eine Testdatei erstellt:

test.c

Code: [Auswählen]

int main()
{

}
Compilieren tue ich die Datei folgendermaßen:

tcc -mt -c test.c

-c = Nur compilieren, nicht linken
-mt = Tiny Memory Model

Das funktioniert auch schonmal ganz gut und ich erhalte die gewünschte test.obj. Allerdings scheitere ich jetzt beim linken:

tlink test.obj /n /t

/n = Keine default libs verwenden
/t = COM Datei erstellen

Allerdings erhalte ich immer die Meldung:

Cannot generate COM file : invalid initial entry point address

Kenne mich aber weder mit dem Linker noch mit dem Compiler noch generell mit C wirklich gut aus.

Also wie kann ich ihm jetzt den richtigen Entry-Point (0x100) übergeben?

Per Compilerschalter oder irgendwie doch über den Linker oder sonst irgendwie?

Gruß
Cjreek

52

Offtopic / Re: RawWrite neu erfinden

« am: 27. November 2009, 18:00 »

Hi,

Also ich denke du solltest noch FILE_SHARE_READ hinzufügen...

Ich würde CreateFile so aufrufen:

Code: [Auswählen]

CreateFile(myFile,GENERIC_READ or GENERIC_WRITE,FILE_SHARE_WRITE or FILE_SHARE_READ,0,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);
Wegen WriteFile... Hab von C nicht viel Ahnung aber was passiert wenn du WriteFile so aufrufst:

Code: [Auswählen]

WriteFile(hFile,&DataBuffer[0],dwBytesToWrite,&dwBytesWritten,NULL);
?

53

Offtopic / Re: RawWrite neu erfinden

« am: 24. November 2009, 21:31 »

Zum Beschreiben wäre GENERIC_WRITE auch ganz sinnvoll.

Ach wassss.... Die Daten werden einfach auf die Diskette gelesen! 

54

Offtopic / Re: RawWrite neu erfinden

« am: 24. November 2009, 20:04 »

CreateFile, WriteFile, CloseHandle sind die Funktionen die du suchst

Versuch evtl mal sowas:

Code: [Auswählen]

CreateFile('\\.\a:',GENERIC_READ,FILE_SHARE_WRITE or FILE_SHARE_READ,nil,OPEN_EXISTING,0,0);
Hab grad kein Diskettenlaufwerk, aber bei meiner C: Partition funktioniert es.

55

Softwareentwicklung / Re: int nach ascii umwandeln

« am: 22. November 2009, 12:05 »

Als kleiner Tipp:

http://www.asciitable.com/

Schau dir mal die Hexwerte der Zeichen 0-9 an. Und dann lies nochmal taljeths Post und dann sollte dir die Erleuchtung kommen

56

Offtopic / Re: Hardware Dokus auf Deutsch.

« am: 14. November 2009, 15:03 »

Hi,

Warum überhaupt die Arbeit machen? Wenn dus übersetzen kannst, kannst dus genauso gut auch einfach lesen 

57

Lowlevel-Coding / Re: Diskettentreiber

« am: 13. November 2009, 19:00 »

Und ich bin auch sicher dass Du es schneller kapierst

Da wäre ich mir jetzt nicht so sicher! 

Zwei Dinge sind wichtig, wenn man es verstehen will:

1. Lies 1 Satz, überleg ob du ihn wirklich komplett verstanden hast. Wenn nicht, dann lies ihn nochmal und denk drüber nach.

2. Vorallem in der OS Entwicklung gibt es viele Dinge die man nur schwer durch reine Theorie richtig verstehen kann. Als ich mit FAT12 und Ext2 zu tun hatte, habe ich mir einerseits die Artikel und Dokumentationen angeschaut und dann aber auch gleichzeitig ein FAT12/Ext2 Image im Hexeditor geöffnet und versucht das gelesene im Hexeditor nachzuvollziehen. Ein Hexeditor bringt natürlich nicht bei jedem Thema was. Aber mir geht es darum, dass man sich die Dinge mal praktisch anschauen oder sogar tun muss, um sie zu verstehen. Und wenns nur auf nem Blatt Papier ist.

Diese 2 Schritte wendest du so lange an bis du alles oder zumindest genug verstanden hast.

58

Lowlevel-Coding / Re: Diskettentreiber

« am: 12. November 2009, 19:46 »

Ok,
könnte mir jemand dann erklären, wie ich das mit DMA mache?
Es kommt jetzt vielleicht ein bisschen doof rüber, aber irgendwie versteh ich weder den Wiki-Artikel, noch mit Google gefundene Seiten.

Naja es geht ja gerade mal "nur" um das Diskettenlaufwerk.  Ich denke in so einer frühen Phase sollte man zusehen dass man sich durch den Stoff durchboxt. Ich musste auch ca. ne Woche lang den Paging Artikel (und externe Quellen) anstarren, bis ich das soweit verstanden hatte, dass ich es programmieren konnte. Ich denke so ist das nunmal.

59

Offtopic / Re: Wird OS-Programmierung in Zukunft ein Kinderspiel sein?

« am: 01. November 2009, 21:56 »

Abgesehen davon.

Was hat man davon? Man schreibt doch ein Betriebssystem aus Interesse und um was zu lernen.

Mit diesen Programmen lernt man wahrscheinlich nichts und was anständiges, konkurrenzfähiges wird auch nicht bei rauskommen. 

60

Lowlevel-Coding / Re: cls in Assembler

« am: 31. October 2009, 14:33 »

Wieso sollten sie? o.O

Sind dann halt dezimalzahlen