Das bisher trotz eingeschaltetem Inline-ASM Befehle wie AND,OR oder XOR farblich als PB-Befehle angezeigt worden sind ist ja o.K., aber in der V6 werden o.g. Befehle mit einem "Syntax error!" bedacht. Es hilft also nur ein "!" davor. Das ist irgendwie noch nicht das Gelbe vom Ei. Ideal wäre ein Compiler-Test, ob PB- oder ASM-Befehl. Ist sicher recht aufwändig, aber ich fänd´s gut.
Gruss
Helle
V6:ASM
Obwohl ich mitten im ASM-Code munter zu PB "zurück" komme (z.B. Bildschirmausgaben; wegen dieser prima Möglichkeiten bin ich ja bei PB kleben geblieben 
), könnte ich mich mit einer expliziten ASM-Kennzeichnung durchaus anfreunden. Es muss ja nicht jedesmal gleich als Section definiert werden, ein simples BeginAsm und EndAsm würde es auch tun. Der Asm-Inline-Teil von PB scheint ja sowieso seit Jahren nicht angefasst worden zu sein, z.B. nach wie vor die Schwächen bei 32-Bit Stringbefehlen (LODSD, STOSD usw.), von "neueren" Befehlen (z.B. CPUID, MMX-SSEx generell) ganz zu schweigen. Das Ganze würde sogar die Compilierung beschleunigen, bei der Übergabe an FAsm müsste der Compiler nur Begin/EndAsm entfernen.
Dies würde allerdings den Punkt Inline-Asm überflüssig machen...
Übrigens: mit V6 meinte ich natürlich die Beta 6 (habe sie bei mir nur V... genannt).
Gruss
Helle
), könnte ich mich mit einer expliziten ASM-Kennzeichnung durchaus anfreunden. Es muss ja nicht jedesmal gleich als Section definiert werden, ein simples BeginAsm und EndAsm würde es auch tun. Der Asm-Inline-Teil von PB scheint ja sowieso seit Jahren nicht angefasst worden zu sein, z.B. nach wie vor die Schwächen bei 32-Bit Stringbefehlen (LODSD, STOSD usw.), von "neueren" Befehlen (z.B. CPUID, MMX-SSEx generell) ganz zu schweigen. Das Ganze würde sogar die Compilierung beschleunigen, bei der Übergabe an FAsm müsste der Compiler nur Begin/EndAsm entfernen.Dies würde allerdings den Punkt Inline-Asm überflüssig machen...
Übrigens: mit V6 meinte ich natürlich die Beta 6 (habe sie bei mir nur V... genannt).
Gruss
Helle
Ja die idee mit Begin/EndAsm würde mir auch gefallen. Dann würde auch
endlich OR/AND in der richtigen farbe erscheinen. (Hoffe ich zumindest)
Denn die frage ist ja auch wie PB das beim Compilieren umsetzt.
Als reinen ASM Code oder vielleicht als Basic Teil. Und immer ein "!"
vor dem Befehl zu machen kann schliesslich auch keine lösung sein.
endlich OR/AND in der richtigen farbe erscheinen. (Hoffe ich zumindest)
Denn die frage ist ja auch wie PB das beim Compilieren umsetzt.
Als reinen ASM Code oder vielleicht als Basic Teil. Und immer ein "!"
vor dem Befehl zu machen kann schliesslich auch keine lösung sein.
-
technicorn
- Beiträge: 11
- Registriert: 11.03.2006 22:07
Hi,
ab Beta6 müßen die ASM-Anweisungen groß geschrieben werden
mov -> MOV
auch für Basicanweisungen scheint b6 jetzt zwischen Groß/Kleinschreibung
zu unterscheiden, bei mir ergibt case einen Syntax error, Case geht.
Und bitte kein AsmBegin/End
Ich schreibe manchmal zeilenweise umschichtig Assembler/Basic,
da würde ich dann wohl mehr AsmBegin/End schreiben als Code.
ab Beta6 müßen die ASM-Anweisungen groß geschrieben werden
mov -> MOV
auch für Basicanweisungen scheint b6 jetzt zwischen Groß/Kleinschreibung
zu unterscheiden, bei mir ergibt case einen Syntax error, Case geht.
Und bitte kein AsmBegin/End
Ich schreibe manchmal zeilenweise umschichtig Assembler/Basic,
da würde ich dann wohl mehr AsmBegin/End schreiben als Code.
Die Grossschreibung nutzt nichts. Abspeichern und neuer Aufruf - Käse.
Ging doch vorher
!
Wenn dem guten Fred einfällt, dass MOV eigentlich ein prima PB-Befehl sein kann, fang ich wieder an, ca. 12.000 Zeilen Programmcode durchzuackern. Das hält die stärkste Leber nicht aus
(nüchtern geht das nicht)!
Gruss
Helle
Ging doch vorher
!Wenn dem guten Fred einfällt, dass MOV eigentlich ein prima PB-Befehl sein kann, fang ich wieder an, ca. 12.000 Zeilen Programmcode durchzuackern. Das hält die stärkste Leber nicht aus
(nüchtern geht das nicht)!Gruss
Helle