Zitat:

---

Original von Der_Wanderer:
@Ralf
Das stimmt einfach nicht. Amiblitz ist sehr änhlich zu anderen Basic Dialekten. Allerdings hat man ZUSÄTZLICH die Möglichkeit, etwas komplexer und strukturierter zu programieren, was dann eher in die Richtung C geht. Aber man MUSS das nicht. Es gibt auch inline 68K, x86 und PPC Assembler. Aber man MUSS es nicht benutzen. Man kann auch schön brav bei Standard Basic bleiben. Es gibt natürlich ein paar syntaktische Abweichungen, aber das gibts in jedem Basic Dialekt.

Ich bin ja dabei, quasi ein neues Basic API zu schreiben, d.h. einen neuen Befehlssatz für Amiblitz, der Amiblitz mit EINFACHEN Befehlen dazu befähigt, aktuelle Dinge zu tun, wie 24bit Bilder, AHI sound oder TCP/IP, und zwar systemkonform. Eben das, was "alten" Basics fehlt, oder eben nur im "C Stil" hineinbauen lässt.

---

Ähm, wo bitte ist AmiBlitz sehr ähnlich zu anderen Basicdialekten?!? Das ist ungefähr so als wenn man C mit Basic vergleichen würde, bzw. sagen würde es war ähnlich, ist es aber nicht.

Ich geb dir mal ein Beispiel:
Ich hab in AmigaBasic begonnen und hab damals mal QBasic auf dem PC gesehn das 99% genau so aussieht. Ich konnte sofort(!) ohne weiteres darauf programmieren. Logischerweise sind Befehle wie z.b. Screen etwas anderest (einfacher) aufgebaut, was aber klar ist.
Dann ist MBasic gekommen das 99,9% so aussieht wie AmigaBasic.
Ich könnte jetzt fast weitermachen mit z.b. ACE, das ich kurz mal angetestet habe und auch gleich kleine testprogramme schreiben konnte...

Also, wer eine der Sprachen kann, kann die anderen auch.
AmiBlitz würde da ganz und gar nicht rein passen. Ich vermute mal das es einfach ist, wenn man es kann. Aber das reinkommen ist nicht so einfach.
Du schreibst ja selbst das es komplex sein kann.

Nichts desto trotz verfolge ich natürlich auch die AmiBlitzgeschichte mit und hab mir auch mal die neueste Beta angesehn, die verständlicherweise noch nicht ganz stabil ist. Ich versteh von dem Quellcode aber weniger als von einem C-Quellcode und das tippe ich als Basic-Programmierer ...

--
http://www.alternativercomputerclub.de.vu

Zitat:

---

Original von Der_Wanderer:
BTW, in Amiblitz wäre so ein Anzeiger ein paar wenige Zeilen. ;-)

---

Aber bestimmt nur für jemanden der AmiBlitz kann...
--
http://www.alternativercomputerclub.de.vu

Zitat:

---

Original von NoImag:
@Ralf27:
MBasic lässt sich mit Sicherheit entsprechend patchen. Es dürfte aber weniger Aufwand sein, gleich einen neuen Basic-Compiler zu schreiben.

Tschüß

---

Zitat:

---

Original von Holger:
So benutzt der durchschnittliche Programmierer normalerweise z.B. x<<5 statt x*32, weil die Integer Einheit der CPU das schneller verarbeiten kann. Wenn man aber im Code sieht, dass MBasic für ersteres (im Gegensatz zum zweiten Konstrukt) ein extra Unterprogramm aufruft, inkl. diversen Register-Verschiebe und -Sicherungs-Overhead, dann versteht man sehr schnell, warum ein C oder Assemblerprogramm um Welten schneller ist, wenn man ein normales, durchschnittlich optimiertes Programm heranzieht.
Ein unnormales, nicht oder falsch optimiertes Programm mag dafür aber in MBasic die gleiche Performance wie in C hinlegen. Je nachdem.

---

Zitat:

---

Original von MaikG:
>Außerdem gibt es keine Fehlerkontrolle (z.b. bei Poke) bei MBasic.

Hab ja auch fast geschrieben.

>Steht glaub ich auch in der Doku. Z.b. dürfte dann z.b. Pokel 4,0 nie laufen.

Wieso sollte das nicht gehen? Du kannst eine 0 an position 4 schreiben.

---

Zitat:

---

>Dann laufen die MB-Programme nicht mehr auf einem 6800er?

Ja, führen zum Deathend. Versuchst du immernoch zum 000er kompatibel
zu sein?

---

Zitat:

---

Original von MaikG:
ASM ist auch schneller als C, das war nicht die frage.
Fast jeder Maxonbasic befehl hat eine unmenge an sicherheitabfragen,
weil der User könnte ja was falsches übergeben oder es könnte
was unerwartet auftreten.
Unter ASM kannst du ganz genau das machen was du willst,
normalerweise weiss man ja welche eingaben kommen können und
daher legt man die überprüfungen selbst fest.

---

Das ASM schneller ist als C war vielleicht noch zur 68000er Zeit richtig. Allerdings wird es schon beim 020er schwerer ASM mit der Hand zu optimieren. Der C-Compiler bekommt das schon besser hin.
Also bekommt man heute mit C schnellere Programme hin als mit ASM, weil der Compiler besser optimieren kann. Bzw. könnte man das auch mit ASM machen, allerdings wäre das wirklich hochkomplex.

Außerdem gibt es keine Fehlerkontrolle (z.b. bei Poke) bei MBasic. Steht glaub ich auch in der Doku. Z.b. dürfte dann z.b. Pokel 4,0 nie laufen. Könnte man eine Fehlerkontrolle z.b. bei Poke einbauen, dann hätte man sogar schon Speicherschutz.

Zitat:

---

>Außerdem: MBasic scheint wohl nur reinen 68000er-Code zu generieren.

Jain, einige befehle z.b. ungrade adressionen erfordern den 020...
Das DTMF teil hab ich auf C sogar auf 68060 optimiert, war trotzdem
nicht schneller als MB.

---

Zitat:

---

>Und: Es gehen auch keine Befehle die FPU-Register belegt haben
>möchten. Ich tippe hier z.b. von 3D-Libs. Das ist eine der vielen
>Grenzen von MB.

Von 3D hab ich keinen schimmer, ich meinte auch die grenzen der
Geschwindigkeit.

---

Zitat:

---

Original von NoImag:

Zitat:

---

Original von hansfaust:
NB: für die Freunde, die von Basic kommen: das Semikolon am Ende eines Ausdrucks ist für den C-Compiler sehr wichtig, damit er weiß, wo ich als Programmierer das Ende eines Ausdrucks haben will. Ich könnte so sogar mehrere Ausdrücke in eine Zeile schreiben, wo ich in Basic zwingend mehrere Zeilen dazu brauche.

z.B.
ULONG a, b, c;

b = 345; c = (28 / 7); a = b + c;

---

Nur zur Info:
In Basic gibt es den Doppelpunkt:

b& = 345 : c& = (28 / 7) : a& = b& + c&

---

code:

---

DEFLNG a,b,c

b=345 : c=(28/7) : a=b+c

---

So würde das aussehn wenn man es wirklich fast(ULONG gibt es eigentlich nicht bei Basic, leider ist alles Vorzeichenbehaftet) 1 zu 1 nach Basic übersetzen würde.
--
http://www.alternativercomputerclub.de.vu

Zitat:

---

Original von MaikG:

>Es gibt einen ganz einfachen Grund von Basic (bzw. MaxonBasic) weg
>zu kommen und das ist vor allem die unglaublich geringe
>Geschwindigkeit von MBasic bzw. von Basic.

Das sagst du, ich bin an keine MB grenzen gestossen.
Ich erinnere nur mal an die DTMF erkennung C genauso lahm
wie MBasic.

---

Dann frag ich mich, wieso sonst keiner mehr in MBasic programmiert wenn es keine Grenzen hat?

Ich hab mal für ein Projekt eine Routine von MBasic nach ASM konvertiert und dann auch gleich das ganze möglichst an die Möglichkeiten von ASM angepasst. Mit ASM sind halt einfache Bitmanipulationen einfacherer als in Basic(Ja, geht wohl auch mit C, aber damals hab ich es halt in ASM gemacht). Und, was soll ich tippen, ASM war wesentlich schneller. Und das, obwohl ich kaum ASM kann bzw. eigentlich nichts an die "neueren" 68k-Prozessoren angepasst war.

Geschwindigkeitstechnisch stoße ich immer wieder an die Grenzen von MB. Aber es kommt halt auch darauf an was man programmieren möchte.

Selbst ACE ist im Integerbereich schneller(!) als MBasic. Außerdem: MBasic scheint wohl nur reinen 68000er-Code zu generieren.

Und: Es gehen auch keine Befehle die FPU-Register belegt haben möchten. Ich tippe hier z.b. von 3D-Libs. Das ist eine der vielen Grenzen von MB.
--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 19.08.2007 um 11:48 Uhr geändert. ]

Zitat:

---

Original von Bogomil76:
"Also wenn man keine Ahnung hat, einfach mal die Fresse halten"
Sorry, is ein Zitat, passt aber. Wie witzig, dann scheint Dein "Beauftrager" ja noch weniger Ahnung zu haben als Du

---

Zitat:

---

Wie auch immer: Win98 kannst Du nicht "sicher" machen.
Bzw. was versteht man denn unter "sicher"?

---

Zja, das ist der Knackpunkt: Sicher vor Büromenschen reicht. Denn die könnten sicher auch auf die Idee kommen und statt in der Startleiste rumzusuchen auch direkt auf die Festplatte zugreifen oder gar die Suchfunktion benutzen.

Also eigentlich nur sicher gegen Ottonormaluser. Unnd nix gegen Firmenspionage oder dergleichen. Das wäre ja wirklich der Brüller.


--
http://www.alternativercomputerclub.de.vu