Beiträge: 666
Themen: 77
Registriert seit: Oct 2013
Bewertung:
0
Hallo Leute
Da ich mich zwecks mangelnder Hardware für Os4 nun mehr mit MorphOs beschäftige, ist mir aufgefallen das Ab3
extrem langsam kompiliert. Ich kann mich erinnern das wir das Thema vor vielen Jahren schonmal hatten, aber ich weis nicht mehr
wie die Lösung war (evtl. weis Bernd da noch was drüber ?)
Jetzt werden evtl. viele sagen das es doch "schnell" geht mit den beiliegenden Sourcen (dbl usw) aber PfP (ziemlich groß) oder Copakabana (recht klein)
dauern ewig !!! Unter OS4 geht das in Sekunden, unter MorphOs dauert das viele Minuten...
Wer also sachdienliche Hinweise beisteuern kann immer her damit....
Beiträge: 396
Themen: 8
Registriert seit: Sep 2013
Bewertung:
0
Copakabana ist sehr gross wenn du ntui mit rein kompilierst.
Das hatte irgendwas mit dem CPU Cache zu tun. Ich dachte Bernd hätte das Problem beseitigt.
Beiträge: 666
Themen: 77
Registriert seit: Oct 2013
Bewertung:
0
Nein hat er scheinbar dann nicht...
Na ja, evtl. schaut er ja hier mal wieder vorbei und hilft.
Beiträge: 67
Themen: 5
Registriert seit: Jun 2014
Bewertung:
0
habe mal wieder geschaut
Ich habe da einen Vorschlag gemacht, es hat auch funktioniert, war auch mit winuae schneller. müsst halt getestet werden, ob es vielleicht doch manchmal fehlschlägt. der code ist irgendwo im alten forum. müsste man mit suche nach clearcache oder cacheclear finden.
Es gibt auch code der nur mit 040 CPU geht und schon in blitz drin war. auf winuae ist der 40 code aber nun drin. müsste dort also auch laufen. kannst mal in MOS testen ob das geht. manche stellen sind 2* deaktiviert.
CPUSHL Dc,(A1)
cinvl ic,(a1)
kennt der blitz assembler aber nicht. alle stellen musste dann so ändern
dc.w $f469 ;CPUSHL Dc,(A1)
dc.w $f489 ;cinvl ic,(a1)
das
; BRA.S 'l10
das ist der code, der je nach CPU flag(wenn 040/060 CPU) verzweigt.
musste dann je nachdem mit bne oder beq ersetzen. vielleicht im original blitz source schauen wie es war
;Aclearcache2: MOVEM.l D0-D1/A0-A1/A6,-(A7)
; MOVEA.l $4,A6
; MOVE $128(A6),D0
; BTST #3,D0
; BRA.S 'l10
;; MOVE.l a0,-(a7)
;; JSR -$96(A6)
;; JSR -$78(A6)
;; MOVEA.L (A7)+,A1
;; CPUSHL Dc,(A1)
;; cinvl ic,(a1)
;; ADDA #16,a1
;; CPUSHL Dc,(A1)
;; cinvl ic,(a1)
;; ADDA #16,a1
;; CPUSHL Dc,(A1)
;; cinvl ic,(a1)
;; ADDA #16,a1
;; CPUSHL Dc,(A1)
;; cinvl ic,(a1)
;; ADDA #16,a1
;; CPUSHL Dc,(A1)
;; cinvl ic,(a1)
;; ADDA #16,a1
;; CPUSHL Dc,(A1)
;; cinvl ic,(a1)
;; JSR -$7E(A6)
;; JSR -$9C(A6)
;; BRA 'l20
;'l10
; MOVEA.l $4,A6
;CacheClearU SET -$27C
; JSR CacheClearU(A6)
;'l20 MOVEM.l (A7)+,D0-D1/A0-A1/A6
; RTS
Beiträge: 67
Themen: 5
Registriert seit: Jun 2014
Bewertung:
0
und haste schon gefunden ?
auf dem original amiga bringt es nicht viel. wird auf jedenfall nicht langsamer. Der code checkt, ob die end Adresse des vorigen erzeugten codes(auch formeloptimierung) kleiner ist als die adresse des codes der für die Formeloptimierung erzeugt wird. ist das der Fall, muss der Cache nicht gelöscht werden. denn dann kann der code ja nicht im JIT cache stehen. dadurch wurde es unter MOS schon schnell genug.
Beiträge: 666
Themen: 77
Registriert seit: Oct 2013
Bewertung:
0
Ja hab die Stelle gefunden, habs auch so aktiviert und ergänzt wie von dir vorgeschlagen.
Allerdings mußte ich den Label CacheClear ändern, das label wurde wahrscheinlich umbenannt in _CacheClear. Ob das noch das selbe macht weis ich nicht, hab noch nicht geschaut.
Wenn Ntui im Spiel ist, kompiliert es aber auch nicht schneller.
Das Bra.S habe ich mit bne ersetzt. Sollte ich evtl beq versuchen ? Hätte das vorteile ?
Beiträge: 666
Themen: 77
Registriert seit: Oct 2013
Bewertung:
0
@tomsmart1
Hast du denn die Änderungen auch mal gemacht und irgendwas festgestellt ?
