amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Amiga, AmigaOS 4 > Amiblitz 3 [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

03.11.2016, 20:52 Uhr

nixweiss
Posts: 142
Nutzer
Hallo zusammen,

Ich würde gern den Blitz Kurs in der Amiga
Future mitmachen, erhalte jedoch nach dem starten
Des Compiler folgende Fehlermeldung:


The VBR is currently located at me more address 0!
It is recommended to move the VBR to Fast-Ram!
Use a tool like MPC, VBRControl etc.,
The Debugger might cause enforcer hits now.

Das ganze läuft bei mir unter Amikit.

Viele Grüße

Nixweiss

[ - Antworten - Zitieren - Direktlink - ]

04.11.2016, 08:21 Uhr

dandy
Posts: 2552
Nutzer
Zitat:
Original von nixweiss:

Hallo zusammen,


Moin, moin!

Zitat:
Original von nixweiss:

Ich würde gern den Blitz Kurs in der Amiga
Future mitmachen, erhalte jedoch nach dem starten
Des Compiler folgende Fehlermeldung:


"The VBR is currently located at me more address 0!
It is recommended to move the VBR to Fast-Ram!
Use a tool like MPC, VBRControl etc.,
The Debugger might cause enforcer hits now."

Das ganze läuft bei mir unter Amikit.
...


Hmmm - um den Sinn der Fehlermeldung besser verstehen zu können, wäre es unter Umständen hilfreich zu wissen, was für eine Hardware Du benutzt.

D.h., wieviel Chipram, wieviel Ranger Mem und wieviel Fastram hat Deine Kiste?

Es geht hier offenbar darum, etwas ins Fastram zu verschieben.
Im Readme zum in der Fehlermeldung erwähnten "VBRControl" steht z.B.:
"VBRControl allows to move the processor vector table to fastmem. This increases the system speed a little."

Mit "Blitz Kurs" meinst Du Blitz Basic?

Erstmal keine Ahnung, was "VBR" hier in diesem Zusammenhang bedeutet.
Normalerweise bedeutet "VBR" eigentlich "Variable Bit Rate" - hier scheint es irgendwas mit einer "Prozessor Vektor Tabelle" zu tun zu haben, die offenbar im Fastram besser aufgehoben wäre, sich z.Zt. aber irgendwo anders befindet ("located at me more address 0").

Wobei mir auch nicht klar ist, was in diesem Zusammenhang "me more address 0" heißen soll. Ich kenne Speicheradressen nur im HEX Format...
--
Ciao,

Dandy

Wenn es jemandem Spaß macht, zu Marschmusik in Reih` und Glied zu marschieren, so verachte ich ihn schon.
Er hat sein Großhirn nur aus Versehen bekommen - bei ihm hätte auch schon das Rückenmark gereicht!
(Albert Einstein)

[ - Antworten - Zitieren - Direktlink - ]

04.11.2016, 14:52 Uhr

cha05e90
Posts: 157
Nutzer
@dandy:

VBR = Vector Base Register
--
X1000|II/G4|440ep|2000/060|2000/040|1000

[ - Antworten - Zitieren - Direktlink - ]

06.11.2016, 07:40 Uhr

Akiko
Posts: 31
Nutzer
Das VBR ist ein Register, dass auf die Interrupt Service Routines zeigt. In der M68k Architektur werden sie Exception Vectors genannt und sind 256 32Bit Adressen, also genau 1 KiB. Diese befinden sich per Default immer an der Adresse 0 im Speicher, also im Fall des Amigas im Chip-Ram.

Ab dem 68010 hat die CPU ein eigenes Register für die Startadresse dieser Vectorentabelle. Dies ist das VBR und kann ab dem 68010 auch woanders hinzeigen, zum Beispiel ins Fast-Ram, was wesentlich schneller ist.

Es gibt verschiedene Programme, die 1 KiB im Fast-Ram reservieren, die Tabelle dorthin kopieren und anschließend den VBR auf die neue Tabelle zeigen lassen. Da wäre zum Beispiel das vbrmov aus dem Aminet.
--
A4000D/060 @66MHz (original!)/604e @233MHz/CyberVisionPPC/PicassoIV + alle Module/128MB FASTRAM/38GB UW-SCSI2/Ariadne 1/GoldenGate 486SLC

[ - Antworten - Zitieren - Direktlink - ]

06.11.2016, 22:21 Uhr

nixweiss
Posts: 142
Nutzer
Danke für Eure Tipps.
Ich hab es mit VBR Control gelöst und
bekomme keine Fehlermeldung mehr.

Viele Grüße
NW

[ - Antworten - Zitieren - Direktlink - ]

08.11.2016, 08:06 Uhr

dandy
Posts: 2552
Nutzer
Zitat:
Original von cha05e90:
@dandy:

VBR = Vector Base Register
--
X1000|II/G4|440ep|2000/060|2000/040|1000


Suchergebnisse für "VBR" bei Google

verschidene Bedeutungen von "VBR" bei Wikipedia
"Vector Base Register" ist NICHT dabei...

Wie ich die kommentarlose Verwendung von Abkürzungen mit nicht dem Standard entsprechenden Bedeutungen doch hasse...
:nuke:


--
Ciao,

Dandy

Wenn es jemandem Spaß macht, zu Marschmusik in Reih` und Glied zu marschieren, so verachte ich ihn schon.
Er hat sein Großhirn nur aus Versehen bekommen - bei ihm hätte auch schon das Rückenmark gereicht!
(Albert Einstein)

[ - Antworten - Zitieren - Direktlink - ]

08.11.2016, 10:26 Uhr

Neodym
Posts: 485
Nutzer
Naja, der Amiga war ja schon so gut wie tot, bevor die Wikipedia überhaupt ins Leben kam. Im Amiga-Programmiererumfeld dürfte die Abkürzung geläufig sein.

Wenn überhaupt, beschwer' Dich darüber, daß noch niemand diese Abkürzung bei Wikipedia eingetragen hat. Oder noch besser: Trag' sie gleich selbst dort ein.

[ - Antworten - Zitieren - Direktlink - ]

08.11.2016, 11:48 Uhr

analogkid
Posts: 2383
Nutzer
Das VBR lässt sich übrigens auch mit dem MMULib Paket von Thor verschieben. Es wird dabei die MMU (falls vorhanden) benutzt, was den Vorteil hat, dass die Kompatiblität zu alter Software gewahrt wird (dank der MMU bleibt das VBR für diese Programme bei $0)

[ - Antworten - Zitieren - Direktlink - ]

08.11.2016, 12:28 Uhr

dandy
Posts: 2552
Nutzer
Zitat:
Original von Neodym:

...
Im Amiga-Programmiererumfeld dürfte die Abkürzung geläufig sein.
...


Sorry, aber ich bin weder Amiga-Programmierer, noch deren Umfeld...
;(
--
Ciao,

Dandy

Wenn es jemandem Spaß macht, zu Marschmusik in Reih` und Glied zu marschieren, so verachte ich ihn schon.
Er hat sein Großhirn nur aus Versehen bekommen - bei ihm hätte auch schon das Rückenmark gereicht!
(Albert Einstein)

[ - Antworten - Zitieren - Direktlink - ]

08.11.2016, 12:39 Uhr

dandy
Posts: 2552
Nutzer
Zitat:
Original von Akiko:

Das VBR ist ein Register, dass auf die Interrupt Service Routines zeigt. In der M68k Architektur werden sie Exception Vectors genannt und sind 256 32Bit Adressen, also genau 1 KiB. Diese befinden sich per Default immer an der Adresse 0 im Speicher, also im Fall des Amigas im Chip-Ram.

Ab dem 68010 hat die CPU ein eigenes Register für die Startadresse dieser Vectorentabelle. Dies ist das VBR und kann ab dem 68010 auch woanders hinzeigen, zum Beispiel ins Fast-Ram, was wesentlich schneller ist.

Es gibt verschiedene Programme, die 1 KiB im Fast-Ram reservieren, die Tabelle dorthin kopieren und anschließend den VBR auf die neue Tabelle zeigen lassen. Da wäre zum Beispiel das vbrmov aus dem Aminet.


Danke für diese detaillierte Erklärung!

Zitat:
Original von Akiko:

Dies ist das VBR und kann ab dem 68010 auch woanders hinzeigen, zum Beispiel ins Fast-Ram, was wesentlich schneller ist.


D.h., irgendetwas müsste dann bei dem 68060 auf meiner CSPPC auch schneller werden? Immerhin ist es 64 Bit breites 60 oder 70 ns schnelles RAM...

Aber WAS GENAU wird dadurch schneller?
Die CPU-Taktfrequenz wird es wohl nicht sein...
--
Ciao,

Dandy

Wenn es jemandem Spaß macht, zu Marschmusik in Reih` und Glied zu marschieren, so verachte ich ihn schon.
Er hat sein Großhirn nur aus Versehen bekommen - bei ihm hätte auch schon das Rückenmark gereicht!
(Albert Einstein)

[ - Antworten - Zitieren - Direktlink - ]

09.11.2016, 05:31 Uhr

njnnjn
Posts: 148
Nutzer
ist das wirklich schon 64bit speicher? hätte jetzt gedacht es wären 32... cool :D
ich denke durch das verschieben in den fastram, kann die Software schneller eingelesen werden und dadurch läuft es dann flüssiger. ist aber nur eine Vermutung die ich beim lesen dieses tread jetzt erstellt habe.
lg

[ - Antworten - Zitieren - Direktlink - ]

09.11.2016, 06:14 Uhr

Akiko
Posts: 31
Nutzer
Zitat:
Original von dandy:
D.h., irgendetwas müsste dann bei dem 68060 auf meiner CSPPC auch schneller werden? Immerhin ist es 64 Bit breites 60 oder 70 ns schnelles RAM...

Aber WAS GENAU wird dadurch schneller?
Die CPU-Taktfrequenz wird es wohl nicht sein...


Es kommt ganz drauf an, ob der PPC aktiv ist oder nicht. Die PPC Karten sind eigentlich ziemlich "fucked-up", weil sich da der M68k und der PPC den Speicher teilen. Es kann immer nur einer auf den Speicher zugreifen. Bevor sie das machen, wird aus Cache-Coherence-Gründen (PCC und M68k müssen in ihren Caches die gleichen Daten haben - wenn der Cache den gleichen RAM Bereich abdeckt) einen echten Context-Switch durchführen, also alle Daten in den Caches und Registern in den RAM zurück schreiben. Dies bremst das System ziemlich stark aus. Und wenn man bedenkt, dass im Hintergrund immer ein PPC-Kernel läuft, dürfte das recht häufig passieren.

Im Fall eines reinen M68k Amigas wird es schneller, weil Fast-RAM einzig allein für die CPU da ist. Dieser RAM ist in der Regel mit der MHz Zahl der CPU angebunden. Der Chip-RAM dagegen wird zwischen den Custom Chips und der CPU geteilt. Wenn man sich vorstellt, dass in Takten auf das Chip-RAM zugegriffen wird (also 1 2 3 4 5 ...), werden alle ungeraden Zugriffe den Custom Chips gegeben und alle geraden Zugriffe der CPU. Allein dadurch ist die Chip-RAM Geschwindigkeit schon mal nur halb so schnell für die CPU. Dann kommt hinzu, dass das Chip-RAM mit der Bus Geschwindigkeit betrieben wird, dass sind diese ominösen 28,xx MHz, die man als Quartz auch auf den Mainboards sehen kann. Und zum Schluss haben OCS/ECS Systeme nur einen 16 Bit breiten Bus und AGA Systeme einen 32 Bit breiten Bus. Zudem können AGA Systeme kaskadierte Zugriffe, die das Chip-RAM etwa 4x so schnell wie bei einem OCS/ECS System machen, aber es ist noch immer deutlich langsamer als Fast-RAM.

Hmm, ob das Verschieben des VBR mit der MMU genauso effizient ist, glaube ich nicht. Gerade bei dem 68030 bekommt der RAM Zugriff, der durch die MMU läuft noch ein paar Taktzyklen Latenz dazu. Die MMU im 68030 ist nicht so hoch integiert wie im 040/060, vor allem weil letztere einen korrekte Harvard Architektur MMU haben (es sind zwei, einmal für Daten und einmal für Instruktionen).
--
A4000D/060 @66MHz (unmodifiziert)/604e @233MHz/CyberVisionPPC/PicassoIV + alle Module/128MB FASTRAM/300GB SCA2 -> UW-SCSI2/Ariadne 1/GoldenGate 486SLC

[ - Antworten - Zitieren - Direktlink - ]

09.11.2016, 09:17 Uhr

dandy
Posts: 2552
Nutzer
@ njnnjn:

Zitat:
Original von njnnjn:

ist das wirklich schon 64bit speicher? hätte jetzt gedacht es wären 32... cool :D
...


Guckst Du hier:

Zitat:
Original von CyberStormPPC:

...
Speicher
...
- mögliche Speicherkonfigurationen: max. 128 MB
- 64-Bit-RAM-Zugriff, interleaved
...


und hier:

Zitat:
Original von CyberVision PPC:

...
- 25 MHz local PCI bus
- 8 MB 64 bit wide SGRAM
...


Frage mich grad, ob es denn möglich sein könnte, einen kleinen Hardwarezusatz zu machen mit - sagen wir mal - 128 mB 64 Bit breitem SGRAM und dieses über den „25 mHz local PCI bus“ (und dem passenden Stecker zur CSPPC) der CSPPC/dem AmigaOS zur Verfügung zu stellen?

RAM-Erweiterungen wie die ZorRAM kann man ja nur als SWAP Memory nutzen - vielleicht könnte man auf diese Weise mehr RAM für Programme (Arbeitsspeicher) wie beim PC verfügbar machen (Beim PC nutzt man doch mittlerweile auch GPU und VRAM für die Ausführung von Programmen)? Es wird ja immer von der schnellen Anbindung der CVPPC and die CSPPC über diesen "local PCI bus" geschwärmt - das müsste man doch irgendwie nutzen können - oder?

--
Ciao,

Dandy

Wenn es jemandem Spaß macht, zu Marschmusik in Reih` und Glied zu marschieren, so verachte ich ihn schon.
Er hat sein Großhirn nur aus Versehen bekommen - bei ihm hätte auch schon das Rückenmark gereicht!
(Albert Einstein)

EDIT:
Tappfühler...

[ Dieser Beitrag wurde von dandy am 09.11.2016 um 09:52 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

09.11.2016, 09:45 Uhr

dandy
Posts: 2552
Nutzer
Zitat:
Original von Akiko:

Zitat:
Original von dandy:

D.h., irgendetwas müsste dann bei dem 68060 auf meiner CSPPC auch schneller werden? Immerhin ist es 64 Bit breites 60 oder 70 ns schnelles RAM...

Aber WAS GENAU wird dadurch schneller?
Die CPU-Taktfrequenz wird es wohl nicht sein...


Es kommt ganz drauf an, ob der PPC aktiv ist oder nicht.
...
Dies bremst das System ziemlich stark aus. Und wenn man bedenkt, dass im Hintergrund immer ein PPC-Kernel läuft, dürfte das recht häufig passieren.
...


Das bedeutet also, dass wegen der Kontextswitcherei OS3.9/WarpOS16.1 auf meinem System "mit angezogener Handbremse" läuft, auch wenn der PPC von laufenden Anwendungen gar nicht angesprochen wird?

Unter OS 4.x classic dürfte dann diese Handbremse "gelöst" sein, da ja da der 68060 nur beim Booten benötigt wird - oder?

Zitat:
Original von Akiko:

Die PPC Karten sind eigentlich ziemlich "fucked-up",
...


Naja, dafür laufen sie eigentlich erstaunlich gut...


Zitat:
Original von Akiko:

...
Im Fall eines reinen M68k Amigas wird es schneller, weil Fast-RAM einzig allein für die CPU da ist. Dieser RAM ist in der Regel mit der MHz Zahl der CPU angebunden.
vO.K. ...


Verstehe...

Zitat:
Original von Akiko:

Der Chip-RAM dagegen wird zwischen den Custom Chips und der CPU geteilt. Wenn man sich vorstellt, dass in Takten auf das Chip-RAM zugegriffen wird (also 1 2 3 4 5 ...), werden alle ungeraden Zugriffe den Custom Chips gegeben und alle geraden Zugriffe der CPU. Allein dadurch ist die Chip-RAM Geschwindigkeit schon mal nur halb so schnell für die CPU. Dann kommt hinzu, dass das Chip-RAM mit der Bus Geschwindigkeit betrieben wird, dass sind diese ominösen 28,xx MHz, die man als Quartz auch auf den Mainboards sehen kann. Und zum Schluss haben OCS/ECS Systeme nur einen 16 Bit breiten Bus und AGA Systeme einen 32 Bit breiten Bus. Zudem können AGA Systeme kaskadierte Zugriffe, die das Chip-RAM etwa 4x so schnell wie bei einem OCS/ECS System machen, aber es ist noch immer deutlich langsamer als Fast-RAM.


Das sollte ja - wenn ich Dich richtig verstehe - bei meinem System nicht zutreffen, da ich ja ausschließlich über die PCI Grafikkarte gehe.

Und Sound läuft über die PCI Terratec 512i digital - da sollte das Chip-RAM ebenfalls außen vor bleiben...

Hab' ich noch was vergessen in Sachen Chip-RAM?

Zitat:
Original von Akiko:

Hmm, ob das Verschieben des VBR mit der MMU genauso effizient ist, glaube ich nicht. Gerade bei dem 68030 bekommt der RAM Zugriff, der durch die MMU läuft noch ein paar Taktzyklen Latenz dazu. Die MMU im 68030 ist nicht so hoch integiert wie im 040/060, vor allem weil letztere einen korrekte Harvard Architektur MMU haben (es sind zwei, einmal für Daten und einmal für Instruktionen).
...


O.K. dann würde das Verschieben auf meinem System wohl kaum etwas bringen...

--
Ciao,

Dandy

Wenn es jemandem Spaß macht, zu Marschmusik in Reih` und Glied zu marschieren, so verachte ich ihn schon.
Er hat sein Großhirn nur aus Versehen bekommen - bei ihm hätte auch schon das Rückenmark gereicht!
(Albert Einstein)

EDIT:
Hey - sehe grad, dass Du "stolzer Besitzer" einer "Vortex GoldenGate 486SLC" bist - was fängt man denn heutzutage noch damit an?
Die aktuellen Windows-Versionen werden ja wohl darauf genau so wenig laufen, wie auf meiner "Vortex AtOnce286 classic"...

[ Dieser Beitrag wurde von dandy am 09.11.2016 um 10:08 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

09.11.2016, 14:23 Uhr

o1i
Posts: 36
Nutzer
Zitat:
Original von dandy:

Aber WAS GENAU wird dadurch schneller?
Die CPU-Taktfrequenz wird es wohl nicht sein...


Interrupts werden dadurch etwas schneller (aufgerufen).

Beim Amiga werden sowohl von der Software als auch von der Hardware durchaus oft "interrupts" generiert. D.h. das aktuell laufende Programm wird unterbrochen und ein anderes (kleines) "Programm" ausgefuehrt. Welches Programm das sein soll, steht in der Tabelle, auf die das VBR zeigt. Fuer jeden Interrupt muss also eine Adresse aus dieser Tabelle ausgelesen werden.

Ohne VBR liegt diese Tabelle im Chip-RAM, wird also langsamer ausgelesen als aus dem Fast-RAM. Allerdings ist das nur das Lesen *einer* einzelnen Adresse, das beschleunigt wird, allerdings pro Interrupt und das sind viele pro Sekunde (Multitasking, Grafiksynchronisation, Mausbewegung, Timer, etc.).

Der Aufruf des Interrupts wird schneller, nicht aber die Ausfuehrung an sich.

Mag sein, dass ein paar Details nicht mehr genau in meiner Erinnerung sind, ist vermutlich 20 Jahre her, dass ich mich mal damit beschaeftigt habe ;-). Aber grundsaetzlich sollte es stimmen.

[ - Antworten - Zitieren - Direktlink - ]

09.11.2016, 15:06 Uhr

Akiko
Posts: 31
Nutzer
Zitat:
Original von dandy:

Das bedeutet also, dass wegen der Kontextswitcherei OS3.9/WarpOS16.1 auf meinem System "mit angezogener Handbremse" läuft, auch wenn der PPC von laufenden Anwendungen gar nicht angesprochen wird?


Bei den ersten Version von PowerUP war es richtig übel, weswegen auch WarpUP als Alternative entwickelt wurde. Bei aktuellen Version sollte das Ausbremsen (bei eine PPC der gerade nichts macht) bei etwa 1-2% liegen. Man müsste an der Stelle mal eine CyberStorm MK3 und einen CyberStorm PCC mit gleichen RAM Bausteinen vergleichen.

Zitat:
Original von dandy:

Unter OS 4.x classic dürfte dann diese Handbremse "gelöst" sein, da ja da der 68060 nur beim Booten benötigt wird - oder?

Naja, dafür laufen sie eigentlich erstaunlich gut...


Jain, im Fall von MorphOS 1.4.x ja, in Fall von OS4 nein. OS4 ist viel zu dick für die viel zu kleinen Caches der MPC603e und MPC604e CPUs. Und ein generelles ja, weil die M68k CPUs nach dem Bootstrap deaktiviert werden. Aber gegen ein reines PPC System mit 604e und 603e sehen die Phase5 Karte noch immer alt aus. Es gab mal ATX Mainboards mit 603e und 604e CPUs auf denen Windows NT 3.5 und 4 gefahren wurde. Die waren richtig flott im Vergleich zu den damals üblichen Pentium 90 bis Pentium MMX 233. (Man hatte nur ein ernsthaftes Treiberproblem :D )

Dass sie erstaunlich gut laufen liegt daran, dass du keinen gleichwertigen Vergleich hast. ;)

Zitat:
Original von dandy:

Das sollte ja - wenn ich Dich richtig verstehe - bei meinem System nicht zutreffen, da ich ja ausschließlich über die PCI Grafikkarte gehe.

Und Sound läuft über die PCI Terratec 512i digital - da sollte das Chip-RAM ebenfalls außen vor bleiben...

Hab' ich noch was vergessen in Sachen Chip-RAM?


Ja, du hast was vergessen. Den Custom Chips wird der Zugriff garantiert und es nicht geschaut, ob der Zugriff wirklich erfolgt. Es kommt noch besser. Dieser garantierte Custom Chip Zugriff wird noch zwischen den Custom Chips anhand einer Prioritätsliste aufgeteilt. Im Amiga erfolgen diese Zugriffe alle per DMA, also ohne die CPU. Der Amiga hat dafür 33 DMA Kanäle (oder waren es 28 bei OCS/ECS? weiß nicht mehr so genau). Das Zugriffsfenster für die Customs Chips müssen sich Disk DMA, Audio DMA, Screen DMA und die Sprite DMA teilen. Wobei die Screen DMA über die Sprite DMA gestellt wird. Man kann den anderen DMAs mehr Reichenzeit einräumen, wenn man auf einige DMAs verzichtet. Zum Beispiel wird bei AIBB die Sprite DMA abgeschaltet, damit die Screen DMA ein paar Rechenzyklen mehr hat.

Zitat:
Original von dandy:

O.K. dann würde das Verschieben auf meinem System wohl kaum etwas bringen...


Ein VBR ins Fast RAM zu schieben bringt immer was, nur ist die non-MMU Variante vermutlich etwas flotter.

Zitat:
Original von dandy:

Hey - sehe grad, dass Du "stolzer Besitzer" einer "Vortex GoldenGate 486SLC" bist - was fängt man denn heutzutage noch damit an?
Die aktuellen Windows-Versionen werden ja wohl darauf genau so wenig laufen, wie auf meiner "Vortex AtOnce286 classic"...


Ich habe die Variante mit einem 486SX 25Mhz (dieser Mist mit 16 Bit Datenpfad zum RAM) und einem 80387 Copro ... nunja, der Trick ist erstmal die Amiga-seitige Software zum laufen zu bringen. Ein 68040 ist da schon unangenehm, der 68060 wird zur Qual. Aber wenn es schon mal läuft - ein MSDOS 6.2/6.22 bekomme ich nicht zum laufen - keine Chance. Ein MSDOS 5.0 geht. Windows 3.11 geht. Aber ich verwende es ab und zu mal für ein Turbo Pascal oder Turbo C++, oder um alte PC DD Disketten zu lesen.

Nein, die Wahreit ist, dass ich meinen A4000T weggepackt habe und stattdessen einen Xeon 1650v4 mit 64GB DDR4 ECC fahre. Da drauf ein vollverschlüsseltes Linux (auch der Bootloader GRUB ist verschlüsselt) betreibe, in dem dank KVM/qemu ein Windows 10 (7 wollte einfach nicht) mit einer GTX 1080 und einer Essence STX II per PCI-passthrough läuft. Es laufen noch diverse andere Linux Systeme dank KVM Virtualisierung da drauf. Die sind im Prinzip Buildhosts, da ich mit diesem "Monster" Bonding-Router Betriebssysteme für meinen Arbeitgeben baue. ;)

Ich habe noch andere schräge Sachen hier, Dual Itianium 2, PowerMac G5 Quad, POWER 4+, HP C8000 (mit 2x Dualcore HPPA-8900+), haufeweise ARM Kram und so weiter. Ist aber im Alltag zu nichts zu gebrauchen, außer vielleich mein "Beast", ein Dual Opteron 6174 (2x12 2.2 GHz + 128DDR3 ECC), fürs Rendern, Simulieren und Distribution bauen.

PS: Wenn das hier wie Angeberei rüberkommt, so wars nicht gedacht. Ich wollte nur untermauern, dass ich gaaanz tief in der Materie drinstecke. Obwohl, etwas angeben kann ich noch. Mein Arbeitsteamkollege ist BeRo aus der Demogruppe Farbrausch. ;) Wir basteln gerade ein paar sehr abgefahrene Router. ;)
--
A4000D/060 @66MHz (unmodifiziert)/604e @233MHz/CyberVisionPPC/PicassoIV + alle Module/128MB FASTRAM/300GB SCA2 -> UW-SCSI2/Ariadne 1/GoldenGate 486SLC

[ - Antworten - Zitieren - Direktlink - ]

15.11.2016, 18:35 Uhr

Holger
Posts: 8038
Nutzer
Zitat:
Original von dandy:
Das bedeutet also, dass wegen der Kontextswitcherei OS3.9/WarpOS16.1 auf meinem System "mit angezogener Handbremse" läuft, auch wenn der PPC von laufenden Anwendungen gar nicht angesprochen wird?


Nein, so kann man das nicht sagen. Wenn der PPC wirklich nicht benutzt wird, gibt’s auch keine Kontext-Switches. Allerdings läuft dann Dein System ja dann erst recht mit angezogener Handbremse, weil Du den vorhandenen PPC nicht nutzt.

Zitat:
Das sollte ja - wenn ich Dich richtig verstehe - bei meinem System nicht zutreffen, da ich ja ausschließlich über die PCI Grafikkarte gehe.
Der Ausgangspunkt war ja, dass trotzdem auf das Chip-RAM zugegriffen wird, wenn das VBR dorthin zeigt.

Zitat:
O.K. dann würde das Verschieben auf meinem System wohl kaum etwas bringen...
Doch, das bringt, wie bereits gesagt, sehr wohl etwas.

Es gibt übrigens in jeder Anwendung mindestens einen unvermeidlichen Chip-RAM Zugriff, da die ExecBase in Adresse vier liegt. Sollte allerdings normalerweise kein Problem darstellen, da jedes ordentliche Programm gleich als erstes die dort ausgelesene Adresse in einer eigenen Variablen ablegt, die üblicherweise im Fast-RAM liegt.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

15.11.2016, 18:41 Uhr

Holger
Posts: 8038
Nutzer
Zitat:
Original von o1i:
Ohne VBR liegt diese Tabelle im Chip-RAM, wird also langsamer ausgelesen als aus dem Fast-RAM. Allerdings ist das nur das Lesen *einer* einzelnen Adresse, das beschleunigt wird, allerdings pro Interrupt und das sind viele pro Sekunde (Multitasking, Grafiksynchronisation, Mausbewegung, Timer, etc.).


Ja, und der Geschwindigkeitsunterschied dieses Lesezugriffs kann deutlich höher ausfallen als der reine Geschwindigkeitsunterschied zwischen Chip-RAM und Fast-RAM (der ja auch schon ziemlich hoch ist), da eine Tabelle im Fast-RAM der CPU auch grundsätzlich das Cachen der Werte erlaubt, was für Daten im Chip-RAM nicht gilt.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]


-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Amiga, AmigaOS 4 > Amiblitz 3 [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1997-2019 by amiga-news.de - alle Rechte vorbehalten.
.