Amiforce Forum (http://www.amiforce.de//index.php)
|- AmiBlitz2/3 (Archiv) (http://www.amiforce.de//board.php?boardid=4)
|-- AmiBlitz4, A/A++ oder Amiga Thunder (http://www.amiforce.de//threadid.php?boardid=4&threadid=1411)


Geschrieben von Der_Wanderer am 22.01.2009, 18:28:

  AmiBlitz4, A/A++ oder Amiga Thunder

Ihr könnte vielleicht schon ahnen, in welche Richtung es hier geht.

Ich habe überlegt, wie man Amiblitz3 am besten weiterentwicklt.

Dabei sind mir ein paar Dinge aufgefallen, die einer Veränderung bedürfen, bzw. gar nicht so schwer sind wenn wir den Editor sowieso abkoppeln würden.

1. Der Name.
Die meisten assoziieren mit allem, wo "Blitz" drin ist, amateurhafte, unstabile 320x200x5 OCS Spiele. Es kommt keiner auf die Idee, damit eine ernsthafte App oder was komplexeres zu proggen für Grafikkarte.

Daher: Namensänderung bei der nächsten Version?

Meine Ideen:
- A/A++
- "Thunder" oder "AmigaThunder" (ist etwas kitschig)
und noch ein paar mehr. Mal sehen.

2. Portierbarkeit.
Sobald man "Windows" oder "WBToScreen" getippt hat, ist das Programm nicht mehr portierbar, weil das Blitzlibs sind. Eine radikale Veränderung wäre Blitzlibs komplett rauszuschmeissen, und nur noch Inlcudes benutzen. Vielleicht wäre das dann ein Spinn-Off, so wie PureBasic es war, statt einer Weiterentwicklung. Ansonsten wird es kein x86 oder PPC Codegenerator geben, da unmöglich.
Die Include müsste ich dann auch ein wenig überarbeiten, um alle komplett mit Resource-Tracking auszustatten und konsistent in der API machen.
Vorteil: Includes sind Sourcecode, jeder hat sie, jeder kann sie fixen, jeder kann eigene schreiben und erweitern. Keine dämlichen Beschränkungen mit 255 Libs, Tokens etc.

3. IDE + Kompatibelität
Die Amiga Welt spricht C. Deshalb sollte das AmigaSDK nicht als .res, sondern per C Code eingebunden werden, so wie es released wird. Auch wäre die Integration von C Libs wünschenswert, denn da gibt es auch einige interessante Sachen. Technisch spricht wenig dagegen. Eine C Lib im elf format kann man genauso einbinden wie eine Blitzlibs, man benötigt nur das Interface dazu.

4. GUI
Da würde ich natürlich gerne auf NTUI umsteigen. Einmal weil es optisch aufgepeppt wird, zum anderen weil schneller erweiterbar.
Neben dem Sourcecode sollte auch ein Tree-View der Dateien sein. Nur so lässt sich schnell mit grossen Projekten arbeiten.

5. Syntax
Die Amiblitz Syntax stösst jedem Neuling auf.

z.B. die geschweiften Klammern:
image_Load(myimage)

wird im allgemeinen als schöner und intuitiver empfunden als

image_Load{myimage}

Es gibt auch einige Inkonsistenzen, die man aufräumen sollte.
z.B. die Derefrenzierung von Pointern in NewTypes und ausserhalb. Das sollte man wie bei C machen.

Wenn ich

Alien\x = 2

mache, ist es doch egal wie Alien erzeugt wurde:

Deftype.AlienType Alien oder
*Alien.AlienType = ...

Das "*" muss man nicht mitführen. Bei NewTypes fällt es momentan auch raus.
Auch

Newtype
x[123]
End Newtype

Aber

Dim x(123)

Da sollte man immer eckige Klammer nehmen, um sich deutlicher von Funktionen abzuheben. (wobei man ein Array natürlich auch als Funktion sehen kann)


6. OOP
Ein einfaches OOP kann man durch reines Pre-Processing machen. C++ macht das intern auch so. OOP ist keine MAgie, sondern versteckt den "Dreck" nur auf Sourcecodeebene.

Es spricht nichts dagegen, ein

myImage\Resize(320,200) als

image_Resize(myImage,320,200)
zu kompilieren.

Dafür sollte man einen Pre-Processor einführen.

7. Fileformat
BB2 Format ist schlecht, wenn man mit SVN arbeitet, weil es keine Textdatei ist. Ausserdem müssen die Deflibs immer gleich sein. ASCII (ab2) ist besser, aber da gehen keine Includes.

Als Fileformat wäre ein reines ASCII am besten, mit EINER Project file.


8. Typensicherheit
Wird immer wichtiger, zumidnest für mich.
Das ist kein grosses Problem, kann man auch alles in einem Pre-Processor erledigen mit einem dezenten Hinweis, wenn man sich im Typ irrt.


Summa Sumarum:
Den Amiblitz3 Kompiler kann man nach wie vor zur Codegenerierung nutzen. Man kann die Syntax ändern, aber ein "Pre-Processor" würde wieder einen Amiblitz3 code draus machen. Der wäre soweiso nötig, wenn man auf einen anderen Texteditor als PED umschwenkt. Denkbar wären dann aber eben später auch C code der dann durch den GCC gejagt wird. Dabei wird natürlich kein C Code erzeugt, wie man ihn in C programmieren würde, sondern eine einzige, riessige C Datei erzeugt, die alles enthält. Dann würde der GCC schneller kompilieren und benötigt keine aufwendige Installtion.

Das sind so Gedankenspiele, ihr dürft hier auch gerne weiter Brain Stormen. Evlt. baue ich mal eine Demo NTUI GUI.



__________________
Check out http://www.hd-rec.de !


Geschrieben von bruZard am 22.01.2009, 18:40:

 

bruZard klatscht als gäbe es kein Morgen

Ich könnte mir noch mehr vorstellen, aber das ist der Weg den AB gehen muss.

Nennt die Sprache doch einfach "A", ist nicht besetzt und impliziert exakt das was man erreichen will: A ist der Anfang, erst danach kommt C. A ist Alles, A ist ein Grundbaustein, A ist einfach, A kann Alles.

Besonders hervorzuheben ist die Idee des GCC als Kompiler. Es wäre möglich Targets zu definieren und den ganzen Kram direkt für AROS, AOS4, MOS etc. zu kompilieren. Einfach so, auf einem A1200 mit ein bissl FastMem


__________________
PanzerZ | jBB / HTML5 Canvas Framework


Geschrieben von am 22.01.2009, 19:55:

 

@Der Wanderer

schön zu lesen der Text...

aber wer soll das umsetzen und wann?

und vorallem, wie willst du das mit dem Debugger lösen ?


Geschrieben von Honitos am 22.01.2009, 20:57:

 

Also, wenn es einen Gui-Designer nach StormWizard-Vorbild gäbe, könnte ich binnen einen Monats die gesamte IDE auf NTUI umstellen, inkl. Codeanpassungen.

Unabhängig davon würde ich den PED komplett durch einen neuen Editor auf TuiTED Basis ersetzen. Das ist ja sowieso mein Ziel dieses Jahr.
Die blitzlibs nur noch in einem Kompatibilitätsmodus zu verwenden, ist sowieso mein Plan.

Ich denke, ein AmiBlitz3.5 ist dieses Jahr auf jeden Fall drin.
Einen neuen Namen könnte man vielleicht schon einführen, wenn PED weg ist, und die neue IDE auf ntui-Basis steht...

Deine Ideen in Richtung Code-modernisierung teile ich ebenfalls. Vielleicht etwas zu stark C-lastig, sonst könnte man ja auch gleich die Cubic-IDE nehmen.


__________________
On the web at http://www.programmed-excellence.de


Geschrieben von Der_Wanderer am 23.01.2009, 01:37:

 

Im Debugger sehe ich das größte Problem. Das ist schon ein mächtiges Werkzeug was ich nicht missen möchte.

Wobei auch das kein Hexenwerk ist, sondern durch geschicktes Pre-Processing lösen lässt. Entwender mit Messages oder mit Traps.

Wenn wir auf TuiTED (oder besser auf eine NTUI TextBox) umsteigen würden, dann bräuchte man auf jeden Fall einen Pre-Processor, der die Tokenisierung macht vor dem kompilieren. Dort könnte man auch alle möglichen anderen Dinge hineinhängen, z.B. Typen Prüfung oder Syntax Umformatierung.
Wenn man unangetastete Teile Cached, dann ist das Geschwindigkeits Technisch kein Problem denke ich, und keiner hier entwickelt noch auf einem nackten A1200, denke ich. Dafür wäre das auch nicht geeignet, dafür sollte man BlitzBasic2 nehmen. Irgendwo muss man eine grenze ziehen, wenn man echte Verbesserungen haben will . Visual Studio .NET läuft auch nicht auf einem 50MHz P mit 4MB RAM.

Ich denke dass alles zusammen gar nicht so viel Arbeit ist. Mit dem Amiblitz3 ASM code herumzuwurschteln kostet auch viel Zeit, die man nicht in wirklich Neues stecken kann.

Ich werde mal noch ein wenig drüber nachdenken, was sich mit welchem Aufwand realisieren lässt.

Aber wie gesagt, das hier ist nur Brain Storming.

Ich denke A/A++ wäre ein guter Name, das es "A" für Amiga steht, und es ein wenig mehr in Richtung C drückt.


__________________
Check out http://www.hd-rec.de !


Geschrieben von Honitos am 23.01.2009, 08:35:

 

Wichtig ist nur, dass nicht zu viele Dinge gleichzeitig passieren - in Hinblick auf die zu erwartende Umsetzungszeit.

In der Zwischenzeit wollen wir ja auch an AB3 noch Verbesserungen sehen.

Im Rahmen es Brainstorming mache ich folgenden Vorschlag:
Zuerst die GUI einheitlich auf ntui umstellen und PED ersetzen (die Übergabe des Source an den Compiler kann ich jetzt schon handeln).
Das könnte man noch in AB3 erledigen und dann für "A+ o.ä.) den Compiler umbauen.

Ich möchte auf jedenfall verhindern, dass wir AB3 als Baustelle liegen lassen und alle evlt. sehr lange auf "das Neue" warten müssen. Eine sukzessive Migration wäre mir am liebsten.


__________________
On the web at http://www.programmed-excellence.de


Geschrieben von Der_Wanderer am 23.01.2009, 10:38:

 

Einen Debugger koennte man so realsieren, das waere auf Emus sogar schneller als Traps:

A++ Code

code:

*myImage.image = image::Create() ; erzeuge image
myImage\Load(filename.s) ; lade image
a.l=0,  : a++ ; erweiterte syntax, z.B ++
End ; beenden...



Generated Amiblitz3 Release
code:

optimize 7 ; standard header
Syntax 2

Deftype.image *myImage ; Variablen deklarieren
Deftype.s filename
Deftype.l a

*myImage = image_Create{} ; Program ausfuehren
image_Load{*myImage,filename}
a=0
a+1

image_AutoExit{} ; Resourcen freigeben
End




Generated Amiblitz3 Debug
code:

optimize 7  ; standard header
Syntax 2

; ============= DEBUGGER

Macro DebugInfo ; {line,pos}
  If (*Debugger\breakline<='1) ; wenn der Debugger hier stoppen will...
    Wait_ (*Debugger\sigflag) ; dann schlafen wir erstmal...
    If (*Debugger\exit) End ; will der Debugger uns beenden?
    Goto skip_debuginfo_line'1_pos'2 ; überspringe Debug Informationen
    Dc.l '1,'2 ; Zeile/Spalte im original A/A++ Sourcecode
    skip_debuginfo_line'1_pos'2
  End If
End Macro

Shared *Debugger.DebuggerBase ; Debugger überall verfügbar machen
*Debugger = debug_GetBase{} ; Basisadresse holen

; ============= DEBUGGER

Deftype.image *myImage ; Variablen deklarieren
Deftype.s filename
Deftype.l a

!DebugInfo{0,0} ; DebugInfo einfügen
*myImage = image_Create{}

!DebugInfo{1,0}
image_Load{*myImage,filename}

!DebugInfo{2,0}
a=0

!DebugInfo{2,5}
a+1

!DebugInfo{3,0}
image_AutoExit{}
End




Erklärung:

A++ Syntax
Jeder Objekttype hat eine Create und eine Free Function. Funktionen, die zum Objekt gehoeren kann man von dort aus aufrufen. In Amibltz3 ist das dann immer der erste Parameter. Das ist auch praktisch in allen Includes schon so.

Release
Das waere das generierte Amiblitz3 equivalent. einige dinge die hier getan werden sind in A++ nicht sichtbar, das macht es kuerzer.

Debug
Amiblit3 wuerde das natuerlich als release compilieren. Der Debugger waere dann neu. Man setzt einfach zwischen jeden Befehl das DebugInfo Macro. Dort wird geprüft, ob das Programm angehalten werden soll. *Debugger\break wird dann von aussen gesetzt. Das A++ Program schlaeft dann erstmal, bis es wieder ein signal zjm weitermachen bekommt. Der Overhead ist lediglich ein IF, ich denke das ist schneller als die Traps im REDDebugger.
Zusaetzlich steht in jedem Macro die  Zeile und Position im A++ Quellcode. So kann man den Programablauf single-step verfolgen - im richtigen Sourcecode Fenster, keine extra Hack Fenster mit halbgaren Highlightning.

Dadurch dass die breakline abgefragt wird, kann man sehr einfach BreakPoints setzen oder "Run-To-Cursor" Realisieren, wie in -NET. (also das programm läuft weiter bis zu der position, wo der coursor im Texteditor steht. Sehr praktisch.

Und jetzt wird es richtig abgefahren:

Generated C Release
code:

#include "A.support.h" ; standard header

image  *myImage   = NULL; // Variablen deklarieren
string *filename  = NULL;
int    a          = 0;

void main(void) {
  myImage = image_Create(); // Program ausfuehren
  image_Load(*myImage,filename);
  a=0;
  a++;

  image_AutoExit(); // Resourcen freigeben
  Return (0);
}



Das ganze kann man natuerlich auch mit DebugInfo machen. Somit ist der Debugger unabhaengig vom verwendeten Compiler!


__________________
Check out http://www.hd-rec.de !


Geschrieben von am 23.01.2009, 14:39:

 

@Der Wanderer

sieht gut aus....

Mir ist es wichtig das ich das auf allen meinen Maschinen benutzen kann (ohne Einschränkungen!)

Ansonsten sehe ich das wie Honitos, erstmal AB3 weitermachen bis es "stable" ist...

Ach ja übrigends, das was du nun hier so prima beschrieben hast (<-- ernst gemeint!) hatte ich vor ca 2 Jahren wenn ich mich recht erinnere schonmal vorgeschlagen (altes Geschrappel raus usw...) Damals hies es aber noch: ja ja der Blackbird will nur das sein PPC-Scheis funktioniert


Geschrieben von Der_Wanderer am 23.01.2009, 14:50:

 

Dadruch bekommt man ja nicht automatisch PPC code. Den bekommt man nur, wenn man ein Backend für GCC macht und dieses auch für PPC anpasst. Aber das was ich geschrieben habe würde es ermöglichen.
Das schöne daran ist, dass der Debugger, so wie ich ihn beschrieben habe nicht nur mit amiblitz compiler, sondern auch mit dem GCC mit JEDEM Prozessor code gehen würde. Man hat zwar einschränkungen, z.B. kann man die Register nicht einsehen, dann wäre man wieder Code abhängig. Aber mal ehrlich, wie oft benutzt ihr das?
Am wichtigsten ist beim Debugger, dass man den Program-Flow optisch mitverfolgen kann und ab und zu in die Variablen reinspicken.
Fehlt natürlich noch Runtime-Checks, aber die würde man auf Sourcecode eben integrieren.

Z.b.

Function Blit(*rp.RastPort)
CNIF #DEBUG
If (*rp<4096) Then ERROR("Blit(): Invalid Pointer for RastPort!");
CEND
BlitBitMapRastPort *rp,...
End Function

Man könnte dann auch den Debugger von dem Runtime Check entkoppeln, also z.B. ein Release machen mit Runtime check, bei einer Beta sicherlich sinnvoll.


__________________
Check out http://www.hd-rec.de !


Geschrieben von Andi am 23.01.2009, 23:04:

 

@Wanderer
Da bleibt mir wirklich fast die Spucke weg. Was Du da beschreibst ist der Traum der meisten Basic-Progger, sozusagen die Eier legende Wollmilchsau.

Aber mal Hand aufs Herz. Das ist eine Riesenaufgabe. Deine Vorstellungen sind so visionär (ein besseres Wort ist mir grad nicht eingefallen), das braucht verdammt viel Zeit und sozusagen langen Atem. Ich bin deshalb auch dafür, dass AB3 zuerst so weit wie es geht stabilisiert wird. Und macht das so schnell wie möglich auch im Team mit Google SVN o. ä. (ich meine beides AB3 und A/A++, wenn es so weit ist). Vielleicht könnte ich auch helfen, zumindest erst einmal mit Tests.

Ich grüble nur noch darüber, ob man nicht versuchen sollte, die Erzeugung nur eines großen Sourcefiles auch abzuschütteln. Für größere Softwareprojekte ist das aus meiner Sicht ein Nachteil, wenn immer alles kompiliert werden muss (siehe C). Oder was meint Ihr?


Geschrieben von am 24.01.2009, 10:41:

 

@Andi

AB3 ist beim compilieren so schnell, da macht das gar nix aus wenn es nur ein Source ist und man den dann immer wieder komplett compilieren muß...

Nimm z.B PfPaint, das sind (mit allen Includes) ca 1,8 MB, das "rutscht" komplett in ca 13 sec mit OS4.x "durch"


Und so wie ich nun durch Bernd und Illka Lethoranta erfahren habe, könnte man das durch die Verwendung von CacheClearE anstatt per CacheClearU !!! noch erheblich beschleunigen... Das scheint zumindest auch der Grund zu sein warum unter MOS PfP compilieren so lange dauert (paar Minuten anstatt die 13sec von OS4.x)...


Geschrieben von Honitos am 24.01.2009, 11:49:

 

Zitat:
Original von Blackbird
Und so wie ich nun durch Bernd und Illka Lethoranta erfahren habe, könnte man das durch die Verwendung von CacheClearE anstatt per CacheClearU !!! noch erheblich beschleunigen... Das scheint zumindest auch der Grund zu sein warum unter MOS PfP compilieren so lange dauert (paar Minuten anstatt die 13sec von OS4.x)...



Echt ? Hast Du da mehr Infos ? Das könnte ich evtl. relativ schnell umsetzen.



@Andi:
Ich habe die Sourcen schon in einige Includes mehr aufgeteilt. Zum Beispiel habe ich den Code für die interne system1lib, die mit im Compiler steckt, bereits ausgelagert. Ebenso die ganzen Compilerfehlermeldungen.
Dadurch wird der Source übersichtlicher.


__________________
On the web at http://www.programmed-excellence.de


Geschrieben von Der_Wanderer am 24.01.2009, 13:31:

 

Sieht so aus, alss ob die Wahl des Namens schon auf A/A++ gefallen ist. Dateiendung wäre dann .app?

Ja, das hier sind Gedankenspiele und nicht die Pläne für die nächsten drei Wochen.

Wenn ich alles gut durchdenke, dann sollte das die Entwicklung von Amiblitz3 nicht stören. Irgendwann käme dann aber ein harter Schnitt.

Wenn wir AB3 ins SVN stellen, dann wäre es aber gut, den Hauptsource als .ab2 zu haben, weil man in SVN nur ASCII Dateien komfortabel Mergen kann. .bb2 wird wegen der Tokens als Binary File behandelt. Das haben wir bei PanzerZ als Testballon schon ausprobiert.
Deshalb denke ich, @honitos, das feature, Includes als .ab2 machen zu können hat ziemlich hohe priorität.

Dann könnte man auch die includes als Textfiles ins SVN stellen. So kann jeder Änderungen direkt mitverfolgen.

Nachtrag: Oder A/A+1 ? Das wäre Amiblitz Stil.

Ich werde dann man das Textbox widget AB3 fähig machen und in amiblitz3 einen NTUI Messageloop mit Testfesnter einbauen. So kann man smooth migireren.


__________________
Check out http://www.hd-rec.de !


Geschrieben von bernd_ am 24.01.2009, 15:53:

 

>wie man ihn in C programmieren würde, sondern eine >einzige, riessige C Datei erzeugt, die alles enthält. >Dann würde der GCC schneller kompilieren und >benötigt keine aufwendige Installtion.

probiers aus, kompiliere mal ein C Test file mit 200 000 Zeilen, ob die Geschwindigkeit ausreicht.

oder mal mit blitz pc demo ein grosses Programm kompilieren.Gibts da eigentlich sowas in der Grössenordnung wie hd-rec oder perfect paint ?

amiblitz programme haben zwar selten mehr als 80000 zeilen, aber da sind auch die residents, die die include files von C ersetzen.je nachdem kommen da nochmal ein paar 10000 Zeilen dazu.

>Das "*" muss man nicht mitführen. Bei NewTypes fällt >es momentan auch raus.
>Auch

muss man nicht, aber es zwingt dazu übersichtlichere Programme zu machen und es ist auch einfacher das ganze typsicher zu machen.

http://de.wikipedia.org/wiki/Ungarische_Notation

Denn es ist fatal wenn man einen Zeiger mit einem Variablen Wert verwechselt wenn man wie in C mit der ungarischen Notation nicht in die var reinschreibt was für ein Typ das ist.

>myImage\Resize(320,200) als

>image_Resize(myImage,320,200)
>zu kompilieren.

das habe ich auch schon länger her vorgeschlagen, aber Interesse hat damals keiner gezeigt.und features das keiner unterstützt, wollte ich noch nie reinbauen.

das ginge auch einfach zu machen, in dem man auch Zeiger auf funktionsaufrufe in newtypes gestattet.man müsste dann eine kennung im newtype z.b @
davorschreiben und der compiler sucht sich dann in der funktionsliste die passende Funktion, wenn der newtype entry angesprochen wird und fügt den Aufruf ein, so als ob man nen normalen call macht.

Das bei C++ grosse Problem, dass man nicht weis ohne guten Klassenbrowser welche klasse die var nun hat, hat man beim ped ja nicht, per help zeigt der gut an und man könnte auch die funcs auswählen.

>Das scheint zumindest auch der Grund zu sein warum >unter MOS PfP compilieren so lange dauert (paar >Minuten anstatt die 13sec von OS4.x)...

Hast du es nun mal auf deinem Peg unter MOS2 probiert, ob es tatsächlich schneller ist ?

ilka schrieb der testspurce mit den 76000 zeilen würde unter MOS unter 2 sec kompilieren, wenn man den cacheclearu weglässt.

Da wäre es so schnell wie bei mir.mit dem alten cacheclearu kompiliert aber der source in der grösse von pfpaint in 3 sec.ohne in unter 2 sec auf winuae mit AMD64 3000+

ob es auch was bringt wenn man es mit cachecleare ersetzt und den adressbereich eingegibt des zu löschenden cache bereichs muss aber erst getestet werden.uae jit ist es egal, aber hilft evlt bei OS4 oder MOS

EDIT 2

was man tun muss um den cachclear ganz wegzubekommen ist erstmal komplizierte Konstante ausdrücke in Programmen vermeiden.

also höchstens sowas wie i= 2*4+8

die konstanten Formelauswertung erzeugt nämlich den Code dafür und muss daher den cache löschen damit 2*4+8 ausgeführt wird und das Ergebniss dann ins programm kommt und nicht jedesmal berechnet wird.

einfache berechnungen habe ich schon in eine Art interpreter gemacht, um das cacheclear grossteils zu sparen, denn uae jit mag alzu viele cache clear auch nicht

der code wird zwtar erstellt, aber anstatt den cache zu löschen und mit einem jsr dahin zuspringen, wird der erzeugte code interpretiert und berechnet, ist quasi ne kleine 68k emu.

der code steht am anfang in dem macro newcalc
falls newcalc den code nicht ausführen kann, weil unbekannte 68k befehle vorkommen, gibt es 0 zurück und führt ihn aus.

man müsste als das so erweitern, dass auch die Befehle die pfpaint oder thilos includes benutzt verstanden werden.

perfeckt paint code löscht nur etwa 1000* den cache, aber das scheint für MOS zu viel zu sein.

schon wenn man es schafft, dass nur 250* der cache gelöscht wird, dürfte es schneller werden, man muss garnicht jeden löschen



!newcalc
BEQ 'l10
MOVE.l d0,d3
MOVEA.l (A7)+,A0
BRA bc1
'l10
MOVE.w #$2600,D1
OR.w regnum,D1
BSR.w writeword
MOVE.w #$4E75,D1
BSR.w writeword
MOVE.w dontwrite,D1
BNE.w JL_0_805C
MOVEA.l (A7)+,A0
NOP
JSR Aclearcache ;simple expression
L_0_C00A: JSR (A0) ;writeresult
bc1


Geschrieben von Der_Wanderer am 24.01.2009, 16:18:

 

Zitat:
Original von bernd_
>wie man ihn in C programmieren würde, sondern eine >einzige, riessige C Datei erzeugt, die alles enthält. >Dann würde der GCC schneller kompilieren und >benötigt keine aufwendige Installtion.

probiers aus, kompiliere mal ein C Test file mit 200 000 Zeilen, ob die Geschwindigkeit ausreicht.


Ein C code kompilieren ist deshalb so langsam, weil man der Compler sich selbst bei einem einfachen Program durch hunderte Headerfiles wühlen muss, und das jedesmal auf neue bei jeder unter Datei.
Wenn alles in einem File steht, dann geht das auch schnell. Ist natürlich nicht mehr Human-Readable der Code, aber das ist auch nicht der Sinn eine generierten Codes. Zum lesen und editieren hat man ja den A++ Code.

Zitat:

>Das "*" muss man nicht mitführen. Bei NewTypes fällt >es momentan auch raus.
>Auch

muss man nicht, aber es zwingt dazu übersichtlichere Programme zu machen und es ist auch einfacher das ganze typsicher zu machen.


Jein. Wenn der Compiler Typensicherheit beherrscht, dann muss man das nicht mitnotieren.

Zitat:

>myImage\Resize(320,200) als
>image_Resize(myImage,320,200)
>zu kompilieren.

das habe ich auch schon länger her vorgeschlagen, aber Interesse hat damals keiner gezeigt.und features das keiner unterstützt, wollte ich noch nie reinbauen.


Vielleicht ist jetzt die Zeit reif.

Zitat:

das ginge auch einfach zu machen, in dem man auch Zeiger auf funktionsaufrufe in newtypes gestattet.man müsste dann eine kennung im newtype z.b @
davorschreiben und der compiler sucht sich dann in der funktionsliste die passende Funktion, wenn der newtype entry angesprochen wird und fügt den Aufruf ein, so als ob man nen normalen call macht.


Ja, so ähnlich.

Zitat:

Das bei C++ grosse Problem, dass man nicht weis ohne guten Klassenbrowser welche klasse die var nun hat, hat man beim ped ja nicht, per help zeigt der gut an und man könnte auch die funcs auswählen.


Der Ped bräuchte eine Onlinehilfe für die klassen, so wie jetzt für die Includes. Das wäre aber im Prinzip das gleiche.


__________________
Check out http://www.hd-rec.de !


Geschrieben von Der_Wanderer am 24.01.2009, 16:23:

 

Wobei es bei A++ eigentlich um einen eigenständigen Compiler handeln würde, der schon alles macht, als Typenprüfung etc.
Er würde dann einfachen Amibitz3 Code erzeugen (oder eben auch C), der dann 100% compiliert, also keine Fehler mehr entält.

Von der Amibltiz3 Fehlermeldung hat ja dann der A++ Programmierer nicht mehr viel, ausser, dass er weiss das der A++ Compiler einen Bug enthält.


__________________
Check out http://www.hd-rec.de !


Geschrieben von bernd_ am 24.01.2009, 16:29:

 

>Wenn alles in einem File steht, dann geht das auch >schnell.

wie gesagt probiers aus, ich habe auch ein paar SDL programme wie defendguin die bestehen aus einem file von 6500 zeilen und wenig includes

das braucht schon 6 sec native gcc AM64 3000+.das ganze mal 10 bei 66000 Zeilen wären dann 66 sec.wenn der optimizer an ist, ists noch langsamer

>Jein. Wenn der Compiler Typensicherheit beherrscht, >dann muss man das nicht mitnotieren.

aber wie du lesen kannst wird vorgeschlagen es zu tun.
mich nervt es jedenfalls in C, wenn ich genau weis was ich tun will und der Compiler meckert und ich muss casten, nur weil so eine blöde Automatic denkt sie weis es besser als ich.

und ausserdem ist es bei C auch inkonsistent nen Zeiger mit *ponter zu definieren und dann mit

pointer anzusprechen.Und dann geht einer her und bringt die ungarische Notation, damit es übersichtlicher wird und man soll dann ein p davorschreiben.

oder willst du den Unsinn nur weils alle machen auch machen ?

das einfachste wäre doch wohl auf das p verzichten und schlicht und einfach den * wie in der Dekleration auch zu verwenden.

eigentlich sollten Programmiersprachen gar keine Zeiger besitzen wie doe"Sprachwissenschaftler sagen), weil man damit leicht ein Programm crashen kann und Zeiger auch in der Praxis zu 99,9% die Absturzursache sind.

aber dann wirds halt lahm, so finde ich auch ein * achtung aufpassen das ist ein Zeiger sinnvoll


Geschrieben von Der_Wanderer am 24.01.2009, 16:35:

 

Das "*" ist nicht Teil des Variablen Namens, das hast du wohl falsch verstanden. Es ist Teil des Types.

Ein "char" ist ein anderer Type als ein Pointer auf char, also "char*".

char* a;
char b;

Viele schreiben leider:

char *a;

aber das ist eigentlich falsch und lässt der Compiler durchgehen, weil ihm die Leerzeichen egal sind.
Das "*" hat eigentlich eine Funktion ist C, und macht eine Indirektion, also quasi das "Peek" und "Poke" in Basic.

Warum sollte bei

Alien\x = 123

dich interessieren, wie die Varialbe erzeugt wurde?
Ist doch egal, ob der Speicher nun mit Allocmen geholt wurde oder ob das der Basic/C Compiler für dich getan hat. Es gibt natürlich Fälle, da will man das unterstriechen, dafür kann man dann die Ungarische Notation verwenden. Ich mache dann i.a. ein "P" hintendran.


__________________
Check out http://www.hd-rec.de !


Geschrieben von Der_Wanderer am 24.01.2009, 16:39:

 

Z.b. kann man un Amiblitz nur mit NewTypes korrekt arbeiten.

*mypointer.l = ...

Ich komme niemals an den Inhalt des Pointers, ich muss Peek und Poke bemühen. Das kommt daher, weil man nicht zwischen Pointe rund Inhalt differenzieren kann bei dieser Notation. Das geht nur indirekt mit Newtypes.


__________________
Check out http://www.hd-rec.de !


Geschrieben von am 24.01.2009, 16:40:

 

@bernd

Zitat:

Hast du es nun mal auf deinem Peg unter MOS2 probiert, ob es tatsächlich schneller ist ?



nein, habe ich nicht weil:

ich den Source und das AB3 das zum testen verwendet wird nicht auf dem PEG1 ist...

ich noch nicht dazukam....

und

ich nur die Demo von MOS2.0 habe, Illka verwendet MOS2.2 !


Geschrieben von bernd_ am 24.01.2009, 16:40:

 

>Alien\x = 123

weil wenn der Compiler den speicher erzeugt, es immer sicher ist, dass der auch da ist, man kann also bei merkwürdigen crashes, mem trashes davon ausgehen, dass das Problem daher nicht kommt.

bei amiblitz muss man nur die mit * gekennzeichneten vars mit vartrace überwachen um Fehlfunktionen zu sehen, aber wenn es nicht gekennzeichnet ist, und man den Code nicht geschrieben hat, wird es schwieriger

>ich nur die Demo von MOS2.0 habe, Illka verwendet >MOS2.2 !

die Demo müsste man auch auf 2.2 updaten können.

Ilka hat reportet, der perfekt paint progressbalken geht bei ihm gleich schnell, bei dir wird der aber wie bei mir langsamer, wie du schriebst

vielleicht hat Ilka nur ne andre setting oder so.


Geschrieben von am 24.01.2009, 16:47:

 

Zitat:
Original von bernd_
>Alien\x = 123

weil wenn der Compiler den speicher erzeugt, es immer sicher ist, dass der auch da ist, man kann also bei merkwürdigen crashes, mem trashes davon ausgehen, dass das Problem daher nicht kommt.

bei amiblitz muss man nur die mit * gekennzeichneten vars mit vartrace überwachen um Fehlfunktionen zu sehen, aber wenn es nicht gekennzeichnet ist, und man den Code nicht geschrieben hat, wird es schwieriger

>ich nur die Demo von MOS2.0 habe, Illka verwendet >MOS2.2 !

die Demo müsste man auch auf 2.2 updaten können.

Ilka hat reportet, der perfekt paint progressbalken geht bei ihm gleich schnell, bei dir wird der aber wie bei mir langsamer, wie du schriebst

vielleicht hat Ilka nur ne andre setting oder so.



stimmt schon, aber ich muß das erstmal machen.... um die Aussagen dann auch exakt wiedersprechen oder bestättigen zu können...gib mir etwas Zeit, es rennt ja nicht davon...


Geschrieben von bernd_ am 24.01.2009, 17:10:

 

ich habe lediglich mal nachgefragt, on du es probiert hast, von dass du es sofort machen sollst habe ich nix geschrieben

hier gibts übrigens auch nen crossassembler der 68k code in X86 code übersetzt, leider ist das Ding nicht freeware.

http://www.microapl.co.uk/Porting/Demo68Kto86.html

um amiblitz an ne andre CPU anzupassen ist zumindest für die FPU einfach, da das alte blitzbasic keinen FPU support hatte.

und somit ist die FPU anpassung sowas wie nen Code generator schreiben.

die stellen findet man wenn man tst.b fpu tst.b iee sucht.z.b der code für FPU add

macht man ne neue CPU dazu, dann muss man den hex wert auf den Befehlsode der neuen CPU ändern.

am betsen macht ein array mit der basis für dsie target CPU

dann braucht man nur mit lea die adresse laden und den offset dazuzählen z.b so

68kcpu

dc.l $xxxxxxxxxx load a long var in a register
dc.l $xxxxxxxxxx add a .long
dc.l $xxxxxxxxxx sub a long

und dann defines
#target_load_to_reg_long 0
#target_add_long 4
#target_sub_long 8

bei 68k is das zb

$f2000022 für fadd fp0,fp1

Dann muss man noch den Code schreiben, wie die regnum dazuaddierert wird um andre register anzusprechen.

AB2 verwendet keine beliebigen Register, es verwendet immer das fpx, fpx+1 Modell

wenn regnum = 1 ist, dann muss also der erzeugt code so sein

fadd.x fp1,fp2



fadd1
MOVEQ #0,d0

MOVE.w regnum,d0
ADDQ #1,d0
ASL.w #8,d0
ASL.w #2,d0
MOVE.l #$f2000022,d1 ;fpu add
OR.l d0,d1
MOVE.w regnum,d0
ASL.w #7,d0
OR.l d0,d1
BRA.w writelong
AJL_0_A0C0:
TST.b iee
BNE fadd1
MOVE.w #$FFBE,D1 ;floatadd
JL_0_A0C4: MOVE.w D1,AL_0_2A5C
BSR.w JL_0_AD40
MOVE.l D4,D1
BSR.w JL_0_AD38
MOVE.w #$C900,D1
BSR.w Atokejsr
BSR.w JL_0_A352
MOVE.l AL_0_2A5A,D1
BSR.w writelong
BSR.w JL_0_A36E
MOVE.l D5,D1
BRA.w JL_0_AD38

Im prinzip ist die fpu auch aufweniger aus der Integer Teil, da es die ganzen sin cos tan etc funcs gibt.

Da muss man dann auch schauen, welcher hexwert die neue CPU hat.

z.b von den FPU funcs

MOVE.w regnumstore,d1
MOVE.w d1,d0
ASL.w #7,d1
ASL.w #8,d0
ASL.w #2,d0
OR.w d0,d1
MOVE.b 25(a2),d0
CMP.b #5,d0
BNE 'nocos
OR.l #$f200001d,d1 ;fpu cos
BRA 'exit
'nocos
CMP.b #$c,d0
BNE 'nosqr
OR.l #$f2000004,d1 ;fpu sqr
BRA 'exit
'nosqr
CMP.b #$d,d0
BNE 'notan
OR.l #$f200000f,d1 ;fpu tan
BRA 'exit
'notan
CMP.b #$a,d0
BNE 'nosin
OR.l #$f200000e,d1 ;fpu sin
BRA 'exit
'nosin
CMP.b #$3,d0
BNE 'noasin
OR.l #$f200000c,d1 ;fpu asin
BRA 'exit
'noasin
CMP.b #$2,d0
BNE 'noacos
OR.l #$f200001c,d1 ;fpu acos
BRA 'exit
'noacos
CMP.b #$4,d0
BNE 'noatan
OR.l #$f200000a,d1 ;fpu atan
BRA 'exit
'noatan
CMP.b #$e,d0
BNE 'nohtan
OR.l #$f2000009,d1 ;fpu htan
BRA 'exit
'nohtan
CMP.b #$6,d0
BNE 'nohcos
OR.l #$f2000019,d1 ;fpu hcos
BRA 'exit
'nohcos
CMP.b #$b,d0
BNE 'nohsin
OR.l #$f2000002,d1 ;fpu hsin
BRA 'exit

'nohsin
CMP.b #$9,d0
BNE 'nolog
OR.l #$f2000014,d1 ;fpu log
BRA 'exit
'nolog
CMP.b #$8,d0
BNE 'nolog10
OR.l #$f2000015,d1 ;fpu log10
BRA 'exit
'nolog10
CMP.b #$7,d0
BNE 'noexp
OR.l #$f2000010,d1 ;fpu exp
BRA 'exit
'noexp


Geschrieben von Der_Wanderer am 24.01.2009, 17:21:

 

Ist das schwierigste nicht die Anbindung an das OS, also der Statup und Library Aufrufe? Auch funktionsaufruefe wuerde man anders machen, via Stack.
Eines ´Cross-compilieren stelle ich mir nicht so schwer vor.


__________________
Check out http://www.hd-rec.de !


Geschrieben von am 24.01.2009, 18:47:

 

@bernd

Zitat:

ich habe lediglich mal nachgefragt, on du es probiert hast, von dass du es sofort machen sollst habe ich nix geschrieben



nicht so feindselig Bernd, habe doch nur angemerkt das ih noch nicht dazu kam....

Aber da ich heute etwas Zeit übrig habe, habe ich das Archiv zusammen mit deinem Update installiert !

Tja, und das Ergebni? ?

ich habe nun unter MOS2.0 Demo 7sec für den Source !!!

Also denke ich das Illka da unter MOS2.2 die angegebene Zeit erreicht...

Das bedeutet das seine Aussage richtig ist !


Geschrieben von Der_Wanderer am 24.01.2009, 20:40:

 

Nemnt mir nicht den Thread weg ;-)

Man könnte auch den Ansatz von MonkeyScript weiterverfolgen:

Ich schreibe einen Compiler, der das Programm auf eine Virtuelle Binary bringt. Dank MonkeyScript habe ich darin Erfahrung, man könnte darauf aufbauen.

Diese Virtuelle Binary kann man dann entweder mit einem Interpreter ausführen, oder in Amiblitz3, Assembler oder C Code umwandeln.


Beispiel:

code:

If (a=b) {
  a=a+2*b
}
Print "Test"



Das wäre ein kleines MonkeyScript Program.

Als Virtuelles Binary von meinem Compiler geparsed (und nun bereits Compiler-fehlerfrei) sieht es so aus (natürlich nicht in Textform, sondern mit Function IDs):

code:

branch( .endiflabel , equal.l( getvar.l(a) , getvar.l(b) ) );
let.l( addr(a) , add.l( getvar.l(a) , mul.l( 2 , getvar.l(b) ) ) );
.endiflabel
print("test");



Der Compiler normalisiert also alles in Prefix Form. (vgl. Infix):

Infix: a + b
Prefix: + a b oder eben add(a,b)


Dadurch lässt sich das durch eine Keller-Maschine linear abarbeiten. Ideal für einen Interpreter, aber auch zur Codegenerierung.

Wobei hier folgende Funktionen benutzt wurden:

void branch(address,bool) ; springe zu address, wenn bool erfüllt
int let.l(address,int) ; kopiere int nach address
void print(string) ; gebe string in Console aus
int getvar.l(address) ; hole int von address
bool equal.l(int,int) ; wenn int=int, dann true, sonst false
int add.l(int,int) ; addiere int und int
int mul.l(int,int) ; multipliziere int mit int

Es gibt nur ein kleines Set von Grundfunktionen.
Die könnte man dann entweder direkt als Maschinencode, als Assembler, als C oder als Amiblitz formulieren, oder eben Interpretieren. Wobei man natürlich keine Funktionen, sondern Macros benutzen würde.

z.B.
int add.l(int,int) wäre

Move.l -(a7),D0 ; D0 als scratch Register
Add.l -(a7),D0
Move.l D0,(a7)+

Es holt sich also die Arguemente vom Stack und schreibt das ergebnis wieder auf den Stack.

Beispiel

code:

a = a + 2*b



Wäre als Virtuelles Binary:

code:

let.l (addr(a),add(getvar(a),mul(2,getvar(b)))



Ausgerollt von innen nach aussen:
code:

getvar(b)
Konstante 2
mul(int,int)
getvar(a)
add(int,int)
addr(a)
let.l(variable,int)



In Assembler Code umwandeln ist dann trivial (Macro Lookup):

code:

Move.l (address_of_b),(A7)+   ; getvar(b)

Move.l #2,(A7)+               ; Konstante 2

Move.l -(A7),D0               ; mul(int,int)
Muls.l -(A7),D0
Move.l D0,(A7)+

Move.l (address_of_a),(A7)+   ; getvar(a)

Move.l -(A7),D0               ; add(int,int)
Add.l -(A7),D0
Move.l D0,(A7)+

Move.l address_of_a,(a7)+     ; addr(a)

Move.l -(A7),A0               ; let.l(variable,int)
Move.l -(A7),(A0)




address_of_a und address_of_b sind zur Compilezeit bekannte Konstanten.
Da lässt sich natürlich noch einiges optimieren, aber es würde so funktionieren. Das Optimieren würde ich dann aber dem jeweils drunterliegenden Compiler überlassen, denn da kann man schnell vom hundertsten ins tausendste kommen und sich auch flexibilität verbauen.

Als Amibitz3 code könnte man(neben dem Assembler) das auch so rück-übersetzen:
code:

a.l = a.l + (2*b.l)



Vorteile des Ansatzes:

1. Der Compiler wäre in Amiblitz3 für den Flat-Start geschrieben, kann später dann A++ sein. Ist aber sehr übersichtlich dadurch.

2. Das Virtuelle Binary kann leicht umgewandelt werden, durch:
- Interpreter (z.B. in Amiblitz/C oder wiederum A++ geschrieben)
- C - compiler
- Amiblitz3
- Assembler
- eigener Codegenerator

Dadurch sehr gut portabel auf CPU Ebene.

3. Die Portabilität auf OS Ebene käme dann durch eine Portierung der Inlcudes. Etwa 50% der Inlcudes nutzen gar keine AmigaOS API, wären also sofort portabel.
Mit NTUI aus Hauseigene GUI Toolkit wäre man auch leicht auf Windows oder Linux portierbar. Man müsste nur den Messageloop und das Linienzeichen ersetzen. Den Rest macht ja NTUI schon im eigenen Code.

Warum nicht gleich C?

1. Weil das "Drumherum" zu umständlich ist. Es sollte ein IDE sein, Print "Hello World" sollte bereits genügen.
2. Strings. Es sollte ein gutes Stringhandling geben
3. Durch die Inlcudes eine High-Level API, OOP Basic style

Warum nicht Amiblitz3?

1. Gute Frage!
2. Veränderungen einfacher, z.B. OOP oder andere CPUs

Warum nicht A++?

Es spricht auch was dagegen:

1. Zeitaufwand
2. Compiliert langsamer als Amiblitz.
(zumindest beim ersten Durchlauf, man kann sich auch geschicktes Caching überlegen, so wie bei C oder noch besser)


__________________
Check out http://www.hd-rec.de !


Geschrieben von bernd_ am 25.01.2009, 15:01:

 

>Ist das schwierigste nicht die Anbindung an das OS, >also der Statup und Library Aufrufe?

ne das ist ja immer gleich, einmal gemacht geht es mit 1000 von Funktionen.Da können sich dann nicht so leicht vesteckte Bugs einschleichen.

Aber wenn du mal monkey script releasen würdest und es welche gäbe die damit was machen würden, dann würden da meiner Meinung nach sehr schnell Fehler in Deinem Befehls Parser gefunden werden, die bei dir nie aufgetreten sind, weil Du nicht alle milliarden möglichen Formelschreibweisen durchtesten kannst.Bei deinem Programmierstiel fällt es halt nicht auf.Das ist auch der Grund, warum gcc so viele Bugs hat.Auch wenn du gcc nutzt, der preprozessor muss ja auch den C Code generieren.klar, bei 1 oder 2 Beispielen die du hier postest geht es, aber weist du was welche für Formeln schreiben, die mathematisch richtig sind, aber trotzdem verdeckte Fehler auslösen ?

du stellst dir das alles zu einfach vor.

dagegen kann man den startup code durchtesten, und die Funktionsaufrufe mit 1-20 parameter.Und wenn das geht läuft es.

alles in allem muss man wenn man etwas nativ unterstützen will auf jedenfall sich auch die Hardware dafür zulegen,muss source Level debugger schreiben um zu sehen wie der code aussieht den man generiert etc.

Das C nicht sonderlich portabel ist, das hat sich auch rumgesprochen, deshalb wird auch bei neuentwicklungen mehr und mehr in einer Virtuellen CPU wie java oder .net entwickelt und das obwohl sich java oder .net ziemlich träge anfühlt.Ich denke mal wäre java .net so flott wie AOS mit MUI oder TUI und winuae, dann gäbe es noch weniger die native Coden würden.

halt apps die vor Jahren in C begonnen wurden, wird man wohl kaum umschreiben, aber neuteile könnte man in JAVA .net schreiben wenn es schneller wäre.vielleicht das Problem weils keine Zeiger gibt und das ganze wenn es das gibt adresscheck macht

für die ati grafikkarten gibts seit einiger zeit das kontrollpanal in .net.

Das ist dermassen langsam, so ein langsames Programm zu schreiben, wäre mit nem A500 und amiblitz garnicht möglich.Ich denke wenn amiblitz .net code erzeugen würde, könnte man auch kein so lahmes Programm schreiben.

Auch ein Nachteil des Objektorientierten, es erlaubt möglichkeiten die wenn man glück hat 5% Code schreiben ersparen (ich sehe aber immer wie es innerhalb eines Programms mehr deklaration ist) , aber das Programm 500% langsamer machen.

Dann muss man erst mühsam optimieren, umschreiben, und letzendlich muss man es dann doch anders machen oder mit nem langsamen Programm leben.

alles in allem hat es am meisten Einfluss auf die speed wie man ein Programm schreibt und nicht ob es native oder virtuell ist.

in C++ kann man mit a=b 100 000 CPU Taktzyklen erzeugen.

in amiblitz ginge das auch, aber ich habe es nicht gemacht und den Befehl copytype reingebaut. da sieht man dann, dass die CPU arbeiten muss und man vermeidet unnötiges.

Man kann in amiblitz einfach a$=a$+char$ schreiben und sieht einfach aus.

Aber intern wurde bei jedem + speicher angefordert, alter string kopiert/freigebeben .wird also bei jedem zeichen ein allocmem freemem ausgeführt.

Da die wenigsten sich den dazugehörigen asm code angucken, kommen so halt langsame Programme bei raus.

amiblitz hat aber das Feature maxlen da kann man das speicher allozieren vermeiden, wenn man vorher soviel string mem anfordert

ausserdem habe ich nun die lib so geändert, dass immer 4 bytes mehr alloziert werden, da wird nur jedes 4. mal speicher angefordert.

Da amiblitz aber nicht so komplexe Möglichkeiten zulässt wie objektorientierte Sprachen, lässt sich das einfach lösen.

>(zumindest beim ersten Durchlauf, man kann sich auch >geschicktes Caching überlegen, so wie bei C oder noch >besser)

das nennt sich dann linken.
aber letztendlich kompiliert amiblitz schneller als C linkt.probiers aus.

und zu den C kompile zeiten musste dann auch noch die Zeit des Preprozessor zählen.

Du solltest dich echt mal mit C++ beschäftigen, kompilier mal den firefox oder den OWB, wie lange das dauert.

C programmierer nehmen bestimmt nicht aus Spass das aufsplitten von Programmen in soviele Teile in Kauf, mehrfach einlesen von Headern, aber es ist nunmal die einzigste möglichkeit dass man nicht so lange warten muss wenn man an neuen Funktionen schreibt, und der grossteil des Programms aber unverändert bleibt


Geschrieben von Der_Wanderer am 25.01.2009, 17:05:

 

Bernd, ich programmiere beruflich mit C und C++, du musst mir also nicht erklären wie langsam das ist und was die Vor und Nachteile sind.

Ich will auch kein Hardcore OOP machen, wo jeder String ein eigenes Objekt ist, aber z.B. Screen, Window, Image, Sound, File, da würde sich das anbieten.

Wenn ich es mit genau überlege, dann wäre A ungefähr auf dem Level wie C, nur vielleicht sogar noch etwas restriktiver. Darauf setzen dann die Inlcudes auf, die OOP Style gecoded sind, mit Resourcenmanager, das wäre dann A++. Ich denke das wäre eine sehr schöne Sprache die für alles gut zu gebrauchen ist, so wie Amiblitz3 auch, nur dass man die Grenzen was CPU, Zielplatform und Neuerungen angeht leichter sprengen kann.

Ich habe MonkeyScript schon lange released, ist in den Sourcecodes dabei. Aber ich packe dir mal hier ein Binary Packet zusammen, mit Beispiel Code.

MonkeyScript ist aber nur zu 90% fertig und nicht gedacht, ausführbare Programme zu generieren. Es hat z.B. keine Funktionen. Als Funktion wird dort ein Script angesehen. Dafür kann man viele Scripte parallel laufen lassen, die auch miteinander kommunizieren können, und es gibt Globale Variablen, die Zur Laufzeit angelegt werden können. Es gibt keine Pointer, weil man die komplette MonkeyScript Sandbox abfreezen und speichern kann. Das ist wichtig für Spielstände.

Stell dir vor, du müsstest in einem Spiel beim speichern/laden die ganzen laufenden Scripte wiederherstellen in dem Zustand wie sie gerade beim Speichern waren. Von aussen kaum machbar.
(übrigends noch ein Vorteil gegenüber eine Amiblitz3 impelemtierung von Gegenern oder Abläufen)


__________________
Check out http://www.hd-rec.de !


Geschrieben von Der_Wanderer am 25.01.2009, 17:13:

 

Hier ist ist ein Binary mit Beispielen:

http://www.hd-rec.de/Archive/msExamples.lha

Starten tut man das mit

msh clock.msc

oder einfach "msh" für die Options.

msh ist ein total simples Program, dass nichts anderes macht als die angegebene Datei an den MonkeyScript Compiler zu reichen und dann auszuführen. Man kann ach ein Virtuelles Binary speichern und nur das ausführen.

Normalerweise würde man ein MonkeyScript nicht mit diesem Programm ausführen, sondern mit der eigenen Applikation/Game.
Deshalb sind die I/O Möglichkeiten auch sehr beschränkt. I/O sind normalerweise eigene Funktionen, die man bereitstellt, z.B. das zeichnen eines Sprites.

Achja, die Warning: Variable already declared! bitte ignorieren, das kommt fehlerhafterweise noch.


__________________
Check out http://www.hd-rec.de !


Geschrieben von am 25.01.2009, 18:59:

 

@Der Wanderer

Zitat:

Nemnt mir nicht den Thread weg



da würde ich doch im Traum nie drauf kommen !


@bernd

ich habe mir gerade das Demo von MOS2.2 gesaugt und da ISo gebrannt....

werde sobald ich dazu komme dann den Test wiederholen. Ich sag dir dann bescheid sobald ich verwertbare Infos habe...

Powered by: Burning Board 1.2 © 2001-2002 by WoltLab GbR