... Ich benutze den Explorer...
Da geht so was auch:
http://praxistipps.chip.de/internet-explorer-gif-bilder-deaktivieren_15640
Danke an
@mfro . Erstmal hilft die ESC-Taste (aus og. praxistipps).
Kann der Firefox parallel installiert werden, oder muß ich zuerst den Explorer entfernen?
.......
Man kann SuperExec (XBIOS_38) grundsätzlich auch für Prozeduren mit Parametern verwenden. Falls es noch interessiert, kann ich ein Bsp. für M2(TDI) zeigen, mit C kenne ich mich nicht aus. Alles nur eine Frage des Bindings.
Auch wenn das Problem mittlerweile gelöst ist, würde mich das Beispiel (auch wenn's in Modula 2 ist) interessieren.
Hatha das versprochene Bsp. (hat ebbs gedauert, weil ich aus den vorhandenen ein zur Demo geeignetes heraussuchent & didaktisch aufbereiten mußte):
(* IMPLEMENTATION *) MODULE SUP_DEMO;
(* ½ 2016 Ari.Tao * 15.08.16 TDI-M2 .
Two examples how to use XBIOS_38 (SuperExec) with parameters:
SupExec (long out par. only)
PeekL (long in & long out par.)
*)(*$T-,$S-,$A+ mini *)
IMPORT GT;
FROM SYSTEM
IMPORT ADR,ADDRESS, WORD, SETREG,CODE;
CONST RTS = 4E75H;
UNLK = 4E5EH;
TRAP = 4E40H;
XTRAP = TRAP+14; (* XBIOS *)
PUSHW = 3F3CH; (* MOVE.W #*,-(A7) ; Word-Konstante.*)
PUSHV = 2F2EH; (* MOVE.L s(A6),-(A7); Long- v VAR-Parameter.*)
RETL = 2D40H; (* MOVE.L D0,d(A6) ; Long-Ergebnis. *)
CONST SUPER = 38; D0 = 0; PM = 8;
TYPE SuperPar = RECORD Op: CARDINAL; Code: PROC END;
TYPE HANDLE = POINTER TO ADDRESS;
(* Beispiel_1: *)
PROCEDURE SuperExec (Code: PROC);
BEGIN CODE (PUSHV,PM, PUSHW,SUPER, XTRAP) END SuperExec;
PROCEDURE SupExec (Code: PROC): (*D0 via Code:*) LONGINT;
BEGIN CODE (PUSHV,PM, PUSHW,SUPER, XTRAP, RETL,PM+4, UNLK,RTS) END SupExec;
(* Beispiel_2: *)
PROCEDURE peekL; VAR h: HANDLE; p: POINTER TO RECORD q,z: HANDLE END;(*$S-*)
BEGIN CODE (RETL+14,-4); p := h^+PM; p^.z := p^.q^ END peekL; (*$S=*)
PROCEDURE PeekL(a: ADDRESS): (*Val:*) ADDRESS; VAR P: SuperPar;
BEGIN P.Op := SUPER; P.Code := peekL; CODE (XTRAP, UNLK,RTS) END PeekL;
(* Test: *)
PROCEDURE TestCode; (*$S-*) BEGIN SETREG (D0, 13H) END TestCode; (*$S=*)
CONST MEMTOP = 436H;
BEGIN (* .TOS *)
GT.wHexL (SupExec (TestCode), 10);
GT.wHexL (PeekL (MEMTOP), 10);
END SUP_DEMO .
Hinweise:
1) Das Phragma $S- unterdrückt den StackTest des TDI-Compilers.
2) Selbstverständlich sind die Bindings Compiler-abhängig, also nur bedingt portabel.
3) Die Idee stammt aus einem Zeitschriften-Artikel. Leider ging mir die Quelle verloren.
4) Das fertig kompilierte Prg. -> Anhang (ziemlich uninteressant, nur zur Vollständigkeit)
.......
Ad Benchmarking:
Deshalb bevorzuge ich echte Applikationen als Benchmark.
Klaro, dacour.
Es liegt mir fern, den CoreMark in Zweifel zu ziehen. Aber der dient doch in erster Linie dazu, Prozessoren zu vergleichen? Beim RAM-Test spielt der Bus eine wesentliche Rolle.
Ist der CoreMark (nomen est omen?) dafür denn auch zuständig? Wenn nicht, dann ist
Fakt ist: Selbst mit -O3 (oder -Os) läuft mein RAM-Test YAART schneller, wenn ich ihn mit Pure C compiliere.
überhaupt kein Wunder. Der gcc wurde vermutlich dem CoreMark angepaßt, aber PureC dem Dhrystone oä.
Übrigens wird im BegleitText zum Dhrystone die von Dir
@czietz angesprochene Optimierungs-Problematik durchaus berücksichtigt. Deshalb halte ich imho diesen mittelalterlichen Test für unsere OldTimer immer noch für gut geeignet. An ein paar wenigen Dhrystones Unterschied würde ich keine Bewertung festmachen, aber bei einem Faktor von ca. 2 gibt es am Dhrystone wohl nix herumzukritteln. Man kann jedenfalls gut sehen, daß der TT mehr Leistung hat als ein F30 mit 32MHz oder auch die groben Unterschiede in verschiedenen Compiler-Designs oder auch den Einfluß des BusTakts oder auch, wieviel Performance eine höhere Grafik-Auflösung im Falcon kostet; und das ist alles sehr plausibel.
.......
@czietz , wo bitte genau finde ich im Hatari-Universum das Stückchen Code, das für die ´Zyklen´ zuständig ist?
Eine jede Wissenschaft hat ein sog. Hauptproblem. Dasjenige der Informatik ist nicht etwa, Information zu erzeugen, sondern, sie (wieder-)zufinden!