Zitat:

---

Danke, also ausgeführt wird der Initcode nur 1x. Er ist nicht in der Open-Funktion, sondern in der Initfunktion. Oder kann es sein, dass der Initcode aus irgendwelchen Gründen nochmal aufgerufen wird? Ich bin auch schon den Initcode in Trace durch gegangen, da wird nach jedem Call, der Festplattenzugriffe aus löst, genug lang gewartet, bis er fertig ist. Oder nicht?

---

Zitat:

---

Libraries, device, settings, bilder etc nur in lib_open öffnen. lib_init ist nur zum Initialisieren globaler Resourcen wie Semaphoren gedacht.

---

Zitat:

---

ich programmiere das in assembler. "Libbase in der Libbase selbst" verstehe ich nicht.

---

code:

---

1)
    STRUCTURE LibraryHeader,0
    ...
    APTR    lh_GfxBase
    ...
    LABEL   SIZEOF_LibraryHeader
   
_LibOpen ; A6 -> LibraryHeader
    ...
    move.l  A6,-(sp)
    movea.l lh_GfxBase(A6),A6
    ...
    ...
    movea.l (sp)+,A6
    ...
    rts

2)
_LibOpen ; A6 -> LibraryHeader
    ...
    move.l  A6,-(sp)
    movea.l _GfxBase,A6
    ...
    ...
    movea.l (sp)+,A6
    ...
    rts

    ...

_GfxBase
    dc.l 0

---

Zitat:

---

Bug oder eher missing Feature?
Womöglich war es damals nur nicht nötig mehr als 104 Tasten zu haben....

---

Zitat:

---

Auf dem Amiga gibt es ja auch keine Pos1-Taste.

---

Zitat:

---

Die kann also nur funktionieren, wenn Du ihr von Hand eine Funktion zuweist, die Du als richtiges Äquivalent erachtest.

---

Ich bin unschuldig und halte mich an Spezifikationen.

Hier einen kleinen Auszug für die entsprechenden RAWKEY-Codes.

code:

---

/* OS 4 and old declaration from '96 */
#define RAWKEY_INSERT		0x47
#define RAWKEY_PAGEUP		0x48
#define RAWKEY_PAGEDOWN		0x49
#define RAWKEY_F11		0x4B
#define RAWKEY_PRINTSCR		0x6D
#define RAWKEY_BREAK		0x6E
#define RAWKEY_F12		0x6F
#define RAWKEY_HOME		0x70
#define RAWKEY_END		0x71
...
#define RAWKEY_HOME_ALT		0x75
#define RAWKEY_END_ALT		0x76
#define RAWKEY_PAGEUP_ALT	0x77
#define RAWKEY_PAGEDOWN_ALT	0x78
#define RAWKEY_PRINTSCR_ALT	0x7B
...

---

Zitat:

---

1. Nach längerer intensiver Benutzung fängt die Maus an zu Springen.

---

Zitat:

---

2. Shift, Capslock, Alt etc. bleiben des öfteren hängen.

---

Zitat:

---

3. Wenn ich zum Windows Desktop wechsele, und WinUAE im Hintergrund aktiv bleibt, dann empfängt er zwar keine Keyboard Events mehr, aber Maus Events und Clipboard Events (ich nutze Shared Clipboard).

---

Zitat:

---

5. Im Fullscreen Modus braucht WinUAE beim Umschalten eine gefühlte Ewigkeit.

---

Zitat:

---

Mittlerweile habe ich noch ein bisschen rumprobiert, komme aber nicht weiter.
Der Sourcecode an sich ist nicht problematisch, weil das Programm selbst nicht auf Hardware zugreift, keine GUI hat und nur ein File verändert.

---

Zitat:

---

Mein Hauptproblem ist vbcc selbst.
Ich habe die Binaries für OS3 und die Target-Icludes für OS3 installiert.

Nun crasht der Befehl vc immer dann, wenn ein bestimmtes File (eine .asm-Datei) aus t: ausgelesen werden soll. Offenbar liegt es daran, dass vc oder vbccm68k auf ein Verzeichnis "t: statt t: zugreifen will, was wohl an einem Platzhalter %s in der Config-Datei liegt. Weiß jemand, was ich da eintragen soll, damit vc keine Anführungszeichen setzt oder erwartet?

---

Zitat:

---

Und dann noch dies: Wenn ich die Befehle von Hand eingebe, bekomme ich zuerst eine .asm-Datei, danach eine .o-Datei und letztere müsste dann mit vlink zum Executable werden. Da bringt vlink aber haufenweise Fehlermeldungen namens "unexpected reference" (bin mir nicht mehr ganz sicher, wie der genaue Wortlaut ist). Was bedeutet dies?

---

Zitat:

---

weil ältere Beispielprogramme den Output-Handle immer direkt aus der Prozessstruktur ausgelesen haben.

---

Zitat:

---

Ich habe nie behauptet, vasm hält sich nicht an den Motorola-standard.

---

Zitat:

---

...kann aber mit vielen üblichen Macros nicht umgehen []

---

Zitat:

---

Und selbst der wurde ja schon in der Zeit der weiterentwicklung vom 68000 zu höheren Prozessoren von Motorola selbst geändert:-)

---

Nee, nur erweitert, bedingt durch die 68020 Adressierungen wie Du weißt.

Zitat:

---

Das Hauptproblem des vasm scheint zu sein, das er sowas wie "lokale Labels" nicht unterstützt, was bedeutet jeder verwendete Label ist auch in der Symboltable enthalten und darf nur einmal verwendet werden, somit muss z.b. jeder loop anders heissen, das erschwert alles.

---

Zitat:

---

Zum vasm: versuch mal einer der vielen ASM-Sourcecodes vom Aminet mit diesem ohne Modifikation zu assemblieren, bei den meisten wird das scheitern.

---

Da magst Du Recht haben, die Frage die sich mir aber stellt ist, ob es an 'vasm' oder am Autor des betreffenden Quellcodes liegt, der *nicht* die offizielle Schreibweise benutzte.

Ich habe selber K-Seka, C-Seka sowie MasterSeka Ende der 1980er und Anfangs der 1990er Jahre verwandt, bis ich Anfang 1991 sporadisch Devpac 2 benutzte um Vollendends in 1992 auf Devpac 3 umstieg. Dass meine damaligen Quellcodes nicht mehr von Devpac akzeptiert wurden, lag nicht an Devpac 2/3 sondern an (den) K-Seka (-Klonen). Dafür habe ich dann einen Konverter geschrieben, der den K-Seka Syntax, inklusive Makro-Schreibweise, in die offizielle Motorola Syntax umwandelt.
Lange Rede, schwacher Sinn: Es gibt eine offizielle Norm an die man sich halten sollte, wenn man sicherstellen will, dass ein Quellcode von verschiedenen Assemblern akzeptiert wird. Verwendet man spezielle Merkmale eines Assemblers, sollte man nicht dem Autor des fremden Assembler Unterlassung/Nachlässigkeit unterstellen, sondern sich selber fragen, ob man zwingend solche Besonderheiten nutzen muss, wenn man seine Quellcodes offen legt.

Wenn ich Dich richtig verstanden habe, so lassen sich viele Assembler Quellcodes die im Aminet freigegeben wurden nicht mittels 'vasm' assemblieren, weil sie auf einen bestimmten Assembler zugeschnitten sind. Deshalb aber 'vasm' als nicht kompatibel abzustufen halte ich für arg unfair dargestellt (gelinde gesagt).

Zitat:

---

Zudem hat er die C-typischen Nachteile alle übernommen, was auch nicht Motorolastandard ist.

---

Dir ist schon klar, dass 'vasm' von Dr. Volker Barthelmann ins Leben gerufen wurde, um einen portablen Assembler für verschiedene Hosts und Targets für seinen C-Compiler zu erhalten, und sich nicht nur auf m68k beschränken zu müssen. Soweit ich weiß, benutzte er anfangs Frank Willes PhxAss (m68k Assembler) und PhxLink (AmigaDOS Linker). Erst nachdem sich Frank Wille 'vasm' angenommen hat wurde aus 'vasm' ein universeller, Standards entsprechender und vielseitiger Assembler, wobei 'vasmm68k-mot' (der m68k vasm) nach wie vor noch in der Lage sein muss, den von 'vbcc' erstellten Code zu übersetzen, was nicht zuletzt ein gewisses Maß an Abwärtskompatibilität (Altlast!) zu PhxAss beinhaltet. Nichtsdestotrotz kann man ( zumindest ich ) klaglos Devpac erstellte Quellcodes mit 'vasmm68k-mot' übersetzen.

Zitat:

---

Und was nützt mir das strikte halten an den Motorolastandard, wenn ich doch verscheidene Plattformen als ziel unterstütze ? Nicht alle Prozessoren sind von Motorola !

---

Zitat:

---

Also wie gesagt, für kleinere Projekt ist der vasm durchaus geeignet, aber bei grösseren ist schon allein die labelbennenung oder das fehlen eines internen versions oder datummacros nervig. Eben wie in C, muss man alles extern selber machen, der ASM-Pro z.B.unterstützt einen da viel besser

---

Erstens, in C ist es einfacher gelöst, einfach '__DATE__' spezifizieren.
Zweitens hat es je nach Geschmack mehr Vor- oder Nachteile, wenn eine automatische Versionskontrolle ausgeführt wird. Ich persönlich mag überhaupt keine automatische Versionsänderung ohne meine explizite Angabe. Wie gesagt, andere mögen es, aber eben nicht jeder.
Drittens, ob ein Assembler für größere oder kleinere Projekte von Vorteil ist, liegt bestimmt nicht an solchen Details, sondern ob der Assembler imstande ist, in einer akzeptablen Zeit den Quellcode zu übersetzen. Bei größeren Projekten wird man sowieso mehrere Module schreiben, die man anschließend 'linkt' und nur die veränderten Dateien neu assemblieren.
Da 'vasm' sowohl direkt ausführbaren Code also auch linkbaren Code generieren kann als auch die Übersetzungszeiten akzeptabel sind, kann 'vasm' sowohl für kleinere als auch für große Projekte verwenden.

Anbei:
Wäre ich tippfaul, so würde ich für kleine Projekte einen Assembler mit IDE vorziehen, weil dies bequemer für mich wäre, als über die Kommandozeile den Assembler aufzurufen. Erst bei größeren Projekten geht es sowieso nicht mehr ohne den Umweg über die Kommandozeile um ein Skript oder ein 'makefile' aufzurufen, da meines Wissens nach keine Assembler-IDE eine 'Make'-Umgebung nachbildet.

Zitat:

---

Was ich aber eigentlich sagen wollte, für einen der sich relativ neu wieder mit dem Thema 68k-Assembler beschäftigen will, sind schon allein die meisten alten Bücher, Kurse, Anleitungen und Beispielcodes besser auf einem Sekaclone nachzuvollziehen, da diese meistens älter sind, und es da einfach noch kein vasm gab.

---

Aber es gab eine Norm, dem der MetaComCo Assembler voll entsprach, und dieser wurde dem Entwicklerpaket beigefügt, bzw. man konnte diesen nachbestellen (Kickstart 1.1/Kickstart 1.2). K-Seka hatte eine sehr große Fan-Gemeinde bei den Hobby-Programmierern, die ohne das Betriebssystem auskamen, nicht zuletzt wegen seiner rasanten Assemblierungsgeschwindigkeit. Leider entsprach er weder den Motorola Spezifikationen noch bot er einen Link-Modus an, was ihn für größere Projekte disqualifizierte. Erst mit den Klonen kam sowas wie Kompatibilität auf. Leider erbten diese Klone aber auch die schlechten Eigenschaften, z.B. 'blk' statt 'dcb' oder 'An,bd' anstatt 'bd,An'.
Ich habe mehrere 68k Assembler Bücher hier, aber nur eines benutzt den K-Seka Syntax, und zwar jenes, welches ohne das Betriebssystem die Hardware direkt anspricht, zudem kann ich die Quelltexte dieses Buches keinem empfehlen, da alle möglichen Optimierungsmöglichkeiten außer Acht gelassen wurden sowie mittels 'clr.w' Hardwareregister gelöscht wurden, wobei jeder weiß, dass das unter einer 68000er fatale Folgen hat, weil ja auch ein Read-Zyklus vor dem Löschen durchgeführt wird. Bei Nur-Schreibregister wird's dann bunt...
Um es kurz zu machen: Über die Güte eines Quellcodes sagt der verwendete Assembler nichts aus.


Um meine Sichtweise der Dinge mal darzulegen:
Ich habe nichts gegen die Verwendung von Assembler XYZ einzuwenden, jedem das seine, was ich aber nicht stehenlassen will, sind Behauptungen, bei denen Ursache und Wirkung meinem Erachten nach vertauscht werden.
Werden spezielle Charakteristiken eines Assemblers verwendet, darf man nicht mokieren, dass der betreffende Quellcode sich nur mit diesem Assembler übersetzen lässt. Z.B. erlauben Devpac und 'vasm' das Weglassen des Semikolons vor Kommentaren; andere Assembler erlauben es nicht. Will man seinen Quellcode veröffentlichen, sollte man die Notation verwenden, die alle Assembler verstehen, demnach sollte man das Semikolon verwenden. Hier einfach behaupten, dass andere Assembler nicht kompatibel genug wären, wäre zu kurz gegriffen.
Bevor ich in der Vergangenheit Quellcodes, die mit Devpac erstellt wurden offen gelegt habe, wurde mittels PhxAss und SNMA gegengeprüft, ob sie sich unverändert assemblieren ließen. Andere hätten auf die gleiche Idee kommen können und somit anderen viel Arbeit erspart.


Grüße

Zitat:

---

seit ein paar tagen nutze ich die funktionalität mittels .htaccess und einer index.var zu anderen sprachen in subdirectories umzuleiten. zB wird domain.de/ bei der browsereinstellung "de" nach domain.de/de/start.html umgeleitet.

---

code:

---

# .htaccess

Options +MultiViews
AddLanguage de .de
AddLanguage en .en
LanguagePriority de en

# Einstellungen für alternative Inhalte mit Apache 2.x
AddHandler type-map .var

# Deklaration der Dateien für die Pseudo-Index-Funktion
DirectoryIndex start.var

---

code:

---

# start.var

URI: start

URI: start.de.html
Content-type: text/html
Content-language: de
Description: "Das deutsche Original des Dokuments"

URI: start.en.html
Content-type: text/html
Content-language: en
Description: "English translation of this document"

---

Zitat:

---

Dito. Dennoch solltest Du Dein (oder eben mein System nicht als repräsentativ ansehen.

---

Zitat:

---

Es wäre interessant zu wissen, ob __M68K__ schon immer das Architektur #define von VBCC war.

---

Frank kann dies definitiv beantworten.

Zitat:

---

Wenn es eine korrekten Weg gibt und man den auch kennt, dann sollte der auch benutzt werden. Alles andere fällt einem früher oder später (meist früher immer auf die Füße...

---

Zitat:

---

Kein Compiler erzählt irgendwas über sein Host-System, denn welchen Sinn sollte das haben? Alle #defines beziehen sich ausschließlich auf das Zielsystem.

---

Das ist der Unterschied zwischen Dir und mir: Du weißt sowas, ich kann nur Vermutungen anstellen. Dementsprechend will ich auch nicht Hand an SDITools legen, sondern das sollen Programmierer mit Deiner Erfahrung tun. Ich würde es höchsten verschlimmbessern.
Ich bleib' lieber auf der sicheren Seite und melde Fehler die dann andere beheben können.


Grüße

Zitat:

---

Nur, im Programm selber wird dann wieder auf die PPC-Variante zurückgegriffen. Was da genau schief geht, kann ich nicht noch nicht sagen.

Zitat:

---

Mysteriös. Werde ich bei Gelegenheit mal testen.

---

---

Zitat:

---

Ich spezifiziere immer eine 68020 als Zielversion. Demnach testet "(defined (__VBCC__) && !defined(__PPC__))" korrekt auf 'vbcc' ungleich PPC-Backend, was dann hier bedeutet, dass es sich um m68k handelt.

Zitat:

---

Nein. Dann weißt Du nur, das es _nicht_ PPC ist. Du willst aber wissen ob es m68k ist und das testet Du bei VBCC mit __M68K__ (bei GCC wäre es __mc68000 und bei SAS/C ist es _M68000).

---

---

Zitat:

---

Du implizierst, das es 68k ist und diese Schlußfolgerung ist nicht zwangsläufig richtig.

---

Zitat:

---

So, wie sich das für mich liest, ist sein Problem das, daß es möglicherweise Compiler geben könnte, die blöd genug gebaut wurden, um Host und Target nicht eindeutig trennbar anzugeben.

---

Exakt das meinte ich.
Ich kenne/benutze nur StormC v3; 'gcc' für AmigaOS, AROS und Linux; MaxonC++ sowie vbcc für AmigaOS, MorphOS und AmigaOS4 - und Anleitungen lese ich nur bei Bedarf.
Demnach traue ich mir nicht zu, zu sagen, was andere Compiler so an vordefinierten Symbolen bereitstellen.


Grüße

Zitat:

---

Die neueste Version der SDI_compiler.h hat die verison 1.32. Die aktuellsten Versionen davon sind immer unter folgendem CVS repository frei verfügbar:

http://sditools.cvs.sourceforge.net/viewvc/sditools/sditools/headers/

---

Danke!
Werde diese herunterladen und schauen ob sich etwas geändert hat beim Kompilieren mit 'vbcc'.

Zitat:

---

Natürlich würden wir uns freuen wenn du deine Änderungen irgendwo als komplette Dateien veröffentlichen können sodass wir diese in einer neuen version der SDI headers mit aufnehmen können.

---

Zitat:

---

Also ich hatte mit den SDI Dateien und VBCC nie Probleme.

---

Zitat:

---

Ich nutze sie für alle meine Projekte ausgiebig. Installer, MMKeyboard, Meridian, IRCom, ...

Sowohl für 68K also auch für PPC und AROS_x86.

---

Zitat:

---

Das angegebene SDI_compiler.h sieht aber korrekt aus.

---

Ja, und komischerweise wird das REG-Makro ja auch definiert. Nur, im Programm selber wird dann wieder auf die PPC-Variante zurückgegriffen. Was da genau schief geht, kann ich nicht noch nicht sagen.
Habe demnach als Quick-Workaround (okay, Hack ) ein "#undef" und anschließendes "#define REG..." eingebaut.

Zitat:

---

Hast Du geprüft, ob VBCC wirklich durch den __VBCC__ Block geht?

---

Zitat:

---

!__PPC__ kann nicht richtig sein. Wenn dann "&& defined(__M68k__)". Ich hätte jetzt allerdings auch erwartet, das __M68000 immer definiert ist, laut .pdf ist das aber anscheinend nicht der Fall, müßte man prüfen.

---

c code:

---

#if  (defined(__VBCC__) && !defined(__PPC__))
#undef REG
#define REG(reg,arg) __reg(#reg) arg
#endif

---

c code:

---

#if defined(_M68000) || defined(__M68000) || defined(__mc68000)

---

c code:

---

#if (defined(__VBCC__) && !defined(__PPC__)) || defined(_M68000) ||
    defined(__M68000) || defined(__mc68000)

---

Zitat:

---

Ich glaube die "Zufriedenheit" mit der API so wie sie ist kommt daher, dass kaum jemand noch versucht was ernsthaftes damit zu entwickeln.
Den Amiga Proggern geht es wohl eher darum, sich mit dem OS als Selbstzweck zu beschäftigen als mit einer echten, nützlichen Applikation, die entstehen soll.

---

Würdest Du nur mich ansprechen, würde ich Dir zustimmen. Da ich Programmieren nur als Hobby betreibe, kann daran auch keiner etwa aussetzen.
Ich verlange kein Geld für meine Programme, dementsprechend brauche ich auch keine Rücksicht auf Anwender zu nehmen. Ich entwickle hauptsächlich Werkzeuge, die für mich interessant sind.

Ich kann Dir aber auch versichern, dass es professionelle Programmierer gibt, die nach wie vor versuchen ihre zig Mega-Bytes umfassende kommerzielle Anwendung AmigaOS/MorphOS tauglich zu halten, und ich meine diesmal nicht Hollywood.
Zudem sind sie trotz der deiner Meinung nach "Unzulänglichkeiten der Amiga/MorphOS Betriebssystemen" imstande, ihre Programme AmigaOS/MorphOS kompatibel zu halten, teilweise aber mit Abstrichen. Ob es sich für sie rechnet, wird die Zukunft zeigen.

Zitat:

---

Es werden eher Mini-Projekte gemacht, die zum Experimentieren oder Lernen dienen, aber nicht als richtige Applikation released werden sollen, wo man auf Stabilität, GUI Richtlinien, Integration ins OS, Kompatibilität mit der Aussenwelt etc. wert legt.

---

Zitat:

---

Das Problem ist wohl eher dieses: Man sieht auf Linux ein Programm, versucht es zu portieren. Es ist posix, benutzt vll noch fork/vfork und schon fängt das erste Problem an: Kein posix, kein fork.

---

Solange es die POSIX-API benutzt kann man es portieren, auch wenn einige POSIX-Funktionen in der entsprechenden Amiga-Implementierung nicht vorhanden sind. Es bedeutet aber einen Mehraufwand, weil man die fehlenden Funktionen nachbilden muss.
Bei fork() sieht es ähnlich aus aber man kann es leider nicht wirklich benutzen, weil es keine Benutzerrechte unter AmigaOS gibt.
Demnach, da hast Du Recht, ist es fast aussichtlos ein Programm zu portieren, dass fork() benutzt.
Für MorphOS/AmigaOS4 bin ich mir nicht sicher, ob es nicht doch möglich ist solch eine Funktion nachzubilden, weil beide versuchen, mehr POSIX-Style (Linux) Programmierung zu erlauben, bzw. die Low-Level-Funktionen die als Basis dafür dienen, anzubieten.
Da müsste man sich an die jeweiligen Entwickler wenden. Ich bin da überfragt.


@Der_Wanderer:

Zitat:

---

Aber ich bin nun immerhin in der Lage, wenn du mir jetzt sagst: "Programmiere ein Tool, wo ich ein Bild reinladen kann, die Schärfe und Farbraum anpassen, resizen und als JPEG, PNG, BMP oder IFF abspeichern."
Dann kann ich das in 2-3h erledigen, und zwar so dass es unter OS3, OS4 und MOS funtkioniert.
Mit der AmigaOS API direkt brauche ich dafür 20-30h, oder vermutlich noch wesentlich mehr wenn man die Saver und DSP Algorithmen noch entwickeln muss, und dannach auch noch Beta Testen auf den verschiedenen Plattformen.

---

Zitat:

---

Das mag für C-Programmierer so sein, insbesondere, wenn die IDEs, die sie sich vorher angeschaut haben, tatsächlich nur umständlich zu bedienende makefile-Generatoren waren.
Wenn man erst mal mit anderen Programmiersprachen gearbeitet hat, kommt einem so etwas wie eine Rückkehr zur Steinzeit vor.

---

Die wirklich erste gute IDE, abgesehen von Devpac 3, die ich verwendet habe, war die, die dem MaxonC++-Compiler spendiert wurde. Ausgeklügelt angelegt, bunt ( ), übersichtlich, intuitiv zu bedienen.
Die VC++ IDE unter Windows ist bestimmt nicht schlecht - und trotzdem komme ich mir nicht vor als wäre ich wieder im Steinzeitalter gelandet nur weil ich handverfasste 'makefiles' benutze.
Zudem glaube ich nicht, aber ich kann mich täuschen, dass ein Projekt mittels einer IDE erstellt, so ohne weiteres auf andere Systeme übertragbar ist. Demnach, falls meine Aussage richtig ist, muss man sich ohnehin mit 'makefiles' beschäftigen, wenn man denn etwas von einer anderen Plattform portieren möchte bzw. auf eine andere portieren möchte, jedenfalls für C/C++.

Da die Programmiersprachen, die ich momentan benutze als ausreichend für meine Belange erscheinen, sehe ich auch nicht die Notwendigkeit, eine IDE zu erlernen.
C und C++ sind relativ weit *unten*, Java und Co relativ weit *oben*, demnach denke ich, dass man bei höheren Programmiersprachen mehr Wert auf eine IDE legt, abgesehen vom persönlichen Geschmack.
Es gibt nämlich auch Assembler-Programmierer, die eine IDE verwenden.

Zitat:

---

Mir persönlich bringt eine IDE auf dem Amiga (OS3) aber solange nichts, wie mir schneller als ich schauen kann das Betriebssystem unterm Hintern wegschmiert, und das nur bei kleinen Fehlern.

Zitat:

---

Ja, woran liegt das wohl...
Da spielt die Kombination aus Programmiersprache und API des Betriebssystems mit Sicherheit eine nicht zu unterschätzende Rolle.

---

---

Nee, für Fehler zeichne ich mich alleine verantwortlich.
Es gibt Tage, da programmiere ich ohne einen einzigen Fehler im Quellcode zu haben, abgesehen von kleinen Unzulänglichkeiten. Es gibt aber auch Tage, da mache ich dermaßen viele Fehler an einem einzigen Tag, dass ich manchmal an mir selber zweifle.

Zitat:

---

Und Du meinst "Linux" hat mehr Marketing betrieben als QNX?

---

Zitat:

---

Auch auf einer höheren Ebene bedeutet Programmieren, Zusammenhänge zu verstehen. Man hat allerdings die Gelegenheit, auch größere Zusammenhänge zu verstehen...

---

Zitat:

---

Natürlich ist es ein Ressourcen/Zeit Problem. Deshalb kann sich Linux auch leisten, grottige APIs anzubieten und irgendwer baut dann schon bessere High-Level APIs drumherum, gerne auch zwei, drei verschiedene Parteien gleichzeitig, so entstehen Gnome und KDE, WebOS und ChromeOS und trotzdem bleiben noch Ressourcen übrig, um darauf aufsetzend auch noch nutzbare Anwendungen zu stricken.

Der Amiga hat solche Ressourcen nicht, und genau deswegen ist es umso wichtiger, die Ressourcen nutzbringend einzusetzen und nicht dafür zu verpulvern, zum hundertsten Mal den gleichen Workaround um eine unzureichende Funktion zu bauen.

---

Zitat:

---

Eigentlich müssten sich alle verbleibenden Entwickler erstmal auf eine freie, offene high-level API für AmigaOS stürzen.

---

Wenn Du mehr als eine Personen in ein Boot steckst und keine klare Hierarchie besteht, wird nur Chaos dabei herauskommen.
Hat aber einer das letzte Wort, muss sichergestellt werden, dass diejenigen, die etwas ausarbeiten sollen, es auch tun, ohne wenn und aber. Üblicherweise spricht man dann von einem Angestelltenverhältnis.
Du weißt worauf ich hinaus will?

Habe ein wenig Geduld, irgendwann erfahren wir, ob MorphOS oder AmigaOS4 oder auch AROS das Zeug dazu haben, weiter zu bestehen. Für Dich, der etwas Kommerzielles vertreiben möchte, ist es bestimmt nicht der beste Rat, aber am Beispiel von Hollywood kann man erkennen, dass es jetzt auch schon möglich ist kommerzielle Wege zu beschreiten, allerdings dies mit Aufwand verbunden ist.
Ob Du dazu bereit bist, liegt einzig und alleine bei Dir.
Anbei, eine einheitliche API für die verschiedenen Systeme wird es meiner Meinung nach nie geben.


Grüße

Zitat:

---

Ähem.
So etwas passiert genau einmal nach dem Laden der Bibliothek, und ähnliches passiert auch beim Amiga, wenn nach dem Laden einer ausführbare Datei Adressen an die tatsächliche Position im Speicher angepasst werden.

---

Zitat:

---

Deshalb funktionieren DLLs selbst unter Windows 3.1 auf einem 386 mit 14MHz...

---

Jo, funktionieren tun auch Classic-Bibliotheken in Verbund mit einer 68000 mit nur 7 MHz recht gut, oder nicht?
Nee, Spaß beiseite, siehe Punkt 1 oben.

Zitat:

---

Wenn man bedenkt, dass der identische Library-Initialisierungscode, inkl. der Verwaltung des Zählers für Anzahl benutzender Programme sich in jeder Bibliothek erneut wiederfinden, statt einmal im Betriebssystem, relativiert sich diese Effizienz erheblich.

---

Da verwechselst Du was. Jede Bibliothek kann einen ganz anderen Initialisierungscode haben; Sprungtabellen können anhand von 32-Bit absoluten Adressen generiert werden (in C macht man das üblicherweise so), für Bibliotheken die ich in Assembler erstellt habe, benutzte ich aber 16-Bit Offsets relativ zur Funktion; zudem kann man im Initialisierungscode reinschreiben was man will, wie will da das Betriebssystem wissen, was es machen soll?
Selbst Open(), Expunge() und Close() sind immer für die betreffende Bibliothek maßgeschneidert.
Das Classic Bibliotheken nicht der Weisheit letzter Schluss sind, weiß ich auch. Nur, ich persönlich finde das Konzept schon ganz passabel. Okay, nicht für PPC und/oder andere Prozessoren, dafür ist es zu maßgeschneidert.
Zudem, wie ich oben schon einmal geschrieben habe, macht das Betriebssystem nichts mehr nachdem die Bibliothek einmal erstellt wurde; eine Bibliothek ist dann nur noch ein Haufen Code der irgendwo im Speicher schlummert und darauf wartet, dass irgendein Anwenderprogramm diesen Haufen Code ausführt. Nix mit Verwaltung seitens des OS.

Zitat:

---

Die Design-Entscheidung, keine symbolischen Namen, sondern eine Tabelle mit 68k-Sprungbefehlen relativ zum Register A6 zu benutzen, die selbst unter der bevorzugten Programmiersprache C ein Fremdkörper ist, muss man akzeptieren. Aber nicht unbedingt glorifizieren.

---

Ich glorifiziere rein gar nichts. Habe ich nicht gemacht und werde es auch nicht machen.
In Zeiten als Assembler noch richtig populär war und CPUs gerade dabei waren in den einstelligen MHz-Bereich vorzudringen, war dieses Konzept aber sehr effizient - und das von beiden Seiten betrachtet, CPU und Assembler-Programmierer.

Zitat:

---

Diese Art des Linkens ist aber auch gar nicht der Grund, warum man Amiga-Libraries nicht so wie Windows oder Unix-Libraries benutzen kann. Der springende Punkt ist hier, dass man nicht die Datensegmente einer Objektdatei automatisch pro Prozess anlegen lassen kann.

---

Stimmt.
Allerdings sollten Amiga Bibliotheken nicht nur thread-safe sein, sondern reentrant, dass heißt dann, dass keine modifizierbaren Daten den Funktionsaufruf überleben. Demnach braucht man auch keinen geklonten Datenbereich.


@Der_Wanderer:

Zitat:

---

Das Argument mit der Effizienz kann ich auch nicht gelten lassen.
Wie Holger gesagt hat, die Klartext Funktionen müssen nur einmal beim Programm start in Jump Offsets aufgelöst werden. Das ist selbst auf einem A500 ein vertretbarer und kaum spürbarer Aufwand.

---

Zitat:

---

Wenn ich das richtig sehe ist der große Unterschied, dass DLLs jedesmal beim öffnen ihren eigenen Kontext erzeugen, während Amiga Shared Libraries nur einmal gestartet werden, und dann von mehreren Prozessen verwendet werden können.

---

Wir driften immer weiter in Richtung pro und kontra DLL, bzw. pro und kontra Classic Amiga Library ab.

Wenn Du mal Zeit hast, dann besuche die Microsoft Entwickler-Seite und lese Dir mal die Low-Level-API Funktionen durch oder programmiere unter Windows mal ohne vorgefertigte WINAPI, dann verstehst Du auch meinen Standpunkt.

Können wir dem Ganzen ein Ende setzen und sagen, dass Holger und Du nichts gegen Sprungadressenermittlung anhand von Bezeichnern habt, wogegen ich statische Offsets fest verankert im Programm favorisiere?


Frieden?

Zitat:

---

Intern verwende ich hier und da Floats, z.b. um ein Hamming Fenster zu berechnen etc.

Verstehe ich aber nicht ganz, in Amiblitz kann ich doch auch Floats in Shared Libs benutzen.

---

Du kannst sie auch innerhalb einer in C erstellten Bibliothek verwenden, leider aber nicht die Versionen, die in der statischen Compiler (Runtime) Biblitohek zu finden sind, denn, wir näheren uns wieder dem Anfang dieses Threads, unter OS3 sind diese nicht thread-safe und zum Anderen setzen sie Teile des Startup-Codes als gegeben voraus.

Ich bin ein wenig überfragt, wie Amibltiz Fließkommazahlen handhabt und ob mittels Amiblitz erstellte Funktionsbibliotheken wirklich reentrant sind. Unter C jedoch gibt es diverse Referenzen zu Funktionen, die zwar alle dasselbe tun, z.B. dividieren, aber unterschiedliche Bezeichner haben, weil es neben FLOAT und DOUBLE noch die internen Formate der 68881/68882/68040/68060 FPUs gibt, die auch unterstützt werden.
Diese Funktionsnamen sind in den betreffenden Compilern fest verankert, z.B. __muldf3(), __fixsfsi(), __floatsisf(), __divsf3(), um nur einige unter "gcc" zu nennen. Und diese müssen zwingend reentrant für eine Amiga Shared-Library sein, ansonsten musst Du nämlich jede Funktion, die eine dieser Routinen benutzt, solange sperren, bis die betreffende Routine wieder frei zur Verfügung steht. Wohl kaum durchführbar.

So, nachdem ich mir jetzt mal kurz das 'Change.log' zu "clib2" angeschaut habe, gehe ich davon aus, dass alle Funktionen die Du benötigst, darin enthalten sind, auch die Compiler-spezifischen für FLOAT und DOUBLE.

Damit kannst Du schon mal OS3 und OS4 abdecken.
Unter MorphOS ist "libnix" das Äquivalent.
Macht schon mal drei von vier.
Ich hoffe, dass unter AROS die zur Verfügung stehenden "Static Libs" thread-safe sind, dann hättest Du nämlich alle vier abgedeckt.


Grüße

Zitat:

---

Es geht um Sprachsynthese, wo es gemeinsame Resourcen gibt, z.B. die Lexica und die Stimmen.

---

Benötigst Du dazu die mathematischen Bibliotheken? - sprich Fließkommazahlen? Dann rennst Du nämlich ins nächste Problem.
Schon Anweisungen wie:
z = i + 1.5;
oder
i = z / 2.0;
benutzten auf dem Amiga Compiler-spezifische Routinen, die ausschließlich in der jeweiligen C-Runtime Bibliothek zu finden sind.

Erschwerend kommt hinzu, aber eher von theoretischer Natur, wenn ich das noch recht in Erinnerung habe, dass man jedwede zu benutzende mathematische Bibliothek von dem Prozess, der sie verwendet, auch öffnen lassen muss, und nicht nur einmal, wie sonst üblich. Der Grund liegt darin begründet, dass eine Ressource (ausschließlich ein Benutzer für die Nutzungsdauer gestattet) anstelle einer Software bzw. einer Software-Hardware-Lösung verwendet werden könnte und diese per Definition ausschließlich von dem Prozess, der sie öffnete, auch geschlossen werden darf.


@whose:

"Winzigweich"?

Habe den Ausdruck noch nicht vernommen.

Zitat:

---

Ja, aber es luppt auch nur deswegen als DLL, weil man bei Winzigweich entsprechend Aufwand mit dem OS getrieben hat. Normalerweise würde das genauso wenig luppen.

---

Ja, da hast Du Recht.
Allerdings kommt so etwas als zentrale Schnittstelle für ein schlankes, halbwegs effizientes Betriebssystem nicht infrage, weil:
a) zur Laufzeit externe Verweise aufgelöst werden müssen
b) zur Laufzeit die Sprungadressen ermittelt werden müssen
c) die Sprungadressen anhand des Namens ermittelt werden
d) ein zentraler Prozess die Nutzung dieser dynamischen Bibliotheken gewährleisten muss

In Zeiten von C#/Java und zig Giga-Hertz spielt das für Endanwender aber keine Rolle mehr, weil man es nicht wahrnimmt, bzw. die Geschwindigkeit als ausreichend erachtet.
Das gleiche für OS3, selbst mit einer 100 MHz 68060 CPU, würde abschreckend wirken.

Ich gebe zu, dass eine Amiga-Shared Bibliothek um ein vielfaches schwieriger zu erstellen ist als eine '.dll', jedoch ist ihre Verwaltung aus Sicht einer CPU effektiver.
Zudem hat Microsoft den Sprach-Standard von C um "__declspec" erweitert, damit es dem Programmierer leichter gemacht wird, eine '.dll' zu erstellen. So was müsste es für AmigaOS/AROS/MorphOS geben...

Zitat:

---

Ok, manchmal übernehmen die Entwickler des Betriebssystems den Aufwand für Dich und basteln, naja, interessante, Lösungen dazu, aber für AOS 68k fällt das auf alle Fälle flach, da passiert in dieser Richtung wohl eher nichts mehr.

---

Zitat:

---

Das lädt nicht gerade zum Entwickeln für den Amiga ein. Ich verstehe eigentlich gar nicht warum, steckt doch hinter einem fopen() letztendlich ein Open() der dos.library, was re-entrant ist. Irgendwo beim "einpacken" hat da doch jemand Bockmist gebaut.

---

Ich entwickle meine Programme lieber auf dem Amiga als unter Windows/Linux, weil ich hier hundertprozentig weiß, welche Betriebssystem-Funktionen meine Programme benutzen. Schon die Benutzung der clib- oder der POSIX-API verschleiern, welche Funktionen man tatsächlich verwendet. Beispiel gefällig?

fopen() in Verbindung mit fread() wird je nach Implementierung und des Quellmediums (Floppy-Disk, Hard-Disk etc.) andere Puffer-Größen verwenden. Z.B. wird anhand des Struktureintrages "Bester Datentransfer" ("<sys/stat.h>") ein Puffer verwendet, der irgendwo im Bereich von 512 Bytes bis zu mehreren Kbytes angesiedelt ist, demnach wird fread()/fwrite() nicht exakt die Anzahl der Daten einlesen/schreiben, die Du angibst, sondern dies alles über einen Puffer im RAM bewerkstelligen, der ohne Dein Zutun alloziiert wurde. Erst wenn Du explizit diesen Puffer (Cache) leerst oder fclose() aufrufst oder auch Dein Programm beendest, werden Daten geschrieben. Beim Lesen ist es wiederum anders. Du kannst sagen ich lese Byte für Byte, intern wird aber ein Puffer verwendet, der Dateien blockweise liest, also zum Beispiel 64 Kbytes auf einmal. Liest Du das nächste Byte, wird keine Lesevorgang ausgeführt, sondern nur der Pufferzähler um ein höher gesetzt (fseek()) und Dir das nächste Byte, das sich im RAM (Cache) befindet, retourniert.
Jetzt hast Du auch den Grund, warum das nicht von Anfang an thread-safe programmiert wurde. Es wurden nämlich Variabeln auf Dateiebene angelegt. Erst als man begann, den FILE-Record (FILE-Descriptor) so zu erweitern, dass diese Puffer/Zähler Teile des FILE-Records wurden, ging man den thread-safe Weg (blödes Wort, aber mir fällt nichts Besseres ein, sorry).
Damit bleibt aber noch immer ein Problem bestehen. Beim Beenden eines Programmes müssen noch alle geöffneten Dateien geschlossen werden sowie alle verwendeten Speicherbereiche dem Betriebssystem zurückgegeben werden. Wie macht man das, wenn man alles im FILE-Record platziert hat, der FILE-Record aber nur dem Anwenderprogramm bekannt ist? Lösung, man erstellt eine Liste mit allen FILE-Records ohne Zutun des Anwenderprogrammes, ergo beim Aufruf von fopen()! Und wo bewahrt man den Zeiger auf diese Liste auf Dateiebene auf? Im Startup-Code! Was macht der Startup-Code wenn dessen Exit-Routine aufgerufen wird? Es testet die Liste; ist ein Eintrag nicht null, wird automatisch flcose() ohne Dein Zutun aufgerufen und damit der Pufferinhalt geleert (flush), die Datei geschlossen und die Speicherbereiche dem Betriebssystem als unbelegt zurückgemeldet!

Ja, ich gebe Dir Recht, der Verzicht auf clib- oder POSIX-Funktionen beim Programmieren unter AmigaDOS (speziell 3.x) bedeutet im Umkehrschluss sehr viel mehr Arbeit, macht mich aber unabhängig von irgendwelchen Implementierungen. Zudem spielt Zeit keine Rolle für mich; bin halt ein Hobby-Programmierer.

Auch solltest Du niemals außer Acht lassen, dass man unsichere Teile immer thread-safe gestalten kann, indem man *nur* die Library-Base klont, also negativ- sowie positiv-Offsets (OS3/AROS/MorphOS, OS4 ist ein wenig *anders*), und jedem Endanwender eine eigene Library-Base zuweist. Dementsprechend braucht man nicht Hand an die Funktionen selber zu legen, sondern nur die Sprungtabelle inklusive des Library-Records für jede Instanz zu reproduzieren (kopieren). Ist allerdings nicht der sauberste Stil, weil eine Shared-Bibliothek im Grunde genommen reentrant sein sollte und nicht nur thread-safe.


Als Ergänzung zu whose Worten kann ich Dir nur ans Herz legen, Weaver (amimedic.de) herunter zu laden.
Es ist ein Programm, das Dir anhand von SFD-Dateien die Grundgerüste für Shared-Libraries erzeugt, und zwar für OS3/AROS/MorphOS und OS4.
Alles was Du dazu brauchst ist dann ein Texteditor, einen C-Compiler, Weaver und fd2pragma und Du erstellst für alle vier Plattformen die benötigten Dateien, inklusiver derer für die Endbenutzer. Nach wie vor musst Du aber erst einmal Deine Funktionen so schreiben, dass diese auch mindestens thread-safe sind, besser wäre aber reentrant. Kriegst Du das nicht hin, klone wie oben beschrieben die Library-Base für jedes aufrufende Programm und dann sollte auch einer Amiga-Implementierung nichts im Wege stehen.
Willst Du weiterhin C++ benutzen, bleibt Dir sowieso nichts anderes übrig, es sei denn, Du kannst exakt bestimmen, ob der vom C++-Compiler generierte Code thread-safe ist.

Mein Fazit:
Wenn man denkt es geht nicht mehr, kommt von irgendwo ein Lichtlein her.
Oder anders gesagt, ich hoffe, dass Du jetzt nicht mehr ganz so schwarz siehst.


Grüße

Zitat:

---

Hm, das wird komplizierter als ich dachte. Soll ich nun doch besser C nehmen?

---

Zitat:

---

Also wenn ich mich zusammenreise, dann komme ich mit

fopen()
fread()
fwrite()
fseek()
ftell()
fclose()
malloc()
free()

aus. Wobei Konsole Output schon hilfreich wäre, also printf().

---

Vergesse printf() ganz, ganz schnell. Ich weiß nicht warum so viele Programmierer printf() innerhalb einer Shared-Lib verwenden möchten.
1) printf() ist nicht thread-safe; es arbeitet intern mit Puffern und Variablen auf Dateiebene (global).
2) das AmigaDOS erlaubt es nicht, dass Prozesse File-Handles untereinander austauschen; jeder Prozess ist angehalten, die File-Handles per Instanz zu reservieren und wieder freizugeben.
3) printf() setzt zwingend einen Startup-Code voraus; dieser entfällt beim Schreiben einer Amiga-Shared-Lib.
4) printf() ist eine C-Funktion, unter C++ ist das Äquivalent 'cout'. (SCNR )

Wenn Du die Ausgaben nur zur Fehlersuche benötigst, verwende kprintf() (OS3, MorphOS, AROS) oder DebugPrintF() (OS4) und starte vorab Sushi oder Sashimi.

Zitat:

---

Alles andere ist rein algorithmisch und kann re-entrant oder zumindest thread-safe implementiert werden.
Wenn das nicht geht, wird es schwierig.

---

Zitat:

---

Wenn ich für diese Funktionen AmigaOS API nehmen würde, dann sollte es doch eigentlich funktionieren, oder nicht?

---

Zitat:

---

Was hat man denn in der C Runtime "verbrochen", dass es nicht mehr thread-safe ist?
Bei printf() kann ich das noch verstehen, denn da müsste man sich erst den Handle auf den stdout holen. Aber die anderen Sachen sollten doch funktionieren, oder übersehe ich da etwas?

---

Zitat:

---

Es ist stark abhängig von diesen pragmas/clib/inlines und der Link-Libs ob die printf, fopen etc richtig funktionieren.

---

Zitat:

---

Also, darf ich nun "sprintf" oder "fopen" in einer Shared Lib benutzen oder nicht?
Sieht so aus, als bräuchte ich dafür eine spezielle Runtime Linkerlib.

---

Zitat:

---

Nachtrag:
Unter Windows und Linux scheint das kein Problem zu sein. Haben dort die DLLs/SOs für jede offene Instanz eigene Addressräume, und die Funktionen müssen deshalb nicht thread-safe sein? Oder ist die Amiga Implementation der C-Runtime einfach crappy?

---

Zitat:

---

Die ursprüngliche Routine habe ich durchaus verstanden. Allerdings werden dort nirgendwo Divisionen eingespart. Divisionen einzusparen wurde erst von Dir vorgeschlagen.

---

code:

---

.2	addq.w	#1,d4
	sub.w	d3,d0
	bpl.s	.2
	add.w	d3,d0
	divu.w	#10,d3
	add.w	#$30,d4

---

code:

---

.2	divu.w	d3,d0	; d3 = 10000, 1000, 100, 10, 1
	move.w	d0,d4	; Wert retten (Quotient)
	clr.w	d0	; Untere 16 Bits löschen (keine Hausnummern)
	swap	d0	; Restwert (Remainder) in untere 16 Bits
	divu.w	#10,d3	; 10000 zu 1000 usw.
	add.w	#$30,d4	; ASCII

---

code:

---

Timing Beispiel für 68000er Code unter Verwendung einer 68060
CPU:
.2	addq.w	#1,d4	; 1 Taktzyklus
	sub.w	d3,d0	; 1 Taktzyklus
	bpl.s	.2	; 7, 1 oder 0 Taktzyklen
			-----
			Variiert von 2 bis 9 Taktzyklen je Durchgang

Unter Umständen benötigen die 3 Instruktionen pro Durchgang nur
einen einzigen Taktzyklus. Das lassen wir mal außen vor.
					
Nehmen wir an dass die Branch-Vorhersage beim ersten Mal versagt
(7 Taktzyklen), ab dem zweiten Durchlauf klappt (0 Taktzyklen)
und beim letzten Durchlauf einen einzigen Taktzyklus benötigt so
ergibt sich folgender Wert für die ASCII-Ziffer 9:

1.  Durchgang  9
2.  Durchgang  2
3.  Durchgang  2
4.  Durchgang  2
5.  Durchgang  2
6.  Durchgang  2
7.  Durchgang  2
8.  Durchgang  2
9.  Durchgang  2
10. Durchgang  3
              ---
	      28 Taktzyklen

Für die ASCII-Ziffer 0 wird aber nur einen Durchgang benötigt,
also 9 Taktzyklen.

Demnach variieren die Ausführungszeiten stark je nach der Zahl,
die in D0 übergeben wird.
Der schlechteste Fall wäre 99999, d.h. 140 Taktzyklen, der beste
Fall wäre 0 mit 45 Taktzyklen.

Unter Verwendung der Division sieht dies wie folgt für eine
68060 CPU aus:
.2	divu.w	d3,d0	; 22 Taktzyklen
	clr.w	d0	; 1 Taktzyklus
	swap	d0	; 1 Taktzyklus
			-----
			24 Taktzyklen

Demnach sind es immer 120 Taktzyklen, egal welcher Wert in D0
steht.

Anbei, bei Verwendung einer Langwort-Division
divul.l dx,dx:dx  (44 Taktzyklen/68060)
liegt der Vorteil klar auf Seiten der Subtraktionsmethode.

---

Zitat:

---

Die Lösung, die Du gepostet hast, ist durchaus sinnvoll, wenn es darum geht, auf einem 68000, also nicht 68020+, eine 32 Bit Zahl zu formatieren.

---

Zitat:

---

Parat haben und jemandem vorkauen, der alle paar Tage mit einer neuen Frage dieser Art kommt, sind zwei verschiedene paar Schuhe.

---

Zitat:

---

jolo hat offensichtlich den ursprünglichen geposteten Code mit einem bestimmten Code für die spezielle Anforderung 32 Bit-Zahlen auf 68000 zu formatieren verglichen und ist zu dem (durchaus richtigen) Schluss gekommen, dass ihm nur geringfügige Teile dazu fehlen, und dabei übersehen, dass diese Anforderung weder genannt, noch von dem ursprünglichen Code erfüllt wurde.

---

Zitat:

---

...auf langwortgröße sollte es schon funtionieren. wer weis wie?

---

Zitat:

---

aber jetzt benutze ich wiederum die funktion von jolo! (und habe ihn in meinem readme creditiert)

---

Zitat:

---

Also zuerst mal, ich finde den Thread hier äußerst lehrreich... ich stelle fest, daß ich in der langen Zeit, in der ich auf die "weit größeren Fähigkeiten eines Compilers in Sachen Optimierung" vertraut habe, eine Menge verlernt habe

---

Zitat:

---

Oder einfach nur dämlich ausgedrückt, also Du von den Werten "von 1000000000 bis 1" gesprochen hast.

---

Zitat:

---

Ich bin kein Profi, nur ein Einäugiger unter Blinden.

Zitat:

---

Nur äußerst eingebildet, würde es offensichtlich besser treffen.

---

---

Zitat:

---

[...] können Dir nicht nur Einäugige helfen.

---

Zitat:

---

Den habe ich ja ganz übersehen. Klasse Vorschlag, Division durch eine Tabelle mit einer Milliarde Einträgen zu "optimieren". Dass es dann auch auf einem 68000 läuft, ist angesichts des Speicherbedarfs von schlappen 4GB natürlich sehr nützlich...

---

code:

---

ValToDez:
	movem.l	d2-d4/a1-a2,-(a7)
	push	a0		; Pufferstart merken
	moveq	#10-1,d1	; 10 Stellen (wg. dbf -1)
	lea	divtable(pc),a2	; Divisionstabelle
	move.l	(a2)+,d3	; = 1000000000 f. ersten Durchlauf
	moveq	#0,d2		; Flagge für führende Nullen
.lp1	moveq	#-1,d4		; Zähler für Subtraktionen ohne Überlauf
.2	addq.w	#1,d4		; plus 1 = im Bereich von 0 bis 9
	sub.l	d3,d0		; Subtraktion
	bpl.s	.2		; Solange kein Überlauf (bcc.s)
	add.l	d3,d0		; Negativen (Überlauf!) Wert korrigieren
	move.l	(a2)+,d3	; Neuen Wert aus Tabelle, entspricht d3 / 10
	add.w	#$30,d4		; Nach ASCII wandeln
	tst.w	d2		; Schon Ziffern in Puffer abgelegt?
	bne.b	.4		; Falls ja, auch Nullziffer ablegen
	cmp.b	#"0",d4		; Ist es eine Nullziffer?
	beq.b	.5		; Falls ja, führende Null nicht ablegen
	st	d2		; Sonst Flagge setzen
.4	move.b	d4,(a0)+	; Ziffer ablegen
.5	dbf	d1,.lp1		; Anzahl Stellen
	cmp.l	(a7)+,a0	; Pufferadresse = initiale Adresse?
	bne.b	.pop		; Wenn nicht,
	move.b	#"0",(a0)+	; sonst Nullziffer ablegen (d0 war 0)
.pop
	clr.b	(a0)		; String Terminierung (Puffer muss 11
				; Bytes groß sein)
	movem.l	(a7)+,d2-d4/a1-a2
	rts

divtable
	dc.l	1000000000
	dc.l	100000000
	dc.l	10000000
	dc.l	1000000
	dc.l	100000
	dc.l	10000
	dc.l	1000
	dc.l	100
	dc.l	10
	dc.l	1

---

Zitat:

---

ah, da sind die profis. geht doch! :-)

---