CPU- FPU-Befehle
Christian Palmes
Dominik Schulz
Weiss jemand, wo man eine Liste mit Prozessorbefehlen
(FPU und CPU) finden kann? Oder hat jemand eine, die
er mir schicken könnte?
Danke, Domink
--
ICQ: 452 356 07
dsc...@c-nit.de oder d.sc...@firemail.de
Homepage: http://www.goettinnen.de.cx
Ing. Franz Glaser
>
> Weiss jemand, wo man eine Liste mit Prozessorbefehlen
> (FPU und CPU) finden kann? Oder hat jemand eine, die
> er mir schicken könnte?
Ei guggemol im ASM - Kapitel der TP-links.
http://bsn.ch/tp-links
Früher gab es zu Turbo Pascal noch den TASM dazu, da war ein
Buch dabei mit allem, was man braucht. Aber nun haben die
Borländer wohl gedacht, daß das für die Windoof-Freaks ohnedies
nicht mehr nötig sei.
--
Franz Glaser, Glasau 3, A-4191 Vorderweissenbach Austria +43-7219-7035-0
Muehlviertler Elektronik Glaser. Industrial control and instrumentation
http://members.eunet.at/meg-glaser/ http://members.xoom.com/f_glaser/
http://www.geocities.com/~franzglaser/ http://start.at/bedarf
Sebastian Koppehel
am Mon, 25 Oct 1999 um 14:42:09 Uhr schrieb Dominik Schulz:
> Weiss jemand, wo man eine Liste mit Prozessorbefehlen
> (FPU und CPU) finden kann? Oder hat jemand eine, die
> er mir schicken könnte?
Ich nehme an, du meinst die 68000er-Serie von Motorola...
...kleiner Scherz. Du meinst natürlich Intel, wußtest nur die Typen-
bezeichnungen der Prozessoren nicht mehr, oder?
Ausführliche Dokumentation zu den Prozessoren, natürlich inklusive
instruction sets sind unter http://www.x86.org zu finden. Etwas direktere
Informationen zur Assembler-Programmierung gibt z. B. unter
http://www.inf.upol.cz/~pitakp/asm/asmmain.htm, aber auch an vielen
anderen Stellen, die sich leicht bspw. mit Altavista finden lassen.
- Sebastian
--
"Integrieren Sie die neue Generation von Windows-Anwendungsprogrammen und
bestehende DOS-Anwendungsprogramme mit Microsoft Windows, der grafischen
Benutzeroberfläche, die sie mit OS/2, dem Betriebssystem der Zukunft,
verbindet." (Verpackungsaufschrift von Windows/286)
Frederic Bonroy
> Früher gab es zu Turbo Pascal noch den TASM dazu, da war ein
> Buch dabei mit allem, was man braucht. Aber nun haben die
> Borländer wohl gedacht, daß das für die Windoof-Freaks ohnedies
> nicht mehr nötig sei.
Assembler unter Windows? Ich bitte Sie! Schnelligkeit und ein bißchen
Hirnzellen anstrengen widersprechen doch der Windows-Philosphie
"Hauptsache bunt". :-)
Letztens hat jemand in einer Delphi Newsgroup den Nutzen von Assembler
stark angezweifelt und einige Nachteile aufgelistet. Später stellte
sich heraus: der konnte gar kein Assembler. Aber, der Delphi Compiler
optimiert, und die Hardware wird immer leistungsfähiger. So
argumentieren viele dieser Leutchen/Leuchten. Echt toll. :-(
Im übrigen verstehe ich nicht, warum der integrierte Assembler von
TP 7 nur 86er Anweisungen kennt. Damals (1992) gab es doch schon den
486.
Und der Delphi 1 Compiler konnte trotz Pentium auch nichts mit 386er
Anweisungen anfangen.
Mal abgesehen davon habe ich immer noch nicht kapiert warum es in
Delphi kein Inline mehr gibt.
Wilfried Brinkmann
Hallo Frederic !
FB> Im ｜rigen verstehe ich nicht, warum der integrierte Assembler von
FB> TP 7 nur 86er Anweisungen kennt. Damals (1992) gab es doch schon
FB> den 486.
Wieso kann er nicht? Hier schon ...
Function LongShl(L: Longint; B: Byte): Longint; Assembler;
asm
db $66; mov ax, word ptr l { mov eax, l }
mov cl, b
db $66; shl ax, cl { shl eax, cl }
db $66, $0f, $a4, $c2, $10 { shld edx,eax,16 }
end;
Function LongShr(L: Longint; B: Byte): Longint; Assembler;
asm
db $66 ; mov ax, word ptr l { mov eax, l }
mov cl, b
db $66 ; shr ax, cl { shr eax, cl }
db $66, $0f, $a4, $c2, $10 { shld edx,eax,16 }
end;
Gruss, email: t...@netsurf.de / t...@msing.de
Wilfried www : http://tsc.msing.de
Frederic Bonroy
> Wieso kann er nicht? Hier schon ...
Dann tipp mal ein
asm
shld eax, edx, 16
end
Ing. Franz Glaser
Einspruch euer Ehren!!!!
Und was dann passiert, wenn so ein Unglücksrabe dat Dingens in
einer Interrupt-Prozedur aufrufen tut und nicht dran denkt, daß
er die oberen 16-Bit gar nicht auf den Stack gerettet hat, das
wissen die Geier. "Das Programm geht so gut, aber manchmal, da
tut es ganz eigenartige Fehler machen"...
Ich will so einen Murx gar nicht sehen !
MfG
T. Junge aka LighTNing
3814867B...@mail.dotcom.fr...
> Im übrigen verstehe ich nicht, warum der integrierte Assembler von
> TP 7 nur 86er Anweisungen kennt. Damals (1992) gab es doch schon den
> 486.
> Und der Delphi 1 Compiler konnte trotz Pentium auch nichts mit 386er
> Anweisungen anfangen.
Wenn du mal scharf nachdenkst, kannst du dir die Antwort, glaube ich selbst
geben. Es gab doch da bei Borland so ein Programm namens Turbo Assembler im
Produktangebot. Wollte man das vielleicht auch verkaufen? So ne Sauerei aber
auch ;-)
Gruß,
Tom
Wilfried Brinkmann
Hallo Frederic !
FB> Dann tipp mal ein
FB> asm
FB> shld eax, edx, 16
FB> end
ich bevorzuge hex-schreibweise ;-)
db $66, $0f, $a4, $c2, $10 { shld edx,eax,16 }
Gruss, email: tsc...@netsurf.de
Wilfried www : http://tsc.msing.de
Wilfried Brinkmann
Hallo Ing. !
> > Wieso kann er nicht? Hier schon ...
>
> Dann tipp mal ein
> asm
> shld eax, edx, 16
> end
IFG> Und was dann passiert, wenn so ein Ungl cksrabe dat Dingens in
IFG> einer Interrupt-Prozedur aufrufen tut und nicht dran denkt, daá er
IFG> die oberen 16-Bit gar nicht auf den Stack gerettet hat
Wenn man schon 32bittig in einem DOS compiler arbeitet, dann MUSS man
sowas auch ber cksichtigen. Ansonsten ... Finger weg, von die Dinger ;-)
IFG> Ich will so einen Murx gar nicht sehen !
Oooch wie schade. Ist doch richtig spannend ;-)
db $66; push ax { push eax }
Ing. Franz Glaser
>
> Ing. Franz Glaser schrieb an All:
>
> >
> > Dann tipp mal ein
> > asm
> > shld eax, edx, 16
> > end
>
> IFG> Und was dann passiert, wenn so ein Ungl cksrabe dat Dingens in
> IFG> einer Interrupt-Prozedur aufrufen tut und nicht dran denkt, daá er
> IFG> die oberen 16-Bit gar nicht auf den Stack gerettet hat
>
> Wenn man schon 32bittig in einem DOS compiler arbeitet, dann MUSS man
> sowas auch ber cksichtigen. Ansonsten ... Finger weg, von die Dinger ;-)
Procedure Irgendwas(Flags,AX,BX....); Interrupt;
(*oder so ähnlich*)
Begin
End;
Wie KANN man da sowas berücksichtigen? Eventuell nochmal im Code
alle ExX - Register pushen? Und wie bring ich das Zeug dann auch
noch in die Parameter?
Nochmal:
> IFG> Ich will so einen Murx gar nicht sehen !
Definitiv: Der TP - Compiler ist ein 16-Bit compiler. Alles was
darüber hinausgeht, ist was für richtige Experten. Und die
denken gar nicht dran, so einen Murx zu machen, also fällt es
flach.
Hourdi
nur weil's sooft erwähnt wurde:
TASM 5.0 Nr. KS-419-04 DM98,80
Originalhandbuch Nr. CL-145--04 DM98,80
jeweils incl. Wehrmachtsteuer bei
Pearl Agency, Tel. 0180 55582
Ob's billiger als bei Bohrland ist, weiss ich nicht.
(und zusätzlich wird ganz umsonst eure Adresse weiterverhökert)
Mein Trick: Beim Absender kommt _hinter_ die Hausnummer
nach einem Schrägstrich ein "A" und die Datensatznummer aus der Adress-
datenbank. Den Briefträger hat's noch nie gestört, und auf einmal
weiss man wunderbar, wer die Adresse trotz Verbot wohin verkauft hat.
Abs:
Hourdi Hallmackenreutter
Backpflaumenalle 77 / A343
77777 Stakeln an der Kruke
OT:
Hintergrund: Meine Mutter hat durch exzessiven Versandhandelsumgang
(Preisausschreiben und Gewinnversprechungen) ihre gesamte Rente
in Qualitätswaren rotchinesischer und ähnlicher Provenienz angelegt, und ich
kämpfe gegen eine Flut von ca. _sechstausend_ Werbe- bzw. Bettelbriefen
und Katalogen pro Jahr (Jeden Tag Postfach mit dem Schürhaken leeren)
Danke, bin nicht ausgelastet.
--
Hourdi
alias Georg O.F. Richter
hou...@t-online.de
Dominik Schulz
> Hallo,
>
> am Mon, 25 Oct 1999 um 14:42:09 Uhr schrieb Dominik Schulz:
>
> > Weiss jemand, wo man eine Liste mit Prozessorbefehlen
> > (FPU und CPU) finden kann? Oder hat jemand eine, die
> > er mir schicken könnte?
>
> Ich nehme an, du meinst die 68000er-Serie von Motorola...
>
> ...kleiner Scherz. Du meinst natürlich Intel, wußtest nur die Typen-
> bezeichnungen der Prozessoren nicht mehr, oder?
>
> Ausführliche Dokumentation zu den Prozessoren, natürlich inklusive
> instruction sets sind unter http://www.x86.org zu finden. Etwas direktere
> Informationen zur Assembler-Programmierung gibt z. B. unter
> http://www.inf.upol.cz/~pitakp/asm/asmmain.htm, aber auch an vielen
> anderen Stellen, die sich leicht bspw. mit Altavista finden lassen.
>
> - Sebastian
ciao, Dominik
--
Dominik Schulz - ICQ: 452 356 07
Vinzent Hoefler
>Und was dann passiert, wenn so ein Unglücksrabe dat Dingens in
>einer Interrupt-Prozedur aufrufen tut und nicht dran denkt, daß
>er die oberen 16-Bit gar nicht auf den Stack gerettet hat, das
>wissen die Geier.
Sein Problem.
Ich wuerde "db 66h; pusha" und "db 66h; popa" vorschlagen. Ausserdem
wuerde ich Interrupt-Prozeduren sowieso komplett in Assembler
schreiben. ;-)
>"Das Programm geht so gut, aber manchmal, da
>tut es ganz eigenartige Fehler machen"...
"Manchmal" ist ja schon ein guter Hinweis auf derartige Fehler. ;-)
>Ich will so einen Murx gar nicht sehen !
Das musst Du dann aber Borland auch klar machen. Wie war das bei denn
seit Version 7 - Nutzung von 32-Bit Befehlen bei
LongInt-Multiplikation/Division?
Und wenn ich nun innerhalb einer in reinem Pascal geschriebenen
Interrupt-Prozedur mit LongInts rechne?
Vinzent.
--
A girl with a future avoids the man with a past.
-- Evan Esar, "The Humor of Humor"
Wilfried Brinkmann
Hallo Ing. !
> IFG> Und was dann passiert, wenn so ein Ungl cksrabe dat Dingens in
> IFG> einer Interrupt-Prozedur aufrufen tut und nicht dran denkt, daá er
> IFG> die oberen 16-Bit gar nicht auf den Stack gerettet hat
>
> Wenn man schon 32bittig in einem DOS compiler arbeitet, dann MUSS man
> sowas auch ber cksichtigen. Ansonsten ... Finger weg, von die Dinger ;-)
IFG> Procedure Irgendwas(Flags,AX,BX....); Interrupt;
IFG> (*oder so „hnlich*)
IFG> Begin
IFG> End;
IFG> Wie KANN man da sowas ber cksichtigen?
Es ist wohl (imho) ziemlich unsinnig Interrupt routinen 32 bittig
zu schreiben. Aber dennoch ist auch sowas m”glich. Man muss halt
nur daf r sorgen, das registerver„nderungen ber cksichtigt werden,
indem ich vorher ein db $66; push <Register> und dannach ein
db $66; Pop <Register> mache.
IFG> Eventuell nochmal im Code alle ExX - Register pushen? Und wie
IFG> bring ich das Zeug dann auch noch in die Parameter?
Wenn Du mal im Borlan Handbuch schn ffelt, findest Du dort auch alle
Antworten. Interruptroutinen pushen am anfang alle Regs auf den Stack
und restaurieren selbige am ende, gefolgt von einem IRet.
Also kann ich doch auch h„ndisch folgendes machen:
Procedure Irgendwas(Flags ... : Word); Interrupt;
begin
{ hier prodziert BP zun„chst alle PUSH reg }
asm
db $66; pusha { alle 32bit regs auf Stack }
end;
... tu was mit 16 oder 32 bit ...
asm
db $66; popa { Register restaurieren }
end;
{ hier produziert Borland alle POP reg und ein IRET }
end;
IFG> Definitiv: Der TP - Compiler ist ein 16-Bit compiler. Alles was
IFG> dar ber hinausgeht, ist was f r richtige Experten.
Dem will ich nicht wiedersprechen ...
IFG> Und die denken gar nicht dran, so einen Murx zu machen, also
IFG> f„llt es flach.
Das stimmt in der form nicht. Ich habe schon viele derartigen routinen
geschrieben. Es gibt einige Dinge, wo man nicht darumherumkommt, solche
Klimmz ge zu machen.
Ing. Franz Glaser
>
> Es ist wohl (imho) ziemlich unsinnig Interrupt routinen 32 bittig
> zu schreiben. Aber dennoch ist auch sowas m”glich. Man muss halt
> nur daf r sorgen, das registerver„nderungen ber cksichtigt werden,
> indem ich vorher ein db $66; push <Register> und dannach ein
> db $66; Pop <Register> mache.
Offenbar muß ich das da präzisieren...
Eine Procedure .... ;interrupt kann ja beliebige andere Prozeduren
aufrufen, verwenden, benutzen. Und dann gibt es das Quirx. Weil da
kein Mensch mehr an die Beschleunigungstricks denkt.
Oder die Prozeduren werden erst später "optimiert" (Frederic,
schau her!) und keiner denkt dran, daß die auch über 3 levels
von einer Int-Prozedur verwendet werden.
Genau Selbiges ist ja den Borland-guys passiert mit den longints.
Worauf ich hinauswill: Wenn schon 32-bit, dann konsequent, aber nicht
in dem "Optimierer" - Sinn.
Natürlich ist nix dagegen zu sagen, einen Interrupthandler komplett
in ASM zu schreiben, dann gibts das Dilemma auch nicht. Aber das ist
was für Gurus. Ich wollte hier nur eine Warnung deponieren, die sich
mit dem Procedure...;Interrupt in Zusammenhang bringen läßt.
Einerseits haben es die Borländer den Programmierern, auch den
weniger geskillten, mit der Procedure Interrupt leicht gemacht,
ins Gefleisch des Systems einzugreifen, aber andererseits ist
das halt nicht ganz so harmlos. In diesem Sinne...
Übrigens, eine Frage: Kommt euch die TP-links von Geocities in der
letzten Zeit auch so langsam vor? Seit Yahoo das gekauft hat, ist
es nicht mehr das alte.
MfG
Frederic Bonroy
> Einspruch euer Ehren!!!!
Einspruch abgelehnt.
> Und was dann passiert, wenn so ein Unglücksrabe dat Dingens in
> einer Interrupt-Prozedur aufrufen tut und nicht dran denkt, daß
> er die oberen 16-Bit gar nicht auf den Stack gerettet hat, das
> wissen die Geier. "Das Programm geht so gut, aber manchmal, da
> tut es ganz eigenartige Fehler machen"...
Es ging alleinig darum, daß der Compiler keine 32 Bit Anweisungen versteht -
und nicht um irgendwelche Interruptprozeduren. Das ist Sache des
Programmierers, darauf zu achten, daß sein Code korrekt funktioniert. Und ob
man das jetzt als
db $66, $0f, $a4, $c2, $10 oder shld eax, edx, 16 schreibt, ist letztendlich
Wurscht. Die zweite Variante ist eben angenehmer.
Frederic Bonroy
> Oder die Prozeduren werden erst später "optimiert" (Frederic,
> schau her!) und keiner denkt dran, daß die auch über 3 levels
> von einer Int-Prozedur verwendet werden.
Stabilität kommt bei mir grundsätzlich vor Geschwindigkeit.
Nochmal: worauf ich eigentlich hinaus wollte ist: wenn man 32 Bit Code in
Hex schreibt, muß man auch auf solche Sachen achten, die Sie hier ja erwähnt
haben. Dann kann man ihn auch eigentlich direkt ausschreiben.
Mir ging es in meinem Posting lediglich um den Komfort, nicht um
irgendwelche Optimierungen oder Interruptprozeduren.
Klaus Loerke
Du meinst die Dinge, die Microsoft beide nicht kennt?
scnr, klausi
Wilfried Brinkmann
> Es ist wohl (imho) ziemlich unsinnig Interrupt routinen 32 bittig
> zu schreiben. Aber dennoch ist auch sowas m”glich. Man muss halt
> nur daf r sorgen, das registerver„nderungen ber cksichtigt werden,
> indem ich vorher ein db $66; push <Register> und dannach ein
> db $66; Pop <Register> mache.
IFG> Offenbar muá ich das da pr„zisieren...
IFG> Eine Procedure .... ;interrupt kann ja beliebige andere Prozeduren
IFG> aufrufen, verwenden, benutzen. Und dann gibt es das Quirx. Weil da
IFG> kein Mensch mehr an die Beschleunigungstricks denkt.
Sorry, aber wenn der Programmierer _SO_ Bl”d ist, dann kann Ihm nichts
mehr helfen, egal ob 16 oder 32 bittig. In jeder asm-Routine kann man
leicht fehler einbauen, das hat nichts damit zu tun, ob ich die in 32bit
oder 16bit schreibe. Einfach mal in einer 16bit asm das Push DS vergessen
und anschliessend ein LDS xyz und schon ist ein Bug programmiert.
IFG> Oder die Prozeduren werden erst sp„ter "optimiert" (Frederic,
IFG> schau her!) und keiner denkt dran, daá die auch ber 3 levels von
IFG> einer Int-Prozedur verwendet werden.
Man sollte immer wissen, was man macht/ver„ndert.
IFG> Genau Selbiges ist ja den Borland-guys passiert mit den longints.
Warscheinlich war der programmierer unterbezahlt ;-))
IFG> Worauf ich hinauswill: Wenn schon 32-bit, dann konsequent, aber
IFG> nicht in dem "Optimierer" - Sinn.
Unsinn! Gerade f r DOS-Programme sind solche 32bitigen optimierungen
angebracht. Wenn der compiler schon optimalen 32bit code erzeugt, muss
man das nun wirklich nicht mehr von hand machen.
IFG> Aber das ist was f r Gurus. Ich wollte hier nur eine Warnung
IFG> deponieren, die sich mit dem Procedure...;Interrupt in
IFG> Zusammenhang bringen l„át.
Nat rlich sollt sowas nur jemand machen, der sein Handwerk versteht.
Nur lassen sich solche Fehler nicht nur auf Interrupt proceduren beziehen.
Der gleiche Fehler kann berall gemacht werden und nebenwirkungen sind
dann nie auszuschliessen ...
Wilfried Brinkmann
> Und was dann passiert, wenn so ein Ungl cksrabe dat Dingens in
> einer Interrupt-Prozedur aufrufen tut und nicht dran denkt, daá
> er die oberen 16-Bit gar nicht auf den Stack gerettet hat, das
> wissen die Geier. "Das Programm geht so gut, aber manchmal, da
> tut es ganz eigenartige Fehler machen"...
FB> Es ging alleinig darum, daá der Compiler keine 32 Bit Anweisungen
FB> versteht -
.. was er in der Tat nicht macht ...
FB> und nicht um irgendwelche Interruptprozeduren. Das ist
FB> Sache des Programmierers, darauf zu achten, daá sein Code korrekt
FB> funktioniert.
Meine Rede ;-)
FB> Und ob man das jetzt als
FB> db $66, $0f, $a4, $c2, $10 oder shld eax, edx, 16 schreibt, ist
FB> letztendlich Wurscht.
.. weil der compiler das ohnehin in eben diese bytefolge bersetzen w rde.
Vinzent Hoefler
>Es ist wohl (imho) ziemlich unsinnig Interrupt routinen 32 bittig
>zu schreiben.
Wieso?
Vinzent.
--
MSDOS is not dead, it just smells that way.
-- Henry Spencer
Frederic Bonroy
> >Stabilität kommt bei mir grundsätzlich vor Geschwindigkeit.
>
> Du meinst die Dinge, die Microsoft beide nicht kennt?
Ich habe letzten Sonntag zum x-ten mal Windows 95 neuinstalliert. Da
stand doch tatsächlich was von "Windows 95 - ein Synonym für
Geschwindigkeit und Effizienz". Kein Scherz, das stand da echt! LOL!
Im Grunde sind es ja nicht die durchschnittlichen 73 Abstürze meines
effizienten Systems pro Tag, die mich so sehr stören. Und daran, daß
mein Pentium unter dem schnellen Windows 95 schleicht wie ein
runtergetakteter 8086er bei der Berechnung der 100000sten Stelle von Pi
habe ich mich auch gewöhnt.
Nee, die Betatester waren richtige Flaschen. Die Oberfläche ist ja an
sich makellos, mal abgesehen davon, daß ich persönlich noch gerne einen
Blumentopf rechts unten hätte, mit Tulpen drin. Säh' doch toll aus.
Die Registrierung allerdings - die schrumpft nicht wenn man Einträge
löscht. Nööö, die wächst höchstens; wenn Programme wie der Internet
Exploder sie mit lauter sinnvollen Einträgen vollpumpen. Und wenn man
eines der Programme rausschmeißen will, mit einer der extrem
leistungsfähigen Desinstallationsroutinen ("some elements could not be
removed. Remove them manually"), dann bleiben alle Einträge hängen und
dann muß der Benutzer selber ran. Registrierung exportieren, DOS
starten, Registrierung importieren, Computer neu starten. Richtig
intuitiv eben, wer da nicht drauf kommt kauft sich eben nochmal 128 MB
RAM dazu und dann ist die wachsende Registrierung zumindest in den
nächsten 14 Tagen kein Thema mehr. Dann wird's wieder eng. Natürlich
braucht man unbedingt mindestend 800 MHz, damit die Fehlermeldungen so
schnell wie möglich angezeigt werden.
Ach, Gates, danke.
Arsčne von Wyss
3814A697...@eunet.at...
> Frederic Bonroy wrote:
> > Wilfried Brinkmann wrote:
> >
> > shld eax, edx, 16
> > end
>
Einspruch nicht stattgegeben...
> Und was dann passiert, wenn so ein Unglücksrabe dat Dingens in
> einer Interrupt-Prozedur aufrufen tut und nicht dran denkt, daß
> er die oberen 16-Bit gar nicht auf den Stack gerettet hat, das
> wissen die Geier. "Das Programm geht so gut, aber manchmal, da
> tut es ganz eigenartige Fehler machen"...
BP stellt sich hier selbst eine Falle, weswegen das nicht als Argument
akzeptiert werden kann. Und zwar benutzen die Borländer sehr wohl 386-Code
in der RTL von BP7 für Long-Multiplikationen und Divisionen, und zwar in
Form eines Tests auf die Prozessortypvariable vor jeder solchen Anweisung.
Ich selbst verwende deshalb nicht das INTERRUPT-Schlüsselwort.
Sollte jemand es trotzdem benutzen, so sollte er am Anfang der
INTERRUPT-Prozedur am besten die Variable Test8068 sichern und für die Dauer
der Interrupt-Prozedur auf 1 setzen...
> Ich will so einen Murx gar nicht sehen !
Möchte ich auch nicht, darum schreibe ich mir meine Interrupt-Procs immer in
Assembler, da weiss ich auch WAS ich sichere, und IRET kennt der integrierte
Assembler ja schliesslich auch...
--
Arsène von Wyss - avon...@gmx.net
Pascal, Delphi & Personal stuff: http://bsn.ch/avonwyss
Programming Contest Problems Archive: http://bsn.ch/contest
Webmaster von Roger's Equine Pages: http://bsn.ch/pferde
Wilfried Brinkmann
Hallo Vinzent !
>Es ist wohl (imho) ziemlich unsinnig Interrupt routinen 32 bittig
>zu schreiben.
VH> Wieso?
Kennst Du einen DOS-Int, (und davon reden wir ja) der 32 bit Register
unterst》zt? Ich nicht ...
Das m《sen schon _sehr_ spezielle Sachen sein, wo man da 32bittigen code
schreibt. Mir f�lt adhock nichts ein ...
Wilfried Brinkmann
Hallo Frederic !
> >Stabilit„t kommt bei mir grunds„tzlich vor Geschwindigkeit.
>
> Du meinst die Dinge, die Microsoft beide nicht kennt?
FB> Ich habe letzten Sonntag zum x-ten mal Windows 95 neuinstalliert.
An und f r sich ist das doch normal? ;-)
FB> Im Grunde sind es ja nicht die durchschnittlichen 73 Abst rze
FB> meines effizienten Systems pro Tag, die mich so sehr st”ren.
[..]
FB> Die Registrierung allerdings - die schrumpft nicht wenn man
FB> Eintr„ge l”scht. N”””, die w„chst h”chstens; wenn Programme wie
FB> der Internet Exploder sie mit lauter sinnvollen Eintr„gen
FB> vollpumpen. Und wenn man eines der Programme rausschmeiáen will,
FB> mit einer der extrem leistungsf„higen Desinstallationsroutinen
FB> ("some elements could not be removed. Remove them manually"), dann
FB> bleiben alle Eintr„ge h„ngen und dann muá der Benutzer selber ran.
Warum glaubst Du, verwende ich sowas nicht? Hier l„uft OS/2 pur rund um
die Uhr, 7 Tage die woche, 365 Tage im Jahr.
Ing. Franz Glaser
>
> Nochmal: worauf ich eigentlich hinaus wollte ist: wenn man 32 Bit
> Code in Hex schreibt, muß man auch auf solche Sachen achten, die
> Sie hier ja erwähnt haben. Dann kann man ihn auch eigentlich direkt
> ausschreiben.
> Mir ging es in meinem Posting lediglich um den Komfort, nicht um
> irgendwelche Optimierungen oder Interruptprozeduren.
Jaja, Frederic, schon klar.
Ich gehe bloß einen Schritt weiter: es ist mir völlig egal, ob es
für undefinierte Maschinenbefehle im ASM einen Übersetzer gibt, denn
diese Befehle sind auf jeden Fall ein Fremdkörper im Programm. Ich
würde sie nicht verwenden.
Allerdings: ich habe auch $L - eingebettete Routinen verwendet,
aber dafür ist ja der TASM da. Und damit habe ich natürlich die
ganze Verantwortung selber. Aber Turbo Pascal selber ist ja für
"Turbo" Programmierer gemacht, nicht für Leute, die Riesenprojekte
damit anpacken wollen.
Ing. Franz Glaser
>
> Ing. Franz Glaser schrieb an Wilfried Brinkmann:
>
> IFG> aufrufen, verwenden, benutzen. Und dann gibt es das Quirx. Weil da
> IFG> kein Mensch mehr an die Beschleunigungstricks denkt.
>
> Sorry, aber wenn der Programmierer _SO_ Bl”d ist, dann kann Ihm nichts
> mehr helfen, egal ob 16 oder 32 bittig.
HammSe schon mal im Team entwickelt? Oder nach 5 Jahren ein Programm
gewartet? Oder von irgendwo eine unit oder eine .OBJ eingebunden?
Vinzent Hoefler
>Kennst Du einen DOS-Int, (und davon reden wir ja)
InterruptRoutine<>DOS-Int, oder?
Aber z.B. koennte eine Timer-Routine oder ein Soundkarteninterrupt
durchaus auch 32-Bit-Code enthalten duerfen, oder?
>der 32 bit Register
>unterst》zt? Ich nicht ...
Nun, so aus dem Kopf nicht, aber zumindest die XMS 3.0 Erweiterung
(wird zwar als far call angesprochen) erwartet bei den erweiterten
Funktionen 32 Bit Register.
>Das m《sen schon _sehr_ spezielle Sachen sein, wo man da 32bittigen code
>schreibt. Mir f�lt adhock nichts ein ...
Nunja, einige (neuere) BIOS-Ints gaebe es da sicher noch...
Allerdings gibt es bei normalen Int-Aufrufen ja auch keine Probleme,
wenn man denn 32-Bit-Register benutzt. Die Probleme treten
schliesslich erst durch die Hardware-Interrupts auf, in denen der
Inhalt der Register erhalten bleiben muss.
Wie schon gesagt, ich habe so meine Gruende, warum ich
Interrupt-Routinen sowieso komplett in Assembler schreibe. :-)
Vinzent.
Wilfried Brinkmann
IFG> Ich gehe bloá einen Schritt weiter: es ist mir v”llig egal, ob es
IFG> f r undefinierte Maschinenbefehle im ASM einen šbersetzer gibt,
IFG> denn diese Befehle sind auf jeden Fall ein Fremdk”rper im
IFG> Programm. Ich w rde sie nicht verwenden.
Prinzipiell richtig. Nur muss mal halt ber cksichtigen, aus welcher
CPU-Generation BP7 stammt. Dezeit war das h”chste der Gef hle ein
486er und den hatte nicht jeder. Ausserden ist DOS/Win 3.x immer noch
ein (mehr oder weniger) DOS Programm, alles auf 16 bit getrimmt.
Mittlerweile hat aber wohl jeder einen Pentium, da ist 32 bit nichts
aussergew”hliches mehr.
IFG> Aber Turbo Pascal selber ist ja f r "Turbo" Programmierer
IFG> gemacht, nicht f r Leute, die Riesenprojekte damit anpacken
IFG> wollen.
Dem m”chte ich doch heftig wiedersprechen. Ich kenne jede menge _sehr_
grosser Projekte f r die Industrie, die mit BP7 erstellt wurden und
heute noch problemlos laufen. Neuerdings wird allerdings mehr Delphi
verwendet, weil halt allewelt auf "Click click" und Windows abf„hrt ...
Wilfried Brinkmann
> Sorry, aber wenn der Programmierer _SO_ Bl”d ist, dann kann Ihm nichts
> mehr helfen, egal ob 16 oder 32 bittig.
IFG> HammSe schon mal im Team entwickelt?
Mache ich eigentlich immer ...
IFG> Oder nach 5 Jahren ein Programm gewartet?
Jep. Mein ex Arbeitgeber ruft mich heute immer noch an, wenn wieder mal
Ger„te zur Wartung/Software„nderung reinkommen, die ich anno 1985/90
programmiert habe ..
IFG> Oder von irgendwo eine unit oder eine .OBJ eingebunden?
Auch das.
F r mich gilt grunds„tzlich;
WENN ich ein vorhandenes Programm (egal ob von mir oder anderen geschrieben)
ge„ndert wird, MUSS ich auch die abh„ngigen Routinen Pr fen, ob da eventuell
unvertr„glichkeiten zum neuen Code bestehen. Tue ich das nicht, sind
Probleme vorhersehbar.
Wilfried Brinkmann
Hallo Vinzent !
>Kennst Du einen DOS-Int, (und davon reden wir ja)
VH> InterruptRoutine<>DOS-Int, oder?
Ja, ja :-)
VH> Aber z.B. koennte eine Timer-Routine oder ein Soundkarteninterrupt
VH> durchaus auch 32-Bit-Code enthalten duerfen, oder?
Sicher, ist garnicht so ungew派lich ...
VH> Wie schon gesagt, ich habe so meine Gruende, warum ich
VH> Interrupt-Routinen sowieso komplett in Assembler schreibe. :-)
Was sicher nichts verkehrtes ist.
Aber so langsam verlassen wir die Ebene, worum es eingentlich ging.
Tenor der Geschicht;
Wenn 32bittiger Code eingeflochten wird, MUSS der Programmierer halt
ber…ksichtigen, dass BP _nur_ ein 16bit Compiler ist. Daraus entstehende
Nebeneffekte m《sen halt ber…ksichtigt werden.
Denke, darauf k馬nen wir uns einigen ...
Klaus Loerke
<3815F199...@mail.dotcom.fr>...
>Klaus Loerke wrote:
>
>> >Stabilität kommt bei mir grundsätzlich vor Geschwindigkeit.
>>
>> Du meinst die Dinge, die Microsoft beide nicht kennt?
>
>stand doch tatsächlich was von "Windows 95 - ein Synonym für
>Geschwindigkeit und Effizienz". Kein Scherz, das stand da echt! LOL!
Ich weiß! Ich hab es auch erst 5 mal gelesen (pro Computer!) und mich
jedesmal wieder schlappgelacht. Da sage noch einer, Microsoft verstehe
keinen Spaß.
;-) klausi
Frederic Bonroy
> Wenn du mal scharf nachdenkst, kannst du dir die Antwort, glaube ich selbst
> geben. Es gab doch da bei Borland so ein Programm namens Turbo Assembler im
> Produktangebot. Wollte man das vielleicht auch verkaufen? So ne Sauerei aber
> auch ;-)
Dann erklär' mir mal warum das bei Borland Pascal dabei war. Damit ich es mir
nochmal zusätzlich kaufe? ;-)
T. Junge aka LighTNing
3817288E...@mail.dotcom.fr...
> Dann erklär' mir mal warum das bei Borland Pascal dabei war. Damit ich es
mir
> nochmal zusätzlich kaufe? ;-)
Beachte die Verhältnismäßigkeit: Borland Pascal kostete 799.- (oder sogar
899), Turbo Pascal, wenn ich mich recht entsinne, zwischen 199.- und 249.-.
BP war als Paket für fortgeschrittene & professionelle Developer gedacht, TP
hingegen für Einsteiger - deswegen auch so billig und ohne TASM, da den ein
Einsteiger ohnehin nicht braucht.
Gruß,
Tom