Inline-Assembler

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

  • Hallo Roland,
    Falls es noch ein Update / Subscription geben wird, hätte ich noch
    ein Vorschlag :
    Bei Set("AsmMode", 1) hätte ich gerne einen Ordner mit angegeben,
    um etwas Ordnung reinzubringen. Wäre es möglich, ähnlich wie bei

    Code
    Set("SQLFile", S)
    Set("LogFile",S)


    auch hier eine Datei ggf. mit Pfad festzulegen. Oder daß S nur ein Pfad ist.


    Code
    Set("AsmFile", S)

    Damit könnte man seine gesammelten Werke besser verwalten.

  • Gute Idee! Und ist bei mir schon eingebaut. Wenn man einen Leerstring übergibt oder ASMFile gar nicht erst setzt, bleibt es wie gehabt, ansonsten wird die in S angegebene Datei benutzt.


    Gruß
    Roland

    (Intel Duo E8400 3,0 GHz / 4 GB RAM / 250 GB HDD / ATI Radeon HD4770 512 MB / Windows Vista - ausgemustert zum Verkauf)
    AMD Athlon II X2 2,9 GHz / 8 GB RAM / 500 + 1000 GB HDD / ATI Radeon 3000 (onboard) / Windows 10(64) - XProfan X4


    http://www.xprofan.de

  • Wenn man einen Leerstring übergibt oder ASMFile gar nicht erst setzt, bleibt es wie gehabt, ansonsten wird die in S angegebene Datei benutzt.

    Ist sogar noch besser.
    Da kann man, sofern man will, alles in einer einzigen Datei organisieren.
    Die darf natürlich nicht überschrieben werden. Andernfalls nutzt man
    eben eine neue Datei.


    Wenn dann mehrere Listings in einer Datei sind, wäre zu beachten, wie man die
    Opcodes am besten wieder rausliest. Am besten wäre da der Funktionsname mit
    Doppelpunkt. Etwa so :


    Auch ein AsmMode 3 wäre interessant. Damit könnte die Zwischenablage
    bedient werden. Im Moment mache ich das so :


    Das ist dann schon schön aufbereitet und man braucht die Anzahl Bytes nicht mehr
    zu bestimmen. Ideal zum schnellen Testen.

  • Angeblich gibt es jetzt Compiler für FreePascal auf ARM-Prozessoren.
    Könnte es bald auch ein XProfan am Android-Smartphone geben?

    HP255G7:Win10pro2.004,4*AMD Ryzen3200U@2.60GHz,6+2GB-RadeonVega/237GBSSD:intlDVDRW,3xUSB3 ext4TB-HDX,XProfanX3+Xasm/Xpse

  • Danke für das interessante Link: Hui, schon die Installation sieht kompliziert aus.
    Ich meinte eher, daß RGH den selben Sourcecode verwenden kann, das wäre dann für 32bit, 64bit und eben Android - also möglichst wenig Gesamtaufwand hat. Aber OK, die Tücke steckt da sicher im Detail...
    Gruss


    P.S.: Warum Infinity aufgegeben wurde, hatte offenbar auch Lizenzprobleme. Die Politik von Google ist aus Gründen der Phone-Sicherheit sehr restriktiv. Infinity dürfte einen Jailbreak benutzt haben, was gem. Richtlinien verboten ist. Leider gibt es trotzdem inzwischen Handy-Viren.

    HP255G7:Win10pro2.004,4*AMD Ryzen3200U@2.60GHz,6+2GB-RadeonVega/237GBSSD:intlDVDRW,3xUSB3 ext4TB-HDX,XProfanX3+Xasm/Xpse

  • Kommt auch darauf an, wie die Sache angegangen wird.
    B4A setzt auf JAVA und das ANDROID SDK, während das
    SpiderBasic von PureBasic die CORDOVA - Bibliothek als
    Untersatz benutzt.


    Man sieht, bei SpiderBasic geht es auch nicht so richtig voran.
    Da scheint es auch irgendwie Probleme zu geben. Ist aber auch
    nur ein Nebenbei - Projekt von Fred.


    Am besten finde ich noch B4A, da hier die aktuellen Bibliotheken
    des Android SDK berücksichtigt bzw. genutzt werden. Ist zwar
    erst etwas Arbeit, das JAVA SDK und ANDROID-SDK zu installieren,
    aber wenn es erstmal drauf ist, läuft es auch.
    Und es erzeugt echte .APK's und nicht so ein Zeug, das nur im
    Browser läuft. Dafür gibt es dann wieder B4J.

  • Gute Idee! Und ist bei mir schon eingebaut. Wenn man einen Leerstring übergibt oder ASMFile gar nicht erst setzt, bleibt es wie gehabt, ansonsten wird die in S angegebene Datei benutzt.

    Wenn man die Opcodes in der Zwischenablage (Clipboard) hätte,
    wäre auch noch eine gute Option.

  • Hmmm... ich dachte, wenn man nach ausgiebigem Testen von XProfan-Programmen die Fehlerprüfungen mit set("Errorlevel",-1) weglässt ("Fast schon kriminell"-Anmerkung in der Hilfe), dann müsste doch auch das Compilat schneller werden. Tut es aber nicht. Gibt es da nicht Beschleunigungsmöglichkeiten, etwa durch einen Errorlevel -2 ("Voll kriminell")?

    HP255G7:Win10pro2.004,4*AMD Ryzen3200U@2.60GHz,6+2GB-RadeonVega/237GBSSD:intlDVDRW,3xUSB3 ext4TB-HDX,XProfanX3+Xasm/Xpse


  • Und was ist mit Errorlevel 0 ?
    Ist ja auch eigentlich dafür gedacht.


    Evtl. ist ja auch über
    Set("FastMode", 1)
    was zu erreichen. Vorausgesetzt, das erweiterte Messagehandling wird nicht unbedingt gebraucht.

  • Gerade getestet: Im Falle von Programmen mit Formeln als Schwerpunkt bringt "Fastmode" keine merklichen Vorteile, bei Print- oder Datei-lastigen Programmen ebenfalls nicht. Leider...

    HP255G7:Win10pro2.004,4*AMD Ryzen3200U@2.60GHz,6+2GB-RadeonVega/237GBSSD:intlDVDRW,3xUSB3 ext4TB-HDX,XProfanX3+Xasm/Xpse

  • Das sind eben die kleinen Nachteile von Programmen, die mit einem
    Runtime-Modul laufen. Auf der anderen Seite hat man eben den vollen
    Rucksack immer dabei und muß sich nicht ums Importieren von Libraries
    kümmern. Ich meine jetzt keine DLL's.


    Denke mal an früher mit VB und die VBRun300. Die mußte man sogar immer
    dazu geben, falls die der Benutzer nicht hatte.

  • Pascal und Delphi schreiben bekanntlich P-Code. Von P-Code kann man theoretisch in verschiedenste Zielplattformen compilieren. Wie ist das eigentlich bei XProfan?

    HP255G7:Win10pro2.004,4*AMD Ryzen3200U@2.60GHz,6+2GB-RadeonVega/237GBSSD:intlDVDRW,3xUSB3 ext4TB-HDX,XProfanX3+Xasm/Xpse

  • Pascal machte das in der Windows-Variante ja auch ... , eben vom P-Code ausgehend. Viele Betriebssysteme haben aber funktionsähnliche Module wie das Application programming interface, bei Win-64 heissen die dann ABI etc. - und bei einem Profan64 scheint das schon gelungen zu sein ...

    HP255G7:Win10pro2.004,4*AMD Ryzen3200U@2.60GHz,6+2GB-RadeonVega/237GBSSD:intlDVDRW,3xUSB3 ext4TB-HDX,XProfanX3+Xasm/Xpse

  • Pascal und Delphi schreiben bekanntlich P-Code. Von P-Code kann man theoretisch in verschiedenste Zielplattformen compilieren. Wie ist das eigentlich bei XProfan?

    Bei Win32 und Win64 geht das ja noch einigermaßen gut, da ja dort nur die
    64Bit beachtet werden müssen. Bei der API gibt es ja passend Pendants dazu.


    Anders sieht es dann bei Linux, MAC und Android aus. Da müssen dann auch
    z.B. Root - Rechte usw. und bei MAC die DevelopperLizenz zusätzlich beachtet
    werden. Da kommt schon einiges zusammen, was dann doch anders ist, als bei
    den Windows - Betriebssystemen.


    Das wärs auch schon bei den häufig verwendeten Betriebssystemen. Nicht umsonst wird
    bei Android ein Unterbau von JAVA gerne benutzt, da dies a) weitverbreitet und ausgebaut
    ist und b) dann auch auf den gängigen Versionen läuft.
    Das ist genauso, wie die .PDF Dateien, die von den 3 BS gelesen werden können.

  • XProfan erzeugt in der Tat bekannterweise einen Zwischencode (oder auch PCode), der von der Runtime ausgeführt wird.


    Tatsächlich gab es einmal den Gedanken, Profan für verschiedene Plattformen zu entwickeln. Es gab ja auch eine Version für DOS, eine für OS/2 und eine für LINUX ohne grafische Oberfläche. Hier konnte derselbe Code von den unterschiedlichen Interpretern bzw. Runtimes ausgeführt werden. Da das Interesse aber "sehr überschaubar" war, sind diese Versuche sehr rasch wieder in der Versenkung verschwunden. Lang, lang ist es her ...


    Bei FreeProfan kann ein Compilat sowohl zur 32-. als auch zur 64-Bit-Runtime gelinkt werden.


    Ein "Nachbau" der Windows-API für Linux, um eine Linux-Version mit grafischere Oberfläche zu erstellen, wäre viel zu aufwendig. Da ist es doch einfacher. die Windowsversion unter WINE zu benutzen.


    Gruß
    Roland

    (Intel Duo E8400 3,0 GHz / 4 GB RAM / 250 GB HDD / ATI Radeon HD4770 512 MB / Windows Vista - ausgemustert zum Verkauf)
    AMD Athlon II X2 2,9 GHz / 8 GB RAM / 500 + 1000 GB HDD / ATI Radeon 3000 (onboard) / Windows 10(64) - XProfan X4


    http://www.xprofan.de

  • So ein Gedanke hatte ich schon vor ein paar Jahren geäußert :
    Daß man den Interpreter und die Runtime nur mit dem Wesentlichen
    (Kontrollstrukturen, usw.) bestückt.
    Alles andere, auch das Neue, was hinzu kommt, könnte in sogen.
    Libraries (ähnlich $L und $U) Platz finden. Der Interpreter bzw. Compiler/
    Interpreter sucht sich im Ordner die Lib raus und startet/ compiliert
    das Programm. Damit der Compiler/Interpreter die Funktionen besser
    findet, könnte man ja auch Headerdateien, die die Funktionen im Klartext
    nochmals speichern, anlegen.
    Vielleicht, daß ein paar Grundlibrarys standarmäßig eingebunden werden,
    um z.B. ein Fenster (CLS), ein Print und Waitkey/Waitinput zu gwährleisten.


    Damit wären die Programme noch schlanker. Auch die Schnelligkeit müßte
    dann noch etwas höher sein, da das gesamte 'Paket' nicht im Speicher
    gehalten werden muß.


    Auch die Wartbarkeit für Roland wäre besser, besonders was Fehler usw. anbetrifft.
    z.b. ist der Fehler im Interpreter behoben, aber in der Runtime schlichtweg vergessen
    worden. Ist ja auch schon ein paarmal vorgekommen. Aber niemand ist ja unfehlbar.


    Wer sich dafür interessiert, sollte sich mal B4J unter
    http://WWW.B4X.COM
    ansehen. Das gefällt mir auch sehr gut, wo man die LIBS einfach anhaken kann,
    und somit die Funktionen darin verfügbar sind. Auch in der IDE wird dann die
    Syntax der einzelnen Funktionen angezeigt.


    Es gibt auch andere Sprachen, die das so ähnlich mit dem Einbinden handhaben.

  • Ein solch pures Profan ohne die ganzen Grafik- und Windows-Sachen hatte ich ja auch mal unter dem Namen PurProfan hergestellt. Durch Einbinden der Windows.ph konnte man damit auch grafische Windows-Programme erstellen. Aber leider ging auch hier das Interesse gegen Null, so dass das Projekt nicht weiter verfolgt wurde.


    Gruß
    Roland

    (Intel Duo E8400 3,0 GHz / 4 GB RAM / 250 GB HDD / ATI Radeon HD4770 512 MB / Windows Vista - ausgemustert zum Verkauf)
    AMD Athlon II X2 2,9 GHz / 8 GB RAM / 500 + 1000 GB HDD / ATI Radeon 3000 (onboard) / Windows 10(64) - XProfan X4


    http://www.xprofan.de

  • Bei so anfängerfreundlich fehlergesicherten Systemen ist klar, daß sie nicht die allerschnellsten sein können. Programmieren hat ja auch etwas mit dem Finden guter, flotter Algorithmen zu tun. Wäre ein separater Runtime-Teil, der auf sämtlichen Ballast verzichtet, im Prinzip machbar? (Natürlich müssten Fenster, Buttons und Menüs bleiben)

    HP255G7:Win10pro2.004,4*AMD Ryzen3200U@2.60GHz,6+2GB-RadeonVega/237GBSSD:intlDVDRW,3xUSB3 ext4TB-HDX,XProfanX3+Xasm/Xpse