home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.uni-stuttgart.de/pub/systems/acorn/
/
Acorn.tar
/
Acorn
/
acornet
/
fun
/
mags
/
hl-05-93.arc
/
!HL-05_93_Text_-Coding
< prev
next >
Wrap
Text File
|
1993-12-01
|
29KB
|
696 lines
ÿÿÿÿÿÿÿÿÿÿ Programmierung ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
An alle:
Wer hat eine superschnelle (z.B. binΣre) Suchroutine in BASIC oder Inline-
Assembler programmiert, so da▀ sie auch ohne Weiteres in einem BASIC-Proggie
funktioniert?
Brauche sie DRINGENDST fⁿr mein PD-Archivprog "!WombatPD".
Danke im Voraus. Addi in der 300.
Wombat.
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Wenn tatsΣchlich irgendwann mal einer den BASIC-Assembler aufmotzen sollte, so
habe ich dafⁿr auch noch (neben den FPA-Befehlen) eine Wunschliste:
-kein 1000faches EQUB xx:EQUB yy:... mehr, sondern etwas wie: DCB xx,yy,zz,...
wie es in allen modernen Assemblern auf der ganzen Welt ist
-da der ARD-Befehl eh` nur ein Pseudo-Befehl ist, k÷nnte man ihn auch gleich
auf beliebige Adre▀rΣume umschreiben, es werden dann halt 1-4 Mnemonics
erzeugt
-bei einem MOV-Befehl mit negativem Operanden wird automatisch MVN benutzt
-ein DCS (bzw. EQUS) kann mit "...",0 terminiert werden
Das ist mir im Moment dazu eingefallen.
Sorcerer
(Denkbar wΣren z.B. auch noch mehrere Standardmakros fⁿr ADD und SUB.
Au▀erdem k÷nnte man bei der Gelegenheit gleich noch ein DIV-Makro einbauen.)
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Acero! Hier ist meine L÷sung zum Bytes vertauschen innerhalb eines Words.
Leider komme ich nicht auf 3-4 Taktzyklen wie Roger "Gott" Wilson, ich brauche
leider mindestens 5! Je nach Anwendung kannst Du aber gegebenenfalls den
letzten Befehl weglassen, bzw. in den nachfolgenden integrieren.
On Entry: { R0 - Wert }
On Exit : { R0 - gedrehter Wert
R1 - corrupted }
BIC R1,R0,#&FF000000
BIC R1,R1,#&0000FF00
EOR R0,R0,R1,ROR #16
EOR R0,R0,R1
MOV R0,R0,ROR #24
Ich hoffe aber, da▀ hier von anderen noch bessere L÷sungen kommen!
Sorcerer
(Thank U !)
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
QArc! Hoffentlich programmiert Du Deine Programme nicht immer so nachlΣssig,
denn sonst kann es passieren, da▀ ein Programm/Demo mal lΣuft, mal aber auch
nicht: Du hast vergessen (?), den Bereich anzugeben, dessen Gr÷▀e mit
OS_ReadDynamicArea geladen werden soll. Fⁿr den Bildschirmspeicher mu▀t Du
zuvor R0 mit einer #2 laden, ansonsten nimmt er, was er gerade in R0
vorfindet, und das k÷nnen halt Werte von 0 bis 2^32-1 sein, wobei in 2^32-7
FΣllen die Meldung 'Unknown Dynamic Area', weil nur R0-Werte von 0-5 definiert
sind.
Ein Vorschlag zur Verbesserung Deiner Stern-Routine wΣre, da▀ Du 'speed' und
'colour' zusammen in ein Word steckst, den speed z.B. 8 Stellen hochshiftest
(LSL #8), und dann zur aktuellen Spalte addierst mit:
ADD R1,R1,R2,LSR #8
Da▀ 'ⁿber' der Farbe noch weitere Bits gesetzt sind, ist hier irrelevant, da
mit
STRB R3,[R6,R0,LSL #6]
wirklich nur die unteren 8 Bits benutzt werden. So sparst Du immerhin einen
ganzen (!) Taktzyklus dadurch, da▀ Du ein Register weniger in der LDM/STM-Liste
hast!!! Wenn Du dann noch die Sterne von rechts nach links laufen lΣ▀t, sparst
Du Dir noch das 'CMP R1,#320' (wieder ein ganzer (!) Taktzyklus!!!), und wenn
Du getrennte Tabellen anlegst fⁿr x-Position und speed/color, brauchst Du nicht
immer mit STM 3 Register abzulegen, es reicht hier ein einzelnes STR fⁿr die
neue x-Koordinate!
Jetzt aber ein Vorschlag fⁿr die ─sthetik: Viel sch÷ner sieht es aus, wenn die
Sterne langsam scrollen, d.h. mit maximal 1 Pixel/VSync. Schau Dir Demo▓ an,
wenn Du wissen willst, was ich meine. Der Gro▀teil mu▀ hier bei den langsamen
Sternen (1 Pixel alle 5-8 VSyncs) liegen, nur ganz, ganz wenige dⁿrfen
schneller scrollen.
Probier's aus!
Sorcerer
(Diese Anzi hat mich auf eine coole (?) Idee gebracht: Bis zum nΣchsten
Hardliner k÷nnen alle interessierten Coder mal eine m÷glichst hochoptimierte
Starscroller-Routine einreichen. Sieger - allerdings ohne Preisgeld oder
sonstige materiellen Vergⁿtungen - ist derjenige, der die Routine mit den
meisten Stars vorweisen kann.
Voraussetzungen: Mode 13, alle denkbaren Geschwindigkeiten zwischen 1/16 und
8 Pixeln/Sekunde mⁿssen m÷glich sein, das Minidemo (sollte man es vielleicht
"Recordmo" nennen ?) darf nicht lΣnger als 2048 Bytes sein, langsame Pixel
sind dunkler als helle (allerdings mu▀ nicht fⁿr jede Geschwindigkeit eine
Extrafarbe angegeben werden - es reicht ja eine Farbe fⁿr zwei oder gar
drei Geschwindigkeiten), mit SPACE kann man das Demo verlassen...
Und mit dem nΣchsten Hardliner werden dann alle eingesandten Demos ver-
schickt. Der Sieger erhΣlt den Titel "Star of Stars" und darf kⁿnftig stolz
sein.
Vielleicht k÷nnten wir solche Wettbewerbe ÷fter durchfⁿhren...)
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Bei komplexeren Berechnungen in Assembler erreicht man selbst mit 32-Bit-
Werten schnell die Grenzen der Integerberechnung. Deswegen brauchte ich,
ursprⁿnglich um Vektormodelle um beliebige Achsen zu drehen, eine Floating-
Point-Arithmetik. Ich mu▀ zugeben, ich habe mich nicht nΣher mit dem FPE
befa▀t, weil die Befehle ja im BASIC-Assembler nicht zur Verfⁿgung stehen.
Und was den FPA betrifft: Der wird sich in meinem Archi nie heimisch fⁿhlen
(lΣuft nicht mit 35Mhz ARM3!). Die folgenden FP-Makros gehen von dem Format
aus:
reg1 = 16-Bit-Mantisse mit Vorzeichen, also mu▀ bit15 immer das h÷chste
signifikante Bit sein
reg2 = Exponent mit Vorzeichen
mit Wert = reg1 / 2^reg2
So lassen sich alle Werte, die betragsmΣ▀ig kleiner sind als 2^16 mit
positivem Exponenten darstellen. Negativ wird der Exponent dabei nur fⁿr
sehr gro▀e Zahlen. Natⁿrlich k÷nnen die Werte praktisch beliebig klein
oder gro▀ werden, da der Exponent ein ganzes Register belegt.
Und jetzt ein Multiplikations-Makro dafⁿr:
DEF FNmul(C,Ce, A,Ae, B,Be) :*| berechnet (C,Ce) = (A,Ae)*(B,Be)
LOCAL pos, neg, eot
LOCAL t,s
s= P%
FOR t=0 TO 1: P%= s :*| mini two-pass-assembly
[ OPT PASS*t
ADD Ce, Ae,Be ; add exponents
SUB Ce,Ce,#15 ; -15, as result shifted right by 15 places
MOV C, A,ASR#1 ; avoid overflow
MUL C, B,C ; multiply!
MOVS C,C,ASR#14 ; and shift back
BMI neg
.pos TST C,#2^16 ; if result positive and bit16 set then
MOVNE C,C,ASR#1; shift right by 1
SUBNE Ce,Ce,#1 ; and decrease exponent by 1
B eot
.neg TST C,#2^16 ; if result negative and bit16 clear then
MOVEQ C,C,ASR#1; shift right by 1
SUBEQ Ce,Ce,#1 ; and decrease exp by 1
.eot
]
NEXT t :=0
Alles klar?
Das sollte doch relativ (zum FPE) schnell gehen.
Wenn man wei▀, da▀ beide Werte positiv sind, ist die Sache sogar noch viel
einfacher:
DEF FNmulp(C,Ce, A,Ae, B,Be)
[ OPT PASS ; multiplies two positives
ADD Ce, Ae,Be
SUB Ce,Ce,#15
MUL C,B,A
MOV C,C,LSR#15
TST C,#2^16
MOVNE C,C,ASR#1
SUBNE Ce,Ce,#1
] :=0
Man k÷nnte damit also zum Beispiel schreiben:
MOV R2,#&C000
MOV R3,#15 ; Konstante &C000/2^15 = 1.5
FNmul(R0,R1, R0,R1, R2,R3)
Das multipliziert eine Flie▀kommazahl in (R0,R1) mit der Konstanten 1.5 .
Natⁿrlich ist die Genauigkeit dieser Routinen beschrΣnkt (ca 4 Dezimal-
stellen), aber fⁿr meine Zwecke reicht das aus (siehe MagnetoidsDemo!)
Schwieriger wird die Sache allerdings bei *Additionen*, mit ungleichem
Vorzeichen, sprich Subtraktionen. Hier wird das Angleichen des Ergebnisses
leider etwas langsamer (loop).
Interessiert euch die ganze Fachsimpelei eigentlich ???
Quatsche ich Chinesisch oder Unsinn ???
Oder wollt ihr meehr ?!?
Wenn ja, k÷nnte ich mich rumkriegen lassen, auch die restlichen Makros
vorzustellen. Wie wΣre es ⁿbrigens mit einem Vektorgrafikkurs im HL?
(das ist nΣmlich mein Steckenpferd, sozusagen).
Jared
(Jared, was hei▀t hier Fachsimpelei ? Diese Rubrik ist doch dazu da, um
alles das zu ver÷ffentlichen, was man fⁿr sinnvoll hΣlt ! Und so ein
cooles MUL-Makro geh÷rt ganz bestimmt zu den Sachen, die der eine oder
andere Leser irgendwann mal brauchen wird.)
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Acero!
Also, zu der Bytevertauschungsroutine:
vorher: R0= (b1b2b3b4)
MOV R1,R0,LSL#24
ADD R1,R1,R0,LSR#24
AND R2,R0,#&FF00
ADD R1,R1,R2,LSL#8
AND R2,R0,#&FF0000
ADD R1,R1,R2,LSR#8
nachher: R0= (b1b2b3b4)
R1= (b4b3b2b1)
Aber so schlau warst Du auch schon, nehme ich an. Es geht schneller, wenn
man irgendwo die Bitmaske &FFFF deponiert, aber DREI Taktzyklen??
Jared
(Hm, mittlerweile glaube ich auch, da▀ sich so eine Routine nicht in drei
Zyklen bewerkstelligen lΣ▀t... :-) Aber glaubt mir: Ich bin mir fast 100%ig
sicher, da▀ Roger die Routine in vier Zyklen gepackt hat ! Keine Spinnerei !
Wenn ich blo▀ das entsprechende Listing wiederfinden k÷nnte...)
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Kann mir jemand sagen, was das definitive Line-Clipping Verfahren ist?
Bei der "normalen" Schnittpunktberechnung kriege ich in Assembler Overflow-
Probleme, wenn die Linien zu lang werden. Das andere Verfahren, das ich
kenne, funktioniert so:
halbiere Cliplinie
wenn HΣlfte auch Cliplinie dann halbiere wieder
usw.... bis Schnittpunkt mit Grafikfenster gefunden
Angeblich braucht das bei einer Aufl÷sung von 256*256 Pixel maximal
8 Halbierungen, und die Linie ist geclipt.
Was ist besser, was ist schneller ?
Jared
(Es kann natⁿrlich sein, da▀ irgend ein verrⁿckter Informatik-Professor
mittlerweile ein besseres Verfahren entwickelt hat. Aber vermutlich ist
der Cohen-Sutherland-Algorithmus schon ziemlich perfekt. Ach ⁿbrigens,
kannst Du mir mal erklΣren, wie man mit 32 (!) Bit Overflow-Probleme
bekommen kann !??!)
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
TatsΣchlich hat sich da ein illegaler Befehl in die VIDC-Tips von Ace (HL
03/93) eingeschlichen. Natⁿrlich darf man niemals die Never-Kondition in
einem Opcode verwenden, wie das auch ausdrⁿcklich in den RO3 PRM steht.
Anstatt also ömovNv r0,r0ò nach dem Prozessorwechsel zu verwenden, mu▀ man
ömov r0,r0ò oder einen anderen NOP verwenden. Dies deshalb, da ab dem ARM6
die Never-Kontiotion nicht mehr vorgesehen ist und somit sicherlich nicht
mehr die gewⁿnschten Resultate herauskommen wⁿrden. Gut aufgepasst, QArc!
Aber Acero, da▀ Demos nur auf dem ARM2 und ARM3 laufen sollen, war doch
hoffentlich ironisch gemeint? Wenn der nΣchste Archimedes (mit dem ARM710)
herauskommen wird, dann ist das doch genauso ein Archie wie die jetzigen,
wenn auch noch schneller und besser. Aber wieso sollten die alten Demos
dann mⁿde belΣchelt werden? Coole Demos und Spiele legt man doch immer
wieder gerne ein, egal auf welchem Modell. Und ein paar Evergreens gibt es
ja allemal. Als ich mir 1992 den A5000 gekauft habe, mu▀te ich in
irgendeinem englischen Magazin lesen, da▀ der A5000 zum Spielen zu schade
sei. Dabei ist der A5000 doch die optimale Spielemachine (neben anderen
Aufgaben :-)
Au▀erdem ist es ja so, da▀ ein Befehl wie ömovNvò sowieso gar nichts macht,
also ist es kaum tragisch, diesen durch z.B. ömov r0,r0ò zu ersetzen (oder
auch ömov r1,r1ò :-) .. Aber das hast Du ja selber geschrieben.
Programme auf bestimmte Konfigurationen zuzuschneiden, das ist sicherlich
gar nicht ratsam, vor allem, weil man das Optimum auf dem Archimedes durch
ARM-Programmierung herausholt und kaum durch Chip-Orgien. Ich wei▀
natⁿrlich, da▀ Dir VIDC-Tricks viel Spa▀ machen, aber leider lief das Intro
vom HL 03/93 und Dein Programm im HL 04/94 auf dem A5000 ganz und gar
nicht, schnⁿfff! Dabei habe ich sogar einen alles synchronisierenden NEC
3D. Au▀erdem wird der kommende High-End-Archie ca. 4 MB Video RAM fⁿr
seinen VIDC20 haben. Da▀ dann die jetzige Memory-Map komplett umgestellt
wird, dⁿrfte klar sein. Also, niemals davon ausgehen, da▀ der Bildspeicher
bei einer bestimmten Adresse anfΣngt, und niemals Chips direkt beschreiben.
Immer sch÷n SWIs benutzen, um an entsprechende Adressen zu kommen... :-)
- Epics -
(Epics, in einem Punkt stimme ich Dir voll zu: Das Optimum kann man auf dem
Archie keinesfalls durch Chip-Orgien erreichen. Es h÷rt sich bl÷d an, aber
dazu sind die Chips einfach zu gut ! Beim Designen haben die Ingenieure
bei Acorn/ARM Ltd. ⁿberhaupt keine Fehler gemacht, weshalb Effekte wie
beispielsweise Sideborder-Sprites (C64) oder Sync-Scrolling (ST) gar nicht
notwendig sind.
Aber trotzdem denke ich, da▀ es an der Zeit ist, mal ein Demo zu coden, da▀
einen ARM2 vollkommen ausreizt. Ich denke da nicht an Demos wie die Vektor-
demos von Olivier Higelin oder 2DWaves von Jan Vlietinck, sondern eher an
Design-Demos, wie man sie vom Amiga kennt. Stimmst Du mir nicht auch zu,
da▀ die beiden erstgenannten Demos eigentlich gar keine Demos, sondern
vielmehr nur aufbereitete Routinen sind ? Logisch, da▀ solche Routinen
einen schnellen Prozessor wie den ARM3 voraussetzen. Aber fⁿr mich stellen
die (guten) Amiga-Demos eine wesentlich h÷her zu bewertende Programmier-
leistung dar. Routinen wie Texture-Mapping oder Zellular-Automaten sind
zwar nicht ganz einfach zu programmieren, aber es ist doch wesentlich
schwieriger, diese Routinen so zu modifizieren bzw. einzuschrΣnken, da▀
sie auch auf wesentlich schwΣcheren Prozessoren laufen ! Im Klartext:
Die Arbeitsweise grundlegender Routinen kann man sich aus Lehrbⁿchern und
Magazinen nahebringen. Nirgendwo dokumentiert sind aber all die Tricks, die
m÷glich sind, um all diese Routinen sozusagen zu "emulieren"; wenn auf dem
Amiga beispielsweise Texture-Mapping gezeigt wird, haben die verwendeten
Routinen kaum etwas mit echtem TM zu tun, sondern nutzen bestimmte
Besonderheiten aus. Natⁿrlich ist echtes TM wesentlich flexibler, aber
dafⁿr kostet es auch das Zehnfache der Rechenzeit !
Ich hoffe, es ist ein bi▀chen klargeworden, was ich eigentlich sagen m÷chte:
Auch auf einem ARM2 kann man geniale Effekte (mit 50 Hertz) hervorzaubern;
nur leider ist dies noch fast gar nicht gemacht worden. Ich kenne z.B.
keinen einzigen Starwars-Scroller auf dem Archie, der einen kompletten
Bildschirm ausfⁿllt und dabei vollkommen flⁿssig ist. Aber selbst auf dem
C64 gab es eine solche Routine... Man kann jetzt natⁿrlich einfach einen
schnelleren Prozessor fordern. Aber mit ein bi▀chen Anstrengung kriegt man
das auch auf einem ARM2 hin ! Und genauso ist es mit vielen anderen Routinen
auch...)
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Hallo Ikarus und alle FPA-Interessierten,
In der neuen BASIC-Version (die in RISC OS 3.2 oder so Σhnlich) drin sein
wird, hat Roger Wilson auch ARM3- und FPA-Befehle in den Inline-Assembler
des ARM-BASICs integriert. Wann das allerdings herauskommt, wei▀ ich leider
nicht.
Wer nicht so lange warten will, sollte sich mal das toole !ArcTools (von
Moshen Alshayef) genauer anschauen, da wird ein SWI zur Verfⁿgung gestellt,
mit dem man v÷llig einfach und elegant alle ARM3- und FPA-Befehle von BASIC
aus dekodieren lassen kann. Diesen SWI kann man leicht als FN-Makro in
seinen BASIC-Assembler einbinden. ▄brigens ist ArcTools Public Domain,
zumindest die sehr weit verbreitete 0.72 Version.
Der Beschleunigungsfaktor bei praxisnahen Anwendungen auf einem A5000 mit
FPA verglichen mit einem ohne FPA liegt zwischen *7 und *14. Gemessen beim
Raytracen (POVray), was zweifelsohne eine Anwendung ist, die den FPA stark
nutzt. Obwohl sich FP-Operationen beim Raytracen letztlich auch nur mit 50%
zu Buche schlagen, der Rest wird bei anderen Befehlen verbraten. Au▀erdem
soll der Norcroft C-Compiler nicht gerade effiziente FPE-Befehle erzeugen.
Was der Faktor bedeutet, sollte man sich mal klar machen: Wenn ein gutes
Bild (640x480 mit AntiAliasing) mit FPA 12 Stunden ben÷tigt, so wird das
ohne FPA um die 120 Stunden brauchen, also ganze 5 (!) Tage, und das auf
einem A5000.
Der Spitzen-Beschleunigungsfaktor, wenn man nur FP-Funktionen mit und dann
ohne FPA vergleicht, liegt ⁿbrigens bei ⁿber 40. Das habe ich mit einem
Mandelbrot-Programm eines Freundes gemessen, das auch Bildschirm-Ausgaben
machen mu▀. Fazit: Auch wenn der FPA den meisten Spielern und Anwendern von
Textverarbeitungen, Malprogrammen und dergleichen nichts bringt, genial ist
das Teil allemal, eben wieder ein RISC-Chip!
- Epics -
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Hoi Sorcerer! (oder wie grⁿ▀en sich Hexer ???)
Ich hab' mich mal des CLAIMens angenommen. Zuerst sah es ja so aus, als ob
es beim Versuch bleiben wⁿrde. Unter BASIC hatte ich nΣmlich auch stΣndig
exceptions usw. Selbst claimen und sofortiges releasen fⁿhrte zu einem
'bad vector release' !!!???
Letztlich ist dann versuchsweise ein Module entstanden (testweise), welches
beim Init den Vector claimt und beim (RM)Killen wieder released. Keine Pro-
bleme damit. In einer frⁿheren Version hatte ich versuchsweise kein Release
eingebaut, das Module gekillt und die ModuleArea anderweitig vergeben ...
- Fehlermeldungen haben ein sch÷nes Outfit! - will sagen, es mu▀ten ja dann
Exceptions auftreten wegen des CodeVectors, der dann vielleicht schon ein
Sprite war ...
Hier die Quelle:
DIM code% 500
FOR pass%=0 TO 2 STEP 2
P%=code%
[OPT pass%
EQUD 0
EQUD init-code%
EQUD finit-code%
EQUD 0
EQUD title-code%
EQUD help-code%
EQUD 0
EQUD 0
EQUD 0
EQUD 0
EQUD 0
.title
EQUS"ClaimV1D" : EQUB 0 : ALIGN
.help
EQUS"ClaimV1D 0.02 (10 Oct 1993) Claim Test" : EQUB 0 : ALIGN
.init
STMFD R13!,{R14} ;claims vector
MOV R0,#&1D
ADR R1,routine
MOV R2,#0
SWI"OS_Claim"
LDMFD R13!,{PC}
.finit
STMFD R13!,{R14} ;releases vector
MOV R0,#&1D
ADR R1,routine
MOV R2,#0
SWI"OS_Release"
LDMFD R13!,{PC}
.routine
STMFD R13!,{R0} ;safety first
LDR R0,count_of_call ;counts OS_UpCalls
ADD R0,R0,#1
STR R0,count_of_call
LDMFD R13!,{R0} ;dito
MOVS PC,R14
.count_of_call
EQUD 0 ;to be examined by memoryi ...
]
NEXT
OSCLI"SAVE $.ClaimV1D "+STR$~code%+"+"+STR$~(P%-code%)
OSCLI"SETTYPE $.ClaimV1D Module"
Ich hab' das dann mal auch praktisch getestet und ein paar Apps gestartet
bzw. noch einige UpCall situations erzeugt - und ... er|sie|es zΣhlt die
jeweiligen Aufrufe.
Hoffentlich hilft Dir das weiter!
greetings blackICe
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Hoi Acero!
Tauschen: B1 B2 B3 B4 >> B4 B3 B2 B1
Ich hΣtte zwei Varianten zu bieten. Hat bzw. haben beide den Nachteil, da▀
sie 3 Register verbraten (Quelle=Ziel, dummy, Mask). ZeitmΣ▀ig liegen beide
bei vier Takten.
Die Maske (R2) mu▀ vorher mit &00FF00FF initialisiert sein! (Ein Register
wirst Du ja wohl ⁿbrig haben!?)
;R0 Quelle=Ziel
;R1 dummy
:R2 Maske &00FF00FF R0 R1
Var.1: AND R1,R0,R2 ;11 22 33 44 00 22 00 44
EOR R0,R0,R1,ROR#16 ;11 24 33 42 00 22 00 44
EOR R0,R0,R1 ;11 44 33 22 00 22 00 44
MOV R0,R0,ROR#24 ;44 33 22 11 00 22 00 44
Var.2: AND R1,R0,R2 ;11 22 33 44 00 22 00 44
AND R0,R0,R2,LSL#8 ;11 00 33 00 00 22 00 44
ORR R0,R0,R1,ROR#16 ;11 44 33 22 00 22 00 44
MOV R0,R0,ROR#24 ;44 33 22 11 00 22 00 44
Vielleicht nicht sehr elegant aber funktionell! 'was besseres fiel mir auf
die Schnelle nicht ein.
greetings blackICe
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
An alle die mir mal helfen wollen.
Ich suche ein Programm, welches mir erlaubt, die Nachkommastellen der Zahl e
auf, sagen wir 1000-10000 Stellen, genau auszurechnen. Das Programm sollte in
Basic geschrieben werden, damit ich es auch verstehe. (Wenns sein mu▀ auch in
Assembler)
Die Zahl e kann man mit folgender Formel berechnen.
e=(1+(1/n))^n
Wobei n unendlich gro▀ ist. (Simus-Zahl oder so Σhnlich)
AldibΣrman
(AldibΣrman, auf ein Wort: Wozu brauchst Du ein auf 1000-10000 Stellen genaues
e ? Naja, ich bin mal gespannt, ob ein Leser eine L÷sung in Assembler
einreicht...)
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Yo Coder !
Gerade isses uns gelungen, in weniger als 25 (!!!) Assemblerzeilen einen
waschechten Starwars-Scroller zu programmieren ! Leider hat das Ding
momentan noch den Nachteil, mit blo▀en 12 Hertz zu laufen, aber Probleme
sind ja dazu da, um gel÷st zu werden.
Wie auch immer, die 25 Zeilen dⁿrften wohl Weltrekord sein, oder ?
CU on CeBIT '94,
Sorcero/XYMOX Produxions
Acerer/Bytepool Project
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Hi Sorcerer!
Das Problem mit deinem "Claim-Problem" dⁿrfte darin bestehen, da▀ das zu
"claimende" Programm, bzw. deine neue Upcall-Routine, im normalen Application-
Memory liegt. Dieser Speicher wird aber vom OS immer umgebankt, so da▀ nach
dem dem beenden deines Programmes die Upcallroutine aus dem "sichtbaren"
Speicher verschwand. Du mu▀t deine Routine wohl oder ⁿbel in die RMA packen,
also absoluten Speicher belegen, der auch beim Multitasking nicht gemapt wird.
Xcalibur
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Ikarus! Ich schΣtze mal, da▀ du um FN-Makro's nicht herumkommen wirst. Ich
habe mir dazu eine FN geschrieben. Allerdings muss man fⁿr diese Funktion
das ArcTools-Modul geladen haben, da dieses einen speziellen SWI zur Ver-
fⁿgung stellt: SWI "ARCTOOLS_Assemble"! Damit kannst du ARM-, FPU- und
(ARM3-) Co-Prozessorinstruktionen assemblieren. Fuer die Cachecontrolle des
ARM3 gibt es einfache 'Namen', z.B. kannst du Schreiben 'FNAss("CSHR Rd,Cx")'
(Cache Status Read) um das Cache-Register Cx ins ARM-Register Rd zu laden.
Fⁿr Cx kannst du z.B. auch 'Control' nehmen (also 'FNAss("CSHR R0,Control"
liest Cache-Control Register). 'Normalerweise' mⁿsstest du das so schreiben:
'MCR Cp#15,Op#0,R0,C0,C0,0' um das Cache-ID Register nach R0 zu laden...
Im Manual-File von Arctools steht's ausfⁿhrlich beschrieben.
Mein Makro (in meiner Bibliothek) sieht ⁿbrigens so aus:
----------------------------- absprengen -----------------------
DEF FNAss(_special$)
LOCAL ERROR
PRINT "Instruction: ";_special$;"... ";
ON ERROR LOCAL:PRINT "ERROR!!!":REPORT:RESTORE ERROR:ERROR 255,"(ArcTools
error -> see ArcTools manual)"
PROCGetPC
SYS "ARCTOOLS_Assemble",_special$,P% TO !pc%
pc%+=4:P%+=4:O%+=4:PRINT "Ok"
RESTORE ERROR
=FALSE
DEF PROCGetPC
IF Z% AND %100 THEN
pc%=O%
ELSE
pc%=P%
ENDIF
ENDPROC
----------------------------- wegflexen ------------------------
In Z% befinden sich die OPT-Settings. PROCGetPC ben÷tige ich fⁿr einige
Makros, um die Offsets richtig zu berechnen (wichtig wenn mit der Option
'Offsetassemblierung' gearbeitet wird).
Xcalibur
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Whow! Endlich habe ich es geschafft, einen Quicksort von C nach BASIC, und
von da dann nach ARM-Code zu 'portieren' (so nennt man das wohl...). Da
dem einen oder anderen vielleicht grade SO eine Sortierroutine fehlt, hier
mal der Source. Fⁿr 100.0000 Langworte braucht der A5000 ca. 1,6 Sekunden...
--------------------------- schnipp ------------------------------
REM>QuickSort implementierung in ARM Assembler
REM ---[ Rekursiv ]---> geht Quicksort auch schneller?
count%=100000
DIM p% 4000 , t% count%*4
MODE MODE
PROCassemble
FOR i%=0 TO count%
t%!(i%*4)=RND(&7ffffff)
NEXT i%
PRINT "sorting... ";:T%=TIME
REM ARM Register in Beschlag nehmen...
A%=t%:B%=0:C%=count%-1:CALL sort
PRINT (TIME-T%)/100;" Sekunden!"
FOR i%=0 TO 19
PRINT i%;" ";~t%!(i%*4)
WAIT
NEXT i%
END
DEF PROCassemble
FOR pass%=0 TO 2 STEP 2
P%=p%
[OPT pass%
; R0 = tabelle%
; R1 = left
; R2 = right
; R3 = l
; R4 = r
; sort ist der Einsprung von BASIC, sortx ist der
; 'rekursive' Einsprung...
.sort STMFD R13!,{R1-R4} ; REGs merken
.sortx STMFD R13!,{R14} ; LINK REG save
MOV R3,R1 ; l=left
MOV R4,R2 ; r=right
ADD R5,R3,R4 ; mid=(l+r) DIV 2
MOV R5,R5,LSR #1 ; -"-
LDR R5,[R0,R5,LSL #2] ; temp
.sloop ; REPEAT
; WHILE f(l)<temp l=l+1 WEND
.slpleft LDR R6,[R0,R3,LSL #2]
CMPs R6,R5
ADDLT R3,R3,#1
BLT slpleft
; WHILE temp<f(r) r=r-1 WEND
.slpright LDR R6,[R0,R4,LSL #2]
CMPs R5,R6
SUBLT R4,R4,#1
BLT slpright
; IF l <= r THEN SWAP f(l),f(r)
CMPs R3,R4
LDRLE R6,[R0,R3,LSL #2]
LDRLE R7,[R0,R4,LSL #2]
STRLE R7,[R0,R3,LSL #2]
STRLE R6,[R0,R4,LSL #2]
ADDLE R3,R3,#1
SUBLE R4,R4,#1
; UNTIL r < l
CMPs R4,R3
BGE sloop
; IF left < r THEN sort(left,r)
CMPs R1,R4
STMLTFD R13!,{R1-R4} ; alte REGs merken
MOVLT R2,R4 ; right = r
BLLT sortx
; IF l < right THEN sort(l,right)
CMPs R3,R2
STMLTFD R13!,{R1-R4}
MOVLT R1,R3 ; left = l
BLLT sortx
LDMFD R13!,{R14} ; alter PC nach R14
LDMFD R13!,{R1-R4} ; alte REGs
MOVS PC,R14 ; RETURN/END
]
NEXT
ENDPROC
--------------------------- schnapp ------------------------------
Und wech...
\/
/\CALIBUR
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Ist ja schon eindrucksvoll, die 3D-Grafik aus Zarch, Lander, Aldebaran und
demnΣchst Arcturus. Nur, wieso wird keine 'richtige' 3D-Grafik erzeugt,
also das man den Hintergrund dreht und immer in die Flug- bzw. Fahrrichtung
schaut? So schwer kann das ja wohl nicht sein (man arbeitet daran... Hehe :-)
Xcalibur
(Hey Xcalibur, die Sache, an der Du gerade arbeitest, sieht aber wirklich
schon vielversprechend aus ! Zuerst dachte ich, da▀ Du da eine waschechte
Gouraud-Routine eingebaut hΣttest. Dann ist mir aber aufgefallen, da▀ es
sich "nur" um normale Vektorgrafik mit *extrem* vielen Polygonen handelte..)
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Sorcerer: Reintheoretisch sollte Deine UpCallV-Routine korrekt arbeiten, tut
sie aber nicht. Vielleicht liegts daran, da▀ das OS darauf besteht, da▀ es die
richtigen Rⁿckmeldungen kriegt (und nicht KEINE). Also spring einfach am Ende
Deiner Routine in die Originalroutine!
QArc
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Acero: Rom ist gro▀, das dⁿrftest Du ja wohl wissen! In meinem Archie ist Rom
jedenfalls 2 MB gro▀. Aber irgendwo hab ich mal was davon gelesen, da▀ man aus
einem Modul in ein Basicprogramm springen kann (und wieder zurⁿck!). Sollte ich
es irgendwann zufΣlligerweise wieder finden, dann melde ich mich bei Dir.
QArc
(Das hilft mir jetzt weiter, wirklich ! QARC, ICH KANN DIR NUR RATEN: FINDE
DIESE TEXTSTELLE ! ANSONSTEN...)
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Acero: Wⁿrdest Du Dich etwa freuen, wenn gute Demos nur fⁿr den Arm3
rauskommen? Glaub ich nicht, Du k÷nntest sie Dir ja garnicht anschauen. Und um
richtig fies zu sein, wⁿrd ich auch abfragen ob die Maschine auch nen Arm3 hat,
wenn nicht wird erst garnichts gemacht! Aber zum Glⁿck schalten die meisten
Demos nur in einen speziellen Arm3-Modus um ! Glⁿck fⁿr Dich!
QArc
(Ich wⁿrde mich schon freuen, wenn ⁿberhaupt mal gute Demos herauskΣmen :-)..
Aber soweit ich wei▀, gibt es bei fast keinem Demo einen speziellen
ARM3-Modus. Die Grafikausgabe wird eventuell schneller, das ist aber auch
schon alles.)
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Ikarus wozu brauchst Du eigentlich die FPA Befehle? Irgendwie find ich die FPA
nicht so toll wie erwartet, sie kann doch eh nur Addieren, Subtrahieren,
Mutliplizieren und Dividieren. Wichtiger wΣre doch Sin und Wurzeln!!!
QArc
(Nee, die neue FPA ist wirklich nur gro▀er Schwachsinn. POVray, der neue
Mega-Raytracer, braucht mit FPA nur 10% der Zeit, die der ohne FPA brΣuchte.
Und dieser minimale Zeitgewinn ist doch nun wirklich das Geld fⁿr die
bl÷de FPA wert !)
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ