braucht jemand einen "Transputer"?

[Michael Kraemer]

http://www.ebay.de/itm/201795293629?ul_noapp=true#ht_158wt_1071

[Hans-Joerg Schlaberg]

Moin,

Am 28.01.2017 um 08:35 schrieb Michael Kraemer:
> http://www.ebay.de/itm/201795293629?ul_noapp=true#ht_158wt_1071


ob Holger Zimmermann wusste was er da auf seine PAK3 gebastelt hat?

:-))

Gruß Hans-Jörg

[Marcel Mueller]

On 28.01.17 08.35, Michael Kraemer wrote:
> http://www.ebay.de/itm/201795293629?ul_noapp=true#ht_158wt_1071

OMG.

Wie war das? Die Menge der Intelligenz auf der Welt ist begrenzt.
Dummerweise gilt das weder für die Weltbevölkerung noch für die
Weiterentwicklung der Fauna ...

Das ist eine Motorola 68k FPU, und zwar die lahme.
Transputer waren von inmos und hörten auf die Namen T2xx, T40x und T80x.


Marcel

[Michael Kraemer]

Marcel Mueller wrote:
>
> OMG.
>
> Wie war das? Die Menge der Intelligenz auf der Welt ist begrenzt.
> Dummerweise gilt das weder für die Weltbevölkerung noch für die
> Weiterentwicklung der Fauna ...

Gestehe ihm wenigstens die Gnade der späten Geburt zu.

>
> Das ist eine Motorola 68k FPU, und zwar die lahme.
> Transputer waren von inmos und hörten auf die Namen T2xx, T40x und T80x.

wenn die Leute den Unterschied zwischen Txxx und MCxxxx nicht mehr kennen,
dann sind die 1980er wohl endgültig vorbei :-(

[Ka Prucha]

Ich habe jetzt gerade keine Möglichkeit nachzusehen ob ein Motorola
68881 oder 68882 FPU in meine Atari MegaST steckt, vermute aber eher
die 2.
Pure Pascal konnte übrigens etliche Flieskommarechnungen mit der CPU
schneller rechnen als diese FPU. :-)

mfg Karl Prucha

[Goetz Hoffart]

Marcel Mueller <news.5...@spamgourmet.org> wrote:

> > http://www.ebay.de/itm/201795293629?ul_noapp=true#ht_158wt_1071
>
> OMG.
>
> Wie war das? Die Menge der Intelligenz auf der Welt ist begrenzt.
> Dummerweise gilt das weder für die Weltbevölkerung noch für die
> Weiterentwicklung der Fauna ...

Und was haben falsche Informationen nun mit Intelligenz zu tun?

Grüße
Götz
--
http://www.knubbelmac.de/

[Nils Hott]

Goetz Hoffart <use...@hoffart.de> wrote:

> Und was haben falsche Informationen nun mit Intelligenz zu tun?

Das ist das Usenet, da muss gepoltert werden.

Weiß Nils

[Ralf Kiefer]

Marcel Mueller wrote:

> Das ist eine Motorola 68k FPU, und zwar die lahme.

Es ist immerhin die 16,66MHz-Variante vom 68881. Es gab alternativ eine
12,5MHz-Version.

Gruß, Ralf

[Ralf Kiefer]

Michael Kraemer wrote:

> http://www.ebay.de/...

Wenn ich Ebay-Angebote bei Unglaubwürdigkeit oder falschen Angaben
anprangern würde, die mir dort über den Weg laufen, hätte ich viel zu
tun. Besonders schlimm ist das bei "professionellen"
Altelektronikhändlern mit Schwerpunkt auf Industrieware. Die Namen der
Firmeneigentümer weisen dabei relativ häufig auf Herkunft vom Balkan
oder der Türkei. Typischerweise haben die das aus einem funktionierenden
System ausgebaut. Ja, ne, klar, ich glaube fast alles. Und gaaanz sicher
wurde das ESD-gerecht behandelt, also so wie Ford-Transit-Ersatzteile.

Z.B. dieses Angebot, das steht seit Monaten, eher Jahren schon bei Ebay,
aber der Verkäufer kann warten so lange er will, denn das wird nie eine
VMEbus-Karte werden:
http://www.ebay.de/itm/Linotype-CPU-Board-fur-VME-Bus-/222014959807

Was dort schon alles als "VME-Bus" verkauft werden sollte, ist eh
spannend. Es scheint sich bei manchen herumgesprochen zu haben, daß
Kennzeichen einer VMEbus-Karte mindestens eine VG96-Leiste ist. Für
viele gilt der Umkehrschluß. Also ist alles mit VG96- (oder VG64-)Leiste
teuer.

Der Anbieter obiger Hardware gilt bei mir sowieso als merkwürdig bis
-befreit. Seine Preisvorstellungen sind "exotisch", aber sein Lager ist
voll. Ich habe dem schon zweimal ein realistisches Preisangebot gemacht,
aber der bleibt lieber Lagerist als Händler.

Wer wirklich was mit Transputern sucht, sollte hier schauen, aber beim
Preis besser wegschauen:
<http://www.ebay.de/itm/1-Stuck-1-piece-TRANSPUTER-IMSB014-VMEbus-BOARD-
8-TRAM-IMSC012-IMSC004-NEW-/282054183905>
Der Verkäufer ist Elektronikentsorger, hat keine Ahnung, meint aber
einen wertvollen Schatz gefunden zu haben. Jetzt muß er "nur noch" den
Hobbyisten finden, der bereit ist soviel zu zahlen. Ich werde das
Angebot beobachten :-) Nicht aus Interesse an der Hardware, sondern am
Angebotsverhalten.

Gruß, Ralf

[Marcel Mueller]

On 28.01.17 10.37, Ka Prucha wrote:
> Ich habe jetzt gerade keine Möglichkeit nachzusehen ob ein Motorola
> 68881 oder 68882 FPU in meine Atari MegaST steckt, vermute aber eher
> die 2.
> Pure Pascal konnte übrigens etliche Flieskommarechnungen mit der CPU
> schneller rechnen als diese FPU. :-)

Dann ist es vmtl. der 881. Das war seinerzeit eigentlich Standard, so
man denn überhaupt eine FPU hatte. Ein Kumpel musste die FPU in seinen
Atari noch selber einlöten. Da war natürlich kein Sockel da, also ein
paar hundert Drähtchen und los; und dann eine Nacht lang nach dem falsch
angeschlossenen D2 Pin suchen. ;-)


Marcel

[Marcel Mueller]

Ich meinte im Vergleich zum 68882.


Marcel

[Michael Kraemer]

Ralf Kiefer wrote:
> Michael Kraemer wrote:
>
>
>>http://www.ebay.de/...
>
>
> Wenn ich Ebay-Angebote bei Unglaubwürdigkeit oder falschen Angaben
> anprangern würde,

mir ging es nicht um's Anprangern, sondern um's Kuriosum,
bzw den Umstand, dass die Zeit inzwischen so weit fortgeschritten ist,
dass Dinge, die unsereiner zum technischen Allgemeinwissen zählt,
mittlerweile verschütt gegangen sind
(was zum Teufel ist eine "Schallplatte" ??)

> Besonders schlimm ist das bei "professionellen"
> Altelektronikhändlern mit Schwerpunkt auf Industrieware. Die Namen der
> Firmeneigentümer weisen dabei relativ häufig auf Herkunft vom Balkan
> oder der Türkei. Typischerweise haben die das aus einem funktionierenden
> System ausgebaut.

Das lässt mir eher deswegen den Kamm schwellen,
weil dabei anscheinend ein funktionierendes System geschlachtet wurde.

Mich ärgern eher solche, die einen anlügen, ihren Krempel getestet zu haben.
Dabei hätte schon ein einfaches power-up oder einschieben einer Reinigungskassette
anhand knarzender Geräusche gezeigt, dass das betreffende Laufwerk (disk oder tape)
reif für die Tonne ist.
Grade bei "Profis" wundert mich das, immerhin müssen die den Schrott kostenpflichtig
zurücknehmen bzw riskieren eine negative Bewertung.

> Der Anbieter obiger Hardware gilt bei mir sowieso als merkwürdig bis
> -befreit. Seine Preisvorstellungen sind "exotisch", aber sein Lager ist
> voll. Ich habe dem schon zweimal ein realistisches Preisangebot gemacht,
> aber der bleibt lieber Lagerist als Händler.

Ich bin da nicht auf dem laufenden, aber kostet das nicht echtes Geld,
wenn man dort eine Auktion über Wochen und Monate (teilweise sogar Jahre)
laufen lässt?

[Michael Kraemer]

Ka Prucha wrote:

> Pure Pascal konnte übrigens etliche Flieskommarechnungen mit der CPU
> schneller rechnen als diese FPU. :-)

Vielleicht hat Dein PurePascal eine besonders kranke FP-Bibliothek?

Ich fand es jedenfalls atemberaubend, wie schnell mein Amiga 1000
die Apfelmännchen wegrechnete, nachdem ich ihm ein CSA 020/881 board spendiert hatte.
Keine Chance ohne FPU, auch nicht wenn man das Motorola FFP Paket nutzte.

[Ralf Kiefer]

Michael Kraemer wrote:

> mir ging es nicht um's Anprangern, sondern um's Kuriosum,
> bzw den Umstand, dass die Zeit inzwischen so weit fortgeschritten ist,
> dass Dinge, die unsereiner zum technischen Allgemeinwissen zählt,
> mittlerweile verschütt gegangen sind

Damit müssen wir "alten Säcke"[tm] leben ;-)

Erzähl der heutigen Jugend mal, daß es in unserer Jugend nicht
selbstverständlich war, daß die Familie ein(!) Festnetztelefon in der
Wohnung hatte (im Flur, ggf. an der Wand festgeschraubt mit 1,5m langem
Spiralkabel für den Hörer) ggf. mit einer dreistelligen Durchwahl im
Ortsnetz, nicht an der familieneigenen Telefonanlage! Und dann noch
diese fingerabraspelnde Bedienung beim Wählen, wohingegen unsere
Großeltern mit dem Frollein vom Amt ...

> Das lässt mir eher deswegen den Kamm schwellen,
> weil dabei anscheinend ein funktionierendes System geschlachtet wurde.

... und weil sie ahnungslos sind und z.B. die Hälfte nicht eingepackt
haben, z.B. spezielle Kabel, Connectorboards o.ä..

Wenn Altelektronikverwerter ein IHK-Ausbildungsberuf wäre, wäre alles
viel besser ;-)

> Dabei hätte schon ein einfaches power-up oder einschieben einer
> Reinigungskassette anhand knarzender Geräusche gezeigt, dass das
> betreffende Laufwerk (disk oder tape) reif für die Tonne ist.

Dafür braucht man Ahnung. Zumindestens mehr, als heute noch
übriggeblieben ist.


>> [Ebay-Angebote]

> Ich bin da nicht auf dem laufenden, aber kostet das nicht echtes Geld,
> wenn man dort eine Auktion über Wochen und Monate (teilweise sogar Jahre)
> laufen lässt?

Es scheint bei gewerblichen Verkäufern Modelle zugeben, daß die ihren
Krempel für 30Tage reinstellen können, um anschließend, scheinbar sogar
automatisch, um weitere 30Tage zu verlängern. Als privater Verkäufer hat
man eine Auktionslaufzeit von 5, 7 oder 10Tagen, AFAIK, und zeitweise
gibt's Angebote bei Nichtverkauf die Auktion zu wiederholen, was
wiederum nicht nötig wäre, weil man zeitweise als privater Verkäufer
eine gewisse Anzahl an Auktionen sowieso kostenfrei einstellen kann.
Zugegeben, ich habe dort keinen allumfassenden Überblick, denn es gibt
wichtigeres im Leben :-)

BTW im Mehrmonatsrhythmus schaue ich nach einer Auktion, die ich im Mai
2013 gebuchmarkiert (;-) ) habe. Ich würde für diese Karte max. 30Euros
zahlen, wenn ich solch ein Exemplar nicht schon hätte. Der Anbieter
möchte weiterhin $700 (rund 650Euros).


Gruß, Ralf

[Sebastian Barthel]

Am Sat, 28 Jan 2017 17:07:56 +0100 schrieb Michael Kraemer:

> Ich fand es jedenfalls atemberaubend, wie schnell mein Amiga 1000 die
> Apfelmännchen wegrechnete, nachdem ich ihm ein CSA 020/881 board
> spendiert hatte.
> Keine Chance ohne FPU, auch nicht wenn man das Motorola FFP Paket
> nutzte.

FFP ? Was ist das ?

Fresh Frozen Plasma ? Wohl eher nicht ...

[Michael Kraemer]

Sebastian Barthel wrote:
>
> FFP ? Was ist das ?
>

Fast Floating Point.
Ein proprietaeres (nicht IEEE) Format von Motorola.
Hatte nur 32-bit, d.h. nur 6 oder 7 Stellen genau und ging auch nur bis 10 hoch plusminus 20.
Dafür aber relativ schnell wenn man keine FPU hatte.
Beim Amiga standardmässig dabei.

[Michael Kraemer]

Ralf Kiefer wrote:

>
> Erzähl der heutigen Jugend mal, daß es in unserer Jugend nicht
> selbstverständlich war, daß die Familie ein(!) Festnetztelefon in der
> Wohnung hatte (im Flur,

Ich stell mir mal so einen youngster vor in Konfrontation
zu einem klassischen Wählscheibentelefon.
Vermutlich würde er auf die Zahlen tippen, in Erwartung dass sich was tut.
Dann würde er anfangen wie gewohnt wischende Bewegungen zu machen,
und wenn es gut läuft, entdeckt er dabei, dass man die Scheibe drehen kann/muss.
</fies>

>>Das lässt mir eher deswegen den Kamm schwellen,
>>weil dabei anscheinend ein funktionierendes System geschlachtet wurde.
>
>
> ... und weil sie ahnungslos sind und z.B. die Hälfte nicht eingepackt
> haben, z.B. spezielle Kabel, Connectorboards o.ä..

nein, weil sie gierig sind und glauben, für die Einzelteile insgesamt mehr Kohle
zu bekommen, als für das gesamte funktionierende System.
Solche Geier hatte ich schon mehrfach "an der Strippe".
(schon wieder so was alttelefonisches :-)

>>Dabei hätte schon ein einfaches power-up oder einschieben einer
>>Reinigungskassette anhand knarzender Geräusche gezeigt, dass das
>>betreffende Laufwerk (disk oder tape) reif für die Tonne ist.
>
>
> Dafür braucht man Ahnung. Zumindestens mehr, als heute noch
> übriggeblieben ist.

Nein dafür braucht man die Unverschämtheit,
den Kunden das Austesten zu lassen, mal sehen wie weit man damit kommt.

[kay]

Am 28.01.2017 um 13:08 schrob Ralf Kiefer:

>
> Wenn ich Ebay-Angebote bei Unglaubwürdigkeit oder falschen Angaben
> anprangern würde, die mir dort über den Weg laufen, hätte ich viel zu
> tun. Besonders schlimm ist das bei "professionellen"

Die Gänsefüsschen sind wichtig. Professionell ist bei denen nur das Geld
scheffeln.

> Was dort schon alles als "VME-Bus" verkauft werden sollte, ist eh
> spannend. Es scheint sich bei manchen herumgesprochen zu haben, daß
> Kennzeichen einer VMEbus-Karte mindestens eine VG96-Leiste ist. Für
> viele gilt der Umkehrschluß. Also ist alles mit VG96- (oder VG64-)Leiste
> teuer.

Da würden sie nicht nur dort, sondern z.B. auch beim COBOLD auf die Nase
fallen. Der besteht aus drei Platinen und nur eine davon enthält den
eigentlichen Computer (aber komplett bis auf UI). Aber die Basiskarte
hat(te) 1-x (IMHO 6-8) Plätze für VG54AC Leisten und die CPU kam in eine
davon...

Natürlich brauchte man mindestens entweder noch ein Serielles Terminal
oder die Dritte, die TD-Karte mit Tastatur und 7Segment Displays. Und so
netten Features wie LEDs aus, Single-Step...

Nichts davon hat was mit VME zu tun. Das ist ein 6502-System aus der
ELRAD. Vorläufer von CEPAC-65 und Co....

Und auf dem "BUS" liegen auch nur die Portleitungen, der bis zu drei
RIOT's (6532, 2*8Bit I/O, RAM, Timer)

Kennt heute sicher auch keiner mehr. Muss wohl gelegentlich mal meinen
wikipedia-artikel dazu etwas verbessern.

N.B. Ich dachte immer das die Klassischen VME-Rechner eher ein 6HE Rack
belegen (also doppelt hohes Euroformat) und deshalb auch Zwei VG-Leisten
pro Karte und Slot hätten.

Liegt wohl daran das ich; wenn's mich mal interessierte; ich nur solche
Systeme fand - oder suchte.


Kay
--
Posted via SN

[Sebastian Barthel]

Am Sat, 28 Jan 2017 17:41:53 +0100 schrieb Michael Kraemer:

> Sebastian Barthel wrote:
>>
>> FFP ? Was ist das ?
>>
>>
> Fast Floating Point.
> Ein proprietaeres (nicht IEEE) Format von Motorola.

OK. Wieder was gelernt.

[Michael van Elst]

Sebastian Barthel <nait...@freenet.de> writes:

>Am Sat, 28 Jan 2017 17:07:56 +0100 schrieb Michael Kraemer:

>> Ich fand es jedenfalls atemberaubend, wie schnell mein Amiga 1000 die

>> Apfelmännchen wegrechnete, nachdem ich ihm ein CSA 020/881 board

>> spendiert hatte.
>> Keine Chance ohne FPU, auch nicht wenn man das Motorola FFP Paket
>> nutzte.

>FFP ? Was ist das ?

Fast Floating Point. Single Precision, nicht IEEE-kompatibel, dafür
schneller.

--
--
Michael van Elst
Internet: mle...@serpens.de
"A potential Snark may lurk in every tree."

[Arno Welzel]

Michael Kraemer wrote:

> Ralf Kiefer wrote:
>
>>
>> Erzähl der heutigen Jugend mal, daß es in unserer Jugend nicht
>> selbstverständlich war, daß die Familie ein(!) Festnetztelefon in der
>> Wohnung hatte (im Flur,
>
> Ich stell mir mal so einen youngster vor in Konfrontation
> zu einem klassischen Wählscheibentelefon.
> Vermutlich würde er auf die Zahlen tippen, in Erwartung dass sich was tut.

So schlimm ist es auch wieder nicht:

<https://www.youtube.com/watch?v=XkuirEweZvM>




--
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[Andreas Bockelmann]

Marcel Mueller schrieb:

Danke für die Auffrischung. Ich wusste, die Bezeichnung kam mir bekannt vor.

--
Mit freundlichen Grüßen
Andreas Bockelmann
F/V +49-3221-1143516

[Andreas Bockelmann]

Marcel Mueller schrieb:

Beim MAiga waren WIMRE auf den 68020-Turbokarten die 68881 verbaut und auf
den 68030-Karten die 68882. Aber das mit dem Amiga ist > 20 Jahre her.

[Andreas Bockelmann]

Michael Kraemer schrieb:

> Ka Prucha wrote:
>
>> Pure Pascal konnte übrigens etliche Flieskommarechnungen mit der CPU
>> schneller rechnen als diese FPU. :-)
>
> Vielleicht hat Dein PurePascal eine besonders kranke FP-Bibliothek?

Das war auf dem Amiga ähnlich. Die FPU verwendete ein anderes Zahlenformat
als es in den Libraries für die CPU verwendet wurde. Doppeltes
Formatumrechnen benötigte mehr Zeit als die FPU sparte.

[Michael Kraemer]

Andreas Bockelmann wrote:
> Michael Kraemer schrieb:
>
>> Ka Prucha wrote:
>>
>>> Pure Pascal konnte übrigens etliche Flieskommarechnungen mit der CPU
>>> schneller rechnen als diese FPU. :-)
>>
>>
>> Vielleicht hat Dein PurePascal eine besonders kranke FP-Bibliothek?
>
>
> Das war auf dem Amiga ähnlich. Die FPU verwendete ein anderes
> Zahlenformat als es in den Libraries für die CPU verwendet wurde.
> Doppeltes Formatumrechnen benötigte mehr Zeit als die FPU sparte.

Für das FFP-format natürlich.
IEEE-Zahlen wurden in den Integer-Registern der CPU übergeben,
die muss man dann erstmal irgendwie in die FPU-Register bugsieren.

Als die ersten Turboboards rauskamen (1985/86) konnten
weder die damaligen Compiler (Lattice) noch die IEEE libraries mit der FPU was anfangen.
Ich habe mir dann mal den Spass gemacht, die FP-Unterprogramme der Compilerbibliotheken durch eigene zu ersetzen.
Sequenzen der Art
move.l d0,-(SP)
move.l d1,-(SP)
fmove.s (SP)+,fp1
fmove.s (SP)+,fp0
fmul fp1,fp0
fmove.s fp0,-(SP)
move.l (SP)+,d0
oder so waren dann immer noch schneller, als ganz auf die FPU zu verzichten.
Ich denke mal, dass die späteren Ausgaben der IEEE libraries das auch so gemacht haben.
Irgendwann konnten dann auch die Compiler inline-FPU Code erzeugen.
Oder man programmiert gleich das ganze Apfelmännchen in Assembler.
Ist ja nicht mehr als eine Fingerübung. :-)

[Marcel Mueller]

On 29.01.17 10.44, Michael Kraemer wrote:
> Irgendwann konnten dann auch die Compiler inline-FPU Code erzeugen.
> Oder man programmiert gleich das ganze Apfelmännchen in Assembler.
> Ist ja nicht mehr als eine Fingerübung. :-)

Die komplexe Zahlenrechnung schon, aber wenn man es wirklich schnell
haben wollte, muss man smarter ran.
Es gibt da ein paar Approximationen, die zwar vereinzelt mal zu falschen
Pixeln führen können, aber dafür durchaus Zehnerpotenzen holen. Allen
voran das Gesetz, dass jeder Innenraum einer vollständig in der
Mendelbrotmenge liegenden Kontur selbst vollständig zu Menge gehört. Das
gilt vorbehaltlich des Grenzfalls der kompletten Umschließung der Menge
auch für Areale mit einer endlichen Iterationsanzahl. Damit muss man nur
noch die Konturen abklappern. Der einzige Fehler, den man dabei macht,
ist, dass einem durch die endliche Quantisierung unter Umständen mal
einzelne Einbuchtungen durch die Lappen gehen können. Das kann man
einfangen, indem man immer noch ein, zwei Nachbarpixel berechnet.
Damit habe ich seinerzeit schon auf den 486-er Apfelmännchen in
4k*4k-Auflösung in vielleicht einer halben Stunde berechnet (um sie
später als Height-Map für PovRay zu verwenden - sieht cool aus).

Die Regel gilt übrigens auch im vierdimensionalen Mandelbrot/Julia Raum.
AFAIR gab es Anfang der 90-ern mal so ein Video dazu, wo jemand mit der
Maus zwei Dimensionen geschubst hat und die anderen zwei Dimensionen
waren dann die Bildkoordinaten - update in Echtzeit versteht sich. Das
war natürlich kein 486, sondern eine Reality Engine 2 oder sowas. Das
alleine hätte aber nicht gereicht.


Marcel

[Ralf Kiefer]

kay wrote:

> Am 28.01.2017 um 13:08 schrob Ralf Kiefer:
> >
> > Wenn ich Ebay-Angebote bei Unglaubwürdigkeit oder falschen Angaben
> > anprangern würde, die mir dort über den Weg laufen, hätte ich viel zu
> > tun. Besonders schlimm ist das bei "professionellen"
>
> Die Gänsefüsschen sind wichtig. Professionell ist bei denen nur das Geld
> scheffeln.

Sie sind bei Ebay als gewerbliche Händler angemeldet. Das wäre eher die
korrekte Bezeichnung.

> N.B. Ich dachte immer das die Klassischen VME-Rechner eher ein 6HE Rack
> belegen (also doppelt hohes Euroformat) und deshalb auch Zwei VG-Leisten
> pro Karte und Slot hätten.

Es gibt den VMEbus in drei mechanischen Ausprägungen: 3HE, 6HE und 9HE.
Die Varianten 3HE und 6HE haben eine Kartenlänge von 160mm, die 9HE
"quad-depth" (den genauen Wert müßte ich suchen). Die 9HE-Version wurde
ausschließlich von Sun [1] eingesetzt, AFAIK. Es gab dazu
Adapterplatinen, um die "kleinen" ins große Sun-Rack schrauben zu
können. Das sind die sprichwörtlichen Kuchenbleche.

Gemeinsam ist allen der P1, also der "obere" Steckverbinder mit einer
vollbelegten 96pol. VG-Leiste. Da passen allerdings nur 24 Adreß- und 16
Datenleitungen drauf. Für 32/32bit wird der P2 benötigt.

Die 3HE-Karten kann man immer in ein 6HE-Rack schrauben. Das sind dann
z.B. solche Karten:
<http://www.ebay.de/itm/Phoenix-Contact-VME-Interbus-S-Slave-IBS-SLV-D-3
020-002-1-GEB-/360759348221>

Es gibt auch 6HE-Karten, die lediglich den P1 nutzen:
http://www.ebay.de/itm/EKF-System-68570-129-LAN-4-1-VMEbus-6U-Hostadapte
<r-9329-/201279973894>

Auf dem P2 wird vom ursprünglichen VMEbus-Protokoll (parallel, 32bit)
nur die mittlere b-Reihe benutzt. Die äußeren a- und c-Reihen dürfen für
proprietäre Signale genommen werden. Soll heißen, daß es auch
6HE-VMEbus-Karten gibt, die vom Bus nur den P1 benutzen, aber die P2-a-
und -c-Reihen für I/O brauchen. Das ist übrigens sehr praktisch, weil
man dazu anpreßbare 64pol. VG-Leisten nehmen kann und so per
Flachbandkabel die Signale zu ihrem Ziel führen kann. Die Preßstecker
kann man bei nicht vorhandener P2-Backplane direkt ins Rack schrauben
oder bei vorhandener P2-Backplane von hinten auf diese aufstecken.

Bist Du noch dabei? ;-)

Noch mehr "Verwirrung" :-) Ich habe hier eine Karte, die kann 32bit
Adreßbus, hat daher P1 und P2, ist allerdings nur per 16bit Datenbus
angeschlossen. Das System ist so flexibel und die jeweiligen Protokolle
darauf ausgelegt, so daß es damit keine Probleme gibt.


Das war Stand der Technik um 1990 herum. Danach kamen noch weitere,
darauf aufbauende VME-Varianten ...

Gruß, Ralf


[1] Siehe englische Wiki und die Einträge für Sun-2, Sun-3 und Sun-4

[Ka Prucha]

Bei mir ist es aber die original Karte mit einem Motorola MC68881FN16B.

<https://www.flickr.com/photos/opa_jimmy/32469660731/>
<https://www.flickr.com/photos/opa_jimmy/32469655691/>

mfg Karl Prucha

[Marcel Mueller]

On 29.01.17 18.57, Ka Prucha wrote:
> Am 28.01.2017 um 15:34 schrieb Marcel Mueller:
>> Dann ist es vmtl. der 881. Das war seinerzeit eigentlich Standard, so
>> man denn überhaupt eine FPU hatte. Ein Kumpel musste die FPU in seinen
>> Atari noch selber einlöten. Da war natürlich kein Sockel da, also ein
>> paar hundert Drähtchen und los; und dann eine Nacht lang nach dem falsch
>> angeschlossenen D2 Pin suchen. ;-)
>
> Bei mir ist es aber die original Karte mit einem Motorola MC68881FN16B.

Ja, der MegaST war aber auch ein paar Jahre später. Das war noch ein 540-er.


Marcel

[Ralf Kiefer]

Ka Prucha wrote:

> Bei mir ist es aber die original Karte mit einem Motorola MC68881FN16B.

68881 und 68882 sind austauschbar. Außerdem kann die FPU asynchron
laufen, d.h. mit anderem Takt als die CPU. Die PAK1 von der c't war so
eine Karte, bei der der FPU-Takt von einem eigenen Oszillator geliefert
werden konnte.

Gruß, Ralf

[Goetz Hoffart]

Ralf Kiefer <R.Kiefe...@gmx.de> wrote:

> 68881 und 68882 sind austauschbar. Außerdem kann die FPU asynchron
> laufen

Jop. Und ein Wechsel 881->882 bringt viel umpf ...

[kay]

Am 29.01.2017 um 21:10 schrob Ralf Kiefer:

> Ka Prucha wrote:
> 68881 und 68882 sind austauschbar. Außerdem kann die FPU asynchron
> laufen, d.h. mit anderem Takt als die CPU.

Nicht nur dort übrigens. Bei PCs (natürlich nur bis 486SX) konnte man
eine langsamere FPU neben eine schnellere CPU stecken. Lag AFAIR daran
das die CPU eh selbst die speziellen FPU Register befüllen musste und
auch das Ergebnis abholte.

Wie ist das bei den Motorolas? Waren die FPU's "aktiver" oder wurden die
auch vom Hauptprozessor aus angesteuert?

Wobei mir grad nicht einfällt wie man es anders sinnvoller lösen könnte.
Schliesslich muss die CPU den Befehlsstrom dekodieren und stößte dabei
entweder auf FPU-Befehle - oder eben nicht.

[Markus Elsken]

Moin!

Am 29.01.17 um 21:20 schrieb Goetz Hoffart:

> Jop. Und ein Wechsel 881->882 bringt viel umpf ...

Der Einbau der PAK/3 brachte RICHTIG Umpf, vor allem weil die
50MHz-Chips locker mit 66MHz stabil liefen...

mfg Markus

[Ralf Kiefer]

kay wrote:

> Wie ist das bei den Motorolas? Waren die FPU's "aktiver" oder wurden die
> auch vom Hauptprozessor aus angesteuert?

Bei den 68k-CPUs gibt's das sogenannte Koprozessorprotokoll, d.h. eine
in Software und Hardware gegossene Schnittstelle für Koprozessoren
beliebiger Art. Max. 15 Koprozessoren kann ein 68020-Kern betreiben.

Software: Für jeden der 15 Koprozessoren ist ein Bereich im Befehlssatz
reserviert. Motorola schlug für die eine übliche FPU eine ID (-> F-Line
instructions) vor, genauso wie für die MMU 68851 als Koprozessor, die
später im 68030 integriert wurde. Findet sich zum Befehl keine FPU im
Rechner, kann der "Trap", ein Software-Interrupt, die FPU-Emulation
anstoßen. Ansonsten übernimmt die FPU den Befehl. Die FPU bedient sich
somit aus dem Cache der CPU und arbeitet parallel, während die CPU mit
eigenen (Integer-)Befehlen weitermachen kann. Das Protokoll ist, wie
erwähnt, auf 15 Koprozessoren ausgelegt und einzig bei der
Code-Erzeugung muß drauf geachtet werden, daß die richtige Koprozesor-ID
im Code berücksichtigt wird. Im Umkehrschluß: es wäre möglich mehrere
gleichartige FPUs neben einer einzelnen CPU zu betreiben.

Hardware: die CPU liefert mit einem Koprozessorbefehl die nötigen Daten
an die FPU und eine Art Chip-Select aus, so daß sich der passende
Koprozessor um die Unterhaltung mit der CPU kümmern kann, ähnlich einem
Peripheriechip.

Autark kann eine 68k-FPU nicht laufen, denn ihr fehlen im Befehlssatz
alle nötigen Befehle, die den Code-Ablauf steuern.

Gruß, Ralf

[Sven Hartge]

Ralf Kiefer <R.Kiefe...@gmx.de> wrote:

> Software: Für jeden der 15 Koprozessoren ist ein Bereich im
> Befehlssatz reserviert. Motorola schlug für die eine übliche FPU eine
> ID (-> F-Line instructions) vor, genauso wie für die MMU 68851 als
> Koprozessor, die später im 68030 integriert wurde. Findet sich zum
> Befehl keine FPU im Rechner, kann der "Trap", ein Software-Interrupt,
> die FPU-Emulation anstoßen. Ansonsten übernimmt die FPU den Befehl.
> Die FPU bedient sich somit aus dem Cache der CPU und arbeitet
> parallel, während die CPU mit eigenen (Integer-)Befehlen weitermachen
> kann. Das Protokoll ist, wie erwähnt, auf 15 Koprozessoren ausgelegt
> und einzig bei der Code-Erzeugung muß drauf geachtet werden, daß die
> richtige Koprozesor-ID im Code berücksichtigt wird. Im Umkehrschluß:
> es wäre möglich mehrere gleichartige FPUs neben einer einzelnen CPU zu
> betreiben.

Gab es Systeme, die soetwas umgesetzt haben, also mehr wie eine FPU zum
Rechnen benutzt haben?

S°

--
Sigmentation fault. Core dumped.

[Ralf Kiefer]

Sven Hartge wrote:

> Gab es Systeme, die soetwas umgesetzt haben, also mehr wie eine FPU zum
> Rechnen benutzt haben?

Mir ist keines bekannt. Allerdings kenne ich eher nur
Mainstream-68k-Hardware. Was teilweise in Nischen-Hardware gebaut wurde,
ist dagegen teils "exotisch", z.B. Spielautomaten oder Meßgeräte.

Wenn man so was baut, braucht man dazu einen geeigneten Compiler. Oder
jemand, der das in Assembler handkodiert.

Gruß, Ralf

[Goetz Hoffart]

Ralf Kiefer <R.Kiefe...@gmx.de> wrote:

> Im Umkehrschluß: es wäre möglich mehrere
> gleichartige FPUs neben einer einzelnen CPU zu betreiben.

Und auch ganz andere FPUs/Coprozessoren als von Motorola zu nutzen,
solange das Protokoll stimmt. Theoretisch kann man sich da heute was
modernes drandengeln.

Übrigens kosten kosten die Line-Traps der 68ks leider auch Performance.

[Goetz Hoffart]

Markus Elsken <markus...@ewetel.net> wrote:

> > Jop. Und ein Wechsel 881->882 bringt viel umpf ...
>
> Der Einbau der PAK/3 brachte RICHTIG Umpf, vor allem weil die
> 50MHz-Chips locker mit 66MHz stabil liefen...

Sicher. Und ein 060 bring noch mehr Umpf.

Nur ist der Wechsel von 881->882 trivial machbar, und ein Wechsel der
Haupt-CPU in den meisten Systemen nontrivial. Denn eigentlich hatten wir
es zwei Posts früher von 68000-Systemen von 1985-1987.

[Michael van Elst]

kay <k...@martinen.de> writes:

>Wie ist das bei den Motorolas? Waren die FPU's "aktiver" oder wurden die
>auch vom Hauptprozessor aus angesteuert?

68881+68882 wurde ähnlich als Koprozessor angesteuert. Der Unterschied
zwischen beiden liegt darin, dass der 68882 Pipelining machte. Das
reduziert den Overhead entsprechend und sorgte für den, aeh, "Umpf".
Die 68882 gab es auch mit höherem Takt (bis 50MHz).

68040+68060 haben interne FPUs und kein Koprozessorinterface mehr,
beim 68040 liefen Teile der FPU mit doppeltem Prozessortakt. Natürlich
führt der Hauptprozessor hier immer noch die Befehle aus und verschiebt
die Daten. Aber die neuere Halbleitertechnik und die Integration
sorgten dafür, dass die Leistung um den Faktor 7-10 stieg.

"Aktive" FPUs gibt es kaum, da sich sowas nur sehr schwer mit
dem normalen Programmablauf kombinieren lässt. Das gab es daher
eher bei Vektorrechnern oder heutzutage bei GPUs. Dort laufen
dann eigene Programme und es wird meist auch auf dedizierten
Speicher zugegriffen.

[Ralf Kiefer]

Goetz Hoffart wrote:

> Und auch ganz andere FPUs/Coprozessoren als von Motorola zu nutzen,
> solange das Protokoll stimmt. Theoretisch kann man sich da heute was
> modernes drandengeln.

Ich hätte mir einen Grafikcontroller vorgestellt, oder zwei ...

Im Mac natürlich einen, der QuickDraw direkt könnte.

Gruß, Ralf

[Ralf Kiefer]

Michael van Elst wrote:

> 68040+68060 haben interne FPUs

Der Vollständigkeit halber: mit eingeschränktem Befehlssatz gegenüber
dem 68881/2. Die 68060-CPU hat noch weniger FPU-Befehle wie die
68040-CPU. Beim Auftauchen eines fehlenden FPU-Befehls wird die
Software-Emulation angeworfen, von der Motorola meinte, daß die nicht so
arg viel langsamer wäre.

Gruß, Ralf

[Goetz Hoffart]

Ich kann das nicht für alle Befehle sagen, aber generell würde ich da
nicken.

Hey, schon ein 68LC040 (d.h. ohne FPU) bei 25 MHz war in der Praxis
fixer als ein 68030/40 + 68882/40. Ja, mit FPU-lastigem Code.

[Ralf Kiefer]

Goetz Hoffart wrote:

> Hey, schon ein 68LC040 (d.h. ohne FPU) bei 25 MHz war in der Praxis
> fixer als ein 68030/40 + 68882/40. Ja, mit FPU-lastigem Code.

Das bezweifle ich ein wenig. Vielleicht bin ich in ein paar Monaten
soweit und kann diesbezüglich was auf repräsentativen VMEbus-Karten
vorführen, bei denen Floatingpoint-Mathematik im OS-9 etwas anders als
im MacOS funktioniert. Ich habe bloß keinen 68LC040 am Start ... Hm,
mir fehlt dazu die FPU-Emulation.

Hast Du den Performa 475 gegen den IIfx verglichen?

Gruß, Ralf

[Goetz Hoffart]

Ralf Kiefer <R.Kiefe...@gmx.de> wrote:

> Hast Du den Performa 475 gegen den IIfx verglichen?

Exakt.

[Ignatios Souvatzis]

Ralf Kiefer wrote:
> Sven Hartge wrote:
>
>> Gab es Systeme, die soetwas umgesetzt haben, also mehr wie eine FPU zum
>> Rechnen benutzt haben?
>
> Mir ist keines bekannt. Allerdings kenne ich eher nur
> Mainstream-68k-Hardware

Da gibt's ein Problem - zumindest der 68882 ist zu schnell, WIMRE,
so dass gar keine wesentliche Wartezeit mehr übrig bleibt, in der
ein zweiter, dritter, oder gar 14ter 68882 Befehle und Daten übernehmen
könnte.

Hat man mich drauf hingewiesen, als ich laut die selbe Idee hatte.

-is

[Ralf Kiefer]

Ignatios Souvatzis wrote:

> Da gibt's ein Problem - zumindest der 68882 ist zu schnell, WIMRE,
> so dass gar keine wesentliche Wartezeit mehr übrig bleibt, in der
> ein zweiter, dritter, oder gar 14ter 68882 Befehle und Daten übernehmen
> könnte.

Ich überfliege gerade die dazu passenden Kapitel im MC68881/882 User's
Manual :-)

Beim 68881 ist's so, daß der einen FPU-Befehl nach dem anderen streng
sequentiell abarbeitet. D.h. er wird von der MPU "gefüttert", rechnet
und wickelt das Ende des Befehls wieder mit der MPU ab. Letzteres ist
'ne komplexe Geschichte, weil ggf. Operanden zwischen MPU- und
FPU-Registern transportiert werden (1 Zyklus für 32bit), oder die FPU
sich im Cache der MPU bedient (1 Zyklus für 32bit), oder die FPU Daten
aus dem RAM braucht (3 Zyklen für 32bit bei Zero-Waitstate-RAM). Dazu
werden noch ein paar weitere Bits zwischen MPU und FPU ausgetauscht
zzgl. eventueller Strafen für misaligned. Mit allen Varianten der
Synchronisation dauert das zwischen 2 und 11 Zyklen, wobei ich annehme,
daß sich das jeweils auf den langsameren Chip bezieht, wenn die mit
unterschiedlichen Frequenzen laufen. Diesen Fall beschreibt Motorola
erst gar nicht, vermutlich, weil's zu kompliziert wird :-)

Wenn die FPU erstmal alle Daten hat, beginnt sie mit Datenkonvertierung
und Berechnung, je nach Befehl. Danach geht das Gehampel mit der MPU
wieder los ;-) Die MPU kann währenddessen parallel eigene Befehle
abarbeiten.

Beim 68882 ist's so, daß es eine Art von Pipelining gibt: während noch
der Berechnungsteil vom einen Befehl läuft, kann der nächste bereits
vorbereitet werden, d.h. Daten holen, sofern es die Registerbelegung
zuläßt, usw. Genauso kann der 68882 bereits am nächsten Befehl rechnen,
während der vorangegangene Befehl noch nachbereitet wird, d.h. die Daten
zur MPU geschrieben werden. Interessanterweise kann der 68882 im
Gegensatz zum 68881 zusätzlich manche Befehle parallel ausführen, d.h.
doppelte Last auf dem Interface zur MPU.

Soll heißen, daß das Interface nach draußen beim 68882 deutlich mehr
beschäftigt ist als beim 68881. Aber ich sehe in der Tabelle der
Ausführungszeiten eine ganze Menge Befehle, die über 500 Zyklen
brauchen. Da sollte eigentlich genügend Zeit bleiben, eine zweite FPU
mitzufüttern, zumindestens wenn die Mehrzahl der FPU-Befehle die
komplexen mit den langen Ausführungszeiten sind wie z.B. die
trigonometrischen. Ich würde jetzt allerdings durchaus vermuten, daß das
Coprozessor-Interface ab der dritten FPU beginnt schlappzumachen, wenn
sie 68882 heißen.

> Hat man mich drauf hingewiesen, als ich laut die selbe Idee hatte.

Ich habe das Kapitel Ausführungszeiten nach der Hälfte aufgehört zu
lesen. Die Komplexität ist enorm, aber die Größenordnung kann ich
erkennen. Zyklenzählen beim 6502 war spaßhafter und mit mehr
Erfolgsaussichten verbunden :-)

Gruß, Ralf

[kay]

Am 08.02.2017 um 01:02 schrob Ralf Kiefer:

>
> Ich habe das Kapitel Ausführungszeiten nach der Hälfte aufgehört zu
> lesen. Die Komplexität ist enorm, aber die Größenordnung kann ich
> erkennen.

Nimm einen Emulator auf einer Gigahertz-CPU dann klappt das auch mit xx
FPU's.... und vielleicht sogar mit der Nachbarin. SCNR

Ernsthaft. Ich weiß ja nicht welche Berechnungen der Chip kann. Aber das
die Befehle mit hohem Zyklenbedarf häufiger vorkommen kann man
bezweifeln. Auch weil das von der Art des auszuführenden Programms
abhängen dürfte. OS-intern dürfte vieles Integer sein und nicht jeder
startet Mandelbrot-männchen, Raytracer oder Mathesoftware.

Vielleicht wäre ein Transputer doch besser, um mal wieder Bezug zum
Topic zu bekommen. ;)

> Zyklenzählen beim 6502 war spaßhafter und mit mehr
> Erfolgsaussichten verbunden :-)

Sischer datt. Der hatte ja nur ZWEI! ;-)

Ähh, ach nee, das waren ja nur die Taktsignale. Bei zweistelligen
Addressierungsarten aber auch nicht mehr lustig - nicht ohne
Opcode/Adressmode-Tabelle.

Ich weiß nur noch das Zeropage und Immediate die Schnellsten gewesen
sein sollen - mit Limitierungen. Muss die alten Schmöker doch noch mal
raus kramen (Zaks u. Co.)

Abgesehen davon und was Befehlszyklen angeht. Das nicht mal der
Hersteller genau angeben kann wie viele Zyklen seine CPU bei einem
Befehl braucht, halte ich irgendwie für Kontraproduktiv. Aber die ganze
Spekuliererei ist wohl billiger als ein neues schnelleres (z.B.
SRAM-Basiertes) Speichersystem.

Ulkigerweise wurden die ATOMs mit In-Order execution erst hoch gelobt
das sie diese Fehlerquellen vermeiden. Doch kürzlich las ich das die
neueren nun auch "Schätzmeister" (out-of-order-exec) werden.

Wo soll diese Komplexität noch hin führen!? Turing-Maschine,
Selbstlernende KI, SkyNet,???

Da kann einem Bange werden was der nächste Pentium-Bug "auslösen" wird.
Vielleicht das ein Immobilien-Mogul die Firma USA leitet... [Unken-Mode
On] RoboCop, ick hör dir tappsen.

Kay

Rule XyZ: Never oppose an OCP-Official.
--
"Indiana TRON und der verlorene Rasterzeilen-interrupt." :-)

[Ralf Kiefer]

kay wrote:

> Ich weiß ja nicht welche Berechnungen der Chip kann.

Er kann die 4 Grundrechenarten zzgl. die trigonometrischen Funktionen,
e^x, 10^x, Logarithmen, Quadratwurzel sowie die vielen Konvertierungen
und Vergleiche zwischen der Integer-Welt und seinen drei
Floatingpoint-Formaten Single, Double und Extended. Letztere Variante
rechnet 80bit breit. Und genau so breit sind die 8 internen
Datenregister. In Summe: 46 Befehle, davon 35 arithmetische. Dazu kommen
nette Kleinigkeiten wie z.B. 22 Konstanten aus dem ROM. Das "große"
Format entspricht IEEE 754.

AFAIR rechnet Apples SANE noch genauer, aber dadurch langsamer. Und ggf.
sehr viel langsamer, weil es dieses Arithemetik-Paket auch auf dem Apple
][ und /// gab, d.h. auf einem 65C02 mit 1MHz.

Ich erinnere mich noch, wie wir in den frühen 1990er Jahren das
Floatingpoint-Format im Mac auf das "billige" IEEE-754-Format
runterregelten, damit Floatingpoint schneller wurde, weil sie somit
komplett in der FPU erledigt werden konnte. Und jetzt komm mir bitte
nicht mit "billigen" Transputern, siehe unten ;-)

> Aber das
> die Befehle mit hohem Zyklenbedarf häufiger vorkommen kann man
> bezweifeln.

Jein. Es kommt drauf an, was die Software machen soll, und wie der Code
dazu generiert wurde. Besonders auffällig war das Thema in den frühen
1990er Jahren, als die teureren Macs eine FPU hatten, die preisgünstige
Linie jedoch nicht. Programme wie Photoshop profitierten in einzelnen
Funktionen ungemein von einer FPU. So was wie Mandelbrötchen natürlich
auch, was ich allerdings nicht zu den wichtigen Anwendungen zähle.

> OS-intern dürfte vieles Integer sein und nicht jeder
> startet Mandelbrot-männchen, Raytracer oder Mathesoftware.

Das Betrübssystem profitiert typischerweise nicht von einer FPU, aber
alles, was komplexere Grafik einsetzt schon. Nur mal als Beispiel, für
welche Zwecke die FPU noch verwendet wurde: in den Modula-2-Bibliotheken
in der OS-9-Welt fanden wir Code zur String-Konvertierung, die die FPU
benutzt. Da hatte ein findiger Auskenner herausgefunden, daß die
Datenformatkonvertierungsbefehle von der FPU schnelleren Code selbst für
solche Aufgaben hergeben.

> Vielleicht wäre ein Transputer doch besser, um mal wieder Bezug zum
> Topic zu bekommen. ;)

Nicht unbedingt. Der T414 hatte lediglich 32bit-Register und keine
Floatingpoint-Datenformate. Erst der T800 bekam drei(!)
64bit-Floatingpoint-Register, aber eben keine 80bit, wie für den
IEEE-754-Standard nötig waren.


> [6502]

> Ich weiß nur noch das Zeropage und Immediate die Schnellsten gewesen
> sein sollen - mit Limitierungen.

Mal wieder die alte Weisheit: der 6502 war einer der ersten
erfolgreichen RISC-Chips mit 3 sehr schnellen internen Registern und 256
ausgelagerten Registern :-)

> Muss die alten Schmöker doch noch mal
> raus kramen (Zaks u. Co.)

Ich habe das 6502-Geschehen gerade im kopfinternen Cache :-) Denn ich
schreibe gerade an meinem universellen Disassembler, der im ersten
Schritt die 8bit-Welt abdecken können soll. Vollstens konfigurierbar,
quasi eine Fortführung vom DASM. Aus naheliegenden Gründen startete ich
mit der 6502-Welt.

> Abgesehen davon und was Befehlszyklen angeht. Das nicht mal der
> Hersteller genau angeben kann wie viele Zyklen seine CPU bei einem
> Befehl braucht, halte ich irgendwie für Kontraproduktiv.

Motorola hat im genannten Datenbuch sehr viele exakte Angaben zu den
Zykluszahlen genannt. Das ist wirklich nicht das Problem. Der Nutzer
sollte nur die vielen Randbedingungen, Fußnoten und Sonderfälle kennen
bzw. beim Zählen anwenden können. Und genau da habe _ich_ keine Lust
mich weiter reinzuvertiefen. Wenn Du magst: das relevante Buch hat die
ISBN 0-13-567009-8 und nur ein paar hundert Seiten.

> Aber die ganze
> Spekuliererei ist wohl billiger als ein neues schnelleres (z.B.
> SRAM-Basiertes) Speichersystem.

Nicht unbedingt nötig. Ich hoffe drauf, daß meine schnelle
Eltec-E6-Karte (noch) funktioniert. 68030 und 68882 @50MHz mit 16kB
L2-Cache. Ok, die 68040 sind schneller: 33MHz Bustakt und beim Lesen vom
DRAM 4-1-1-1 (burst read), Schreiben 2-1-1-1 (burst write). Zum
Nachrechnen: 150nsec zum Schreiben oder 210nsec zum Lesen von 16Byte.
Das sind extrapoliert 100MB/s schreibend und 72MB/s lesend. BTW im Jahr
1993. Das wird mit SRAMs nicht mehr bedeutend schneller.

Weil Götz gerne mit dem LC475 vergleicht :-) Der hatte 32bit breites
RAM mit 80nsec Zugriffszeit drin. D.h. der hat schon mal für 16Bytes
überschlägig 320nsec benötigt, d.h. schafft beim Schreiben weniger als
die Hälfte und beim Lesen 2/3 des Durchsatzes.

> Ulkigerweise wurden die ATOMs mit In-Order execution erst hoch gelobt
> das sie diese Fehlerquellen vermeiden. Doch kürzlich las ich das die
> neueren nun auch "Schätzmeister" (out-of-order-exec) werden.

Die schreddern teilweise auch ihre Taktgeber bzw. haben einen Verschleiß
in der Taktlogik, was aktuell Cisco teuer zu stehen kommt.

> Wo soll diese Komplexität noch hin führen!? Turing-Maschine,
> Selbstlernende KI, SkyNet,???

Selbstschreddernde Teslas sind die Gegenwart ;-)

Du auf Deiner Insel wirst Dich noch wundern, wenn eines Tages so ein
selbstfahrendes Schiff Deine Insel plattfährt, weil die Software bei
eurem platten Land "da oben" am Horizont den direkten Weg in die Ostsee
ausmachte. Du wirst noch bei Navteq betteln, daß die ihr Kartenmaterial
fehlerfrei halten, bevor der erste 500m lange Seelenverkäufer Anlauf
nimmt und bei Dir im Vorgarten steht ;-)

Gruß, Ralf

[kay]

Am 08.02.2017 um 18:52 schrob Ralf Kiefer:

> kay wrote:
>
>> Ich weiß ja nicht welche Berechnungen der Chip kann.
>
> Er kann die 4 Grundrechenarten zzgl. die trigonometrischen Funktionen,
> e^x, 10^x, Logarithmen, Quadratwurzel sowie die vielen Konvertierungen
> und Vergleiche zwischen der Integer-Welt und seinen drei
> Floatingpoint-Formaten Single, Double und Extended. Letztere Variante
> rechnet 80bit breit. Und genau so breit sind die 8 internen

Das scheint mir so das übliche Einmaleins zu sein, denke ich.
IMHO hat der 80387 auch 80bit Breite. Und ich erinnere dunkel das SQRT
einer der generell häufiger nützlichen Funktionen war. Frag nicht wofür,
hab ich vergessen.


> AFAIR rechnet Apples SANE

ScannerAccessNowEasy? :)

> noch genauer, aber dadurch langsamer. Und ggf.
> sehr viel langsamer, weil es dieses Arithemetik-Paket auch auf dem Apple
> ][ und /// gab, d.h. auf einem 65C02 mit 1MHz.

Für den 65x02 gab es aber keine Hardware-FPU - soweit ich weiß. Das wäre
mal lustig geworden... in GEOS auf dem C-128 z.b.

> komplett in der FPU erledigt werden konnte. Und jetzt komm mir bitte
> nicht mit "billigen" Transputern, siehe unten ;-)

Ich wollte nicht behaupten die seien Billig. Obwohl ich damals als sie
raus kamen überrascht war das sie nicht teurer waren. Für mich privat
aber eh nutzlos und unerschwinglich.

> Jein. Es kommt drauf an, was die Software machen soll, und wie der Code
> dazu generiert wurde. Besonders auffällig war das Thema in den frühen
> 1990er Jahren, als die teureren Macs eine FPU hatten, die preisgünstige
> Linie jedoch nicht. Programme wie Photoshop profitierten in einzelnen
> Funktionen ungemein von einer FPU. So was wie Mandelbrötchen natürlich
> auch, was ich allerdings nicht zu den wichtigen Anwendungen zähle.

Ich auch nicht, darum das beispiel Raytracing. Das Grafiklastiges davon
Profitiert ist klar. Ich hatte Autocad auf einer 386DX und erst nur
einen FPU-Emulator. Mit dem 80387 ging das 'REGENALL' dann auch deutlich
flotter.

> welche Zwecke die FPU noch verwendet wurde: in den Modula-2-Bibliotheken
> in der OS-9-Welt fanden wir Code zur String-Konvertierung, die die FPU
> benutzt. Da hatte ein findiger Auskenner herausgefunden, daß die
> Datenformatkonvertierungsbefehle von der FPU schnelleren Code selbst für
> solche Aufgaben hergeben.

Nett. War OS-9 in Modula-2 geschrieben? Ich erinnere das ich damals
einen Modula-2 Compiler (IMHO) hatte, mich damit aber nie intensiver
befasste. Ich habe auch kein OS-9

"Irgendwie" hatte der C-64 übrigens doch einen Coprozessor. In die
Floppystation konnte man ja maschinenprogramme laden und dort ausführen.
Um z.b. so wichtige Anwendungen [Ähem, Räusper] zu benutzen wie mit dem
Stepper-Motor durch variabel getimte microschritte musik zu machen.

>> Vielleicht wäre ein Transputer doch besser, um mal wieder Bezug zum
>> Topic zu bekommen. ;)

> Erst der T800 bekam drei(!)
> 64bit-Floatingpoint-Register, aber eben keine 80bit, wie für den
> IEEE-754-Standard nötig waren.

Hmm, das Schöne bei den Transputern war doch auch das man die einzelnen
Nodes mehrfach untereinander vernetzten konnte (bis zu 4 Links
gleichzeitig, oder?) und das jeder einzelne lokalen Speicher hatte.
Frühes Grid-computing wenn ich das richtig erinnere. Aber da gab es
glaube ich ein limit von 16 Nodes oder ähnliches.

Nur wird wohl jede heutige CPU schneller Massivparallel arbeiten als
diese Alten Transputer. Also Absolut Folklore!

>> [6502]

>
> Mal wieder die alte Weisheit: der 6502 war einer der ersten
> erfolgreichen RISC-Chips mit 3 sehr schnellen internen Registern und 256
> ausgelagerten Registern :-)

Jaja, INT-Vektoren waren keine PC-erfindung.:)

>> Muss die alten Schmöker doch noch mal
>> raus kramen (Zaks u. Co.)
>
> Ich habe das 6502-Geschehen gerade im kopfinternen Cache :-) Denn ich

Vorsicht vor dem Stack-Overflow. ;) Musstest du denn keine Lizenzkosten
abdrücken für deine Memocopy? [Psst, ganz Leise]

> schreibe gerade an meinem universellen Disassembler, der im ersten
> Schritt die 8bit-Welt abdecken können soll. Vollstens konfigurierbar,
> quasi eine Fortführung vom DASM. Aus naheliegenden Gründen startete ich
> mit der 6502-Welt.

Cool. Etwa für DOS oder??? Ich meine wenn Universell dann....

No RISC no Fun. :)

>> und was Befehlszyklen angeht. Das nicht mal der
>> Hersteller genau angeben kann wie viele Zyklen seine CPU bei einem
>> Befehl braucht, halte ich irgendwie für Kontraproduktiv.

> [Motorola]

> Zykluszahlen genannt. Das ist wirklich nicht das Problem. Der Nutzer
> sollte nur die vielen Randbedingungen, Fußnoten und Sonderfälle kennen
> bzw. beim Zählen anwenden können. Und genau da habe _ich_ keine Lust

In einem Buch über 386/486 Architektur las ich über die unmenge an
Befehls Präfixe und suffixe die teils wohl drastische Auswirkungen auf
die Laufzeit haben. Angefangen von Möglichen Misalignement-strafen, das
sie nicht mehr in die; damals kurze pipeline passten (mehrfachzugriff)
u.a. Randbedingungen und Sonderfällen.

Da hab ich dann auch irgendwann das Handtuch geworfen. Nun ja, die x86
Welt mit ihren Segmenten/Selektoren ist ja eh verschrien, je nach dem
wen man fragt.

>> SRAM-Basiertes) Speichersystem.
>
> Nicht unbedingt nötig.

> DRAM 4-1-1-1 (burst read), Schreiben 2-1-1-1 (burst write). Zum
> Nachrechnen: 150nsec zum Schreiben oder 210nsec zum Lesen von 16Byte.
> Das sind extrapoliert 100MB/s schreibend und 72MB/s lesend. BTW im Jahr
> 1993. Das wird mit SRAMs nicht mehr bedeutend schneller.

Moment. Ich erinnere mich damals zu 386/486 Zeiten Cache-SRAMs gesehen
zu haben die m.E. nur eine Zugriffszeit von um die 7-10 nsec. gehabt
haben sollen. Und ich denke mir bei all den Fortschritten sollten doch
heute deutlich größere Speichermengen mit dem Tempo drin sein. Macht
aber offenbar keiner. Warum?

>> Ulkigerweise wurden die ATOMs mit In-Order execution erst hoch gelobt

> Die schreddern teilweise auch ihre Taktgeber bzw. haben einen Verschleiß
> in der Taktlogik, was aktuell Cisco teuer zu stehen kommt.

Hab davon gelesen. Soll ein Nicht näher spezifizierter "intel quality
issue" sein.

Ich frage mich derzeit ob mein Portwell WADE-8071 (ITX) evtl. auch davon
betroffen sein könnte. Einen Atom hat er, und die letzten Tage will er
videos nicht mehr schnell genug aus liefern, was vorher IMHO ging.
Booten tut er aber noch... :)

>> Wo soll diese Komplexität noch hin führen!? Turing-Maschine,
>> Selbstlernende KI, SkyNet,???
>
> Selbstschreddernde Teslas sind die Gegenwart ;-)

Naja, Wer zu Doof ist einen Fahrassistent richtig ein zu schätzen dem
sollte man so was besser nicht an vertrauen. Oder ihm eine Extra
Schulung/Prüfung aufbrummen. Quasi eine Tesla-MPU. :)

> Du auf Deiner Insel wirst Dich noch wundern, wenn eines Tages so ein
> selbstfahrendes Schiff Deine Insel plattfährt, weil die Software bei
> eurem platten Land "da oben" am Horizont den direkten Weg in die Ostsee
> ausmachte. Du wirst noch bei Navteq betteln, daß die ihr Kartenmaterial
> fehlerfrei halten, bevor der erste 500m lange Seelenverkäufer Anlauf
> nimmt und bei Dir im Vorgarten steht ;-)

Nix neues, mein Lieber. Denke an die "Pallas" oder an den Sylter
Inselkomiker.

Siehe hier:
http://www.manfred-degen.de/bilder/buch_vollaufkurs.jpg

Außerdem, so platt ist das hier nun auch nicht, mit all den Windrädern.
Und bevor so ein Pott die Küste erreicht wird ihn das Platte Meer aus
bremsen.

ich weiß ja nicht ob du es wusstest, aber wir haben hier den
"Nationalpark Wattenmeer" und selbst bei Flut kommt ein Kreuzfahrer nur
auf Sichtweite an die Insel ran, bevor er fest steckt.

Quasi eine Natürliche Schlickbremsanlage! Abgesehen davon sind die
Amrumer schon immer Freibeuter gewesen. Was vor der Insel strandet wird
geplündert. Da kennen wir gar nix ;-)

[Volker Borchert]

Ralf Kiefer wrote:

> kay wrote:
>
> > Ulkigerweise wurden die ATOMs mit In-Order execution erst hoch gelobt
> > das sie diese Fehlerquellen vermeiden. Doch kürzlich las ich das die
> > neueren nun auch "Schätzmeister" (out-of-order-exec) werden.
>
> Die schreddern teilweise auch ihre Taktgeber bzw. haben einen Verschleiß
> in der Taktlogik, was aktuell Cisco teuer zu stehen kommt.

Wiedennwodennwasdenn. Seit wann verbaut Cisco denn Intel.

--

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mc...@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert <v_bor...@despammed.com>

[Sven Hartge]

Volker Borchert <v_bor...@despammed.com> wrote:
> Ralf Kiefer wrote:
>> kay wrote:

>>> Ulkigerweise wurden die ATOMs mit In-Order execution erst hoch
>>> gelobt das sie diese Fehlerquellen vermeiden. Doch kürzlich las ich
>>> das die neueren nun auch "Schätzmeister" (out-of-order-exec) werden.
>>
>> Die schreddern teilweise auch ihre Taktgeber bzw. haben einen
>> Verschleiß in der Taktlogik, was aktuell Cisco teuer zu stehen kommt.

> Wiedennwodennwasdenn. Seit wann verbaut Cisco denn Intel.

Seit PIX/ASA. Die ASR 1001 haben auch Intel(kompatible) CPUs drin. (In
der 1002 sind mehrere PowerPC MPC85xx von NXP.)

[kay]

Am 08.02.2017 um 21:36 schrob Volker Borchert:

> Ralf Kiefer wrote:
>> kay wrote:
>>
>>> Ulkigerweise wurden die ATOMs mit In-Order execution erst hoch gelobt
>>> das sie diese Fehlerquellen vermeiden. Doch kürzlich las ich das die
>>

>> Die schreddern teilweise auch ihre Taktgeber bzw. haben einen Verschleiß
>> in der Taktlogik, was aktuell Cisco teuer zu stehen kommt.
>
> Wiedennwodennwasdenn. Seit wann verbaut Cisco denn Intel.

Offenbar stecken intel-SOCs (Avoton/Rangeley-Chips) in Meraki, NCS und
ISA Produkten

Guck mal hier: https://heise.de/-3619283
Da steht es genauer mit ein paar weiter führenden Links.

[Ralf Kiefer]

Volker Borchert wrote:

> Wiedennwodennwasdenn. Seit wann verbaut Cisco denn Intel.

https://heise.de/-3617122

https://heise.de/-3619283

Sorry für den Medienbruch, aber in Kurzfrom ist's so schneller (für
mich) :-)

Gruß, Ralf

[Ralf Kiefer]

kay wrote:

> Das scheint mir so das übliche Einmaleins zu sein, denke ich.

Ja natürlich, aber in einem Floatingpoint-Format.

> IMHO hat der 80387 auch 80bit Breite. Und ich erinnere dunkel das SQRT
> einer der generell häufiger nützlichen Funktionen war. Frag nicht wofür,
> hab ich vergessen.

Wenn's nicht irgendwelche Bildbearbeitung ist, dann vielleicht Krypto?

> > AFAIR rechnet Apples SANE
>
> ScannerAccessNowEasy? :)

<https://en.wikipedia.org/wiki/Standard_Apple_Numerics_Environment>

> Für den 65x02 gab es aber keine Hardware-FPU - soweit ich weiß. Das wäre
> mal lustig geworden... in GEOS auf dem C-128 z.b.

Es gab sogar Auswahl (für den Applebus):
<http://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Inter
face%20Cards/CPU/AE%20FastMath/>

<http://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Inter
face%20Cards/CPU/CCS%207811/>

So ein 68881 hat selbstverständlich auch ein 8bit-Bus-Interface:
<http://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Inter
face%20Cards/CPU/Innovative%20Floating%20Point%20Engine/>

> > komplett in der FPU erledigt werden konnte. Und jetzt komm mir bitte
> > nicht mit "billigen" Transputern, siehe unten ;-)
>
> Ich wollte nicht behaupten die seien Billig.

Deswegen die provokanten Gänsefüßchen :-)

> War OS-9 in Modula-2 geschrieben?

Nein, kein bißchen davon. Das ursprüngliche OS-9 aus den 1970er Jahren
für den 6809 war komplett in 8bit-Asembler geschrieben, das
darauffolgende OS-9 für 68k war teils in Assembler, teils in C
geschrieben, das spätere OS-9000, dem nach ein paar Jahren die letzten
drei Nullen gestrichen wurden, war nicht nur für 68k, sondern auch für
Intel, Arm, PPC und noch ein paar mehr, das war daher überwiegend in C
geschrieben.

Modula-2 wurde in meiner damaligen Firma genommen, weil an diesem
Software-Projekt rund 40 Entwickler beschäftigt waren und somit eine
"gewisse Systematik" vorherrschen sollte, die mit der damals üblichen
C-Programmierweise in Widerspruch stand.

> Ich erinnere das ich damals
> einen Modula-2 Compiler (IMHO) hatte, mich damit aber nie intensiver
> befasste.

Mein erster Kontakt mit Modula-2 war auf dem Apple //e als Compiler im
UCSD-Betriebssystem. Das wurde an der Uni Karlsruhe Mitte der 1980er
Jahre verbreitet. Später saßen die Studenten mit Modula-2 am Mac II (ab
WS 1987/88).

> "Irgendwie" hatte der C-64 übrigens doch einen Coprozessor. In die
> Floppystation konnte man ja maschinenprogramme laden und dort ausführen.
> Um z.b. so wichtige Anwendungen [Ähem, Räusper] zu benutzen wie mit dem
> Stepper-Motor durch variabel getimte microschritte musik zu machen.

Naja ...

Hier sind im Apple-][-Fundus Karten mit einem 1802 oder einem 8748 als
I/O-Prozessor für die Druckerschnittstelle und ein 6511 als universelle
Koprozessorkarte.

Es gab Applebus-Karten mit 6809, 68008, 68000, Z80 (echt paralleler
Betrieb im Gegensatz zur üblichen M$-Karte), 8088, 8086 und noch einige
mehr.

> Hmm, das Schöne bei den Transputern war doch auch das man die einzelnen
> Nodes mehrfach untereinander vernetzten konnte (bis zu 4 Links
> gleichzeitig, oder?) und das jeder einzelne lokalen Speicher hatte.

Ja. Die Transputer-Chips hatten alle eine kleine, aber für einfache
Sachen ausreichende Menge SRAM im Chip und konnten bei Bedarf mit sehr
viel mehr ausgestattet werden.

Ich habe endlich nach Jahren eine Erwähnung im Netz gefunden, wo ich ein
bißchen mit dran "basteln" durfte :-) Der Hersteller war Proteus in
Karlsruhe:
http://www.sciencedirect.com/science/article/pii/0010465589900118
Das waren zwei richtig schöne 19"-Schränke :-)

> Frühes Grid-computing wenn ich das richtig erinnere. Aber da gab es
> glaube ich ein limit von 16 Nodes oder ähnliches.

Solch ein Limit ist mir nicht bekannt. Vielleicht gab's in einzelnen
Transputer-Chips (anfangs) Probleme mit den Links, aber keine
generellen, AFAIR. Es gab allerdings ein physisches Problem mit den
Links, die eine gewisse Länge nicht überschreiten durften. Aber wie bei
Netzwerkprotokollen lag das an der Ausbreitungsgeschwindigkeit der
Signale und der maximalen Antwortzeit im Protokoll. Wir hatten das mal
nachgerechnet. Nur verschwimmen meine Erinnerungen, und ganz dunkel
meine ich mich an einige 100m maximaler Link-Länge aufgrund des
Protokolls zu erinnern. Leitungstreiber wären noch eine andere Baustelle
geworden.

> Nur wird wohl jede heutige CPU schneller Massivparallel arbeiten als
> diese Alten Transputer. Also Absolut Folklore!

In diesem Punkt ja, aber solche alten CPUs haben durchaus auf manchen
Gebieten ihre Vorteile: ihr Interruptverhalten ist deutlich besser für
Realtime geeignet, weil die in der Interrupt-Latenz einfach schneller
sind. Große Registersätze moderner CPUs, auch und insbesondere interne
Frames aus den Pipelines, brauchen viel Platz auf dem Stack und somit
Zeit diese rauszuschreiben. Krass am Ende der Skala liegt z.B. so ein
65C02 mit einer Latenz von max. 7 Zyklen für den längstdauernden Befehl
zzgl. 4 Zyklen (oder so) für den Einsprung in den IRQ sowie 3*2 Zyklen
zur Rettung des Registersatzes extrem gut im Rennen, also max. 17 Zyklen
und der steht vor dem ersten Befehl der IRQ-Bearbeitung.

> > schreibe gerade an meinem universellen Disassembler, der im ersten
> > Schritt die 8bit-Welt abdecken können soll. Vollstens konfigurierbar,
> > quasi eine Fortführung vom DASM. Aus naheliegenden Gründen startete ich
> > mit der 6502-Welt.
>
> Cool. Etwa für DOS oder??? Ich meine wenn Universell dann....

Ich habe vorhin etwas gebingt: es gibt einen Assembler, der sich DASM
nennt. Ich meinte als Disassembler den DASMx, verlinkt z.B. auf
6502.org.

Momentan schreibe ich den aufgrund äußerer Umstände auf einer *schäm*
Windows-10-Kiste (ich hatte keine andere Wahl, und es nicht mein Rechner
;-) ) mit Visual Studio und in C++. Da ich aber sehe, wie sich so ein
moderner PC trotz vieler Kerne, fast 3GHz für die CPU und 16GB RAM mit
C++ rumplagt, ziehe ich die Textdateien in ein paar Wochen auf mein OS-9
mit 68060 @60MHz und natürlich nach C rüber, und ich bin mir sicher, daß
das dann performanter läuft. Da die einzigen relevanten Schnittstellen
die zum Dateisystem sind, das sowieso ein Progrämmchen mit UI ohne 'G'
ist, könnte ich vielleicht drüber nachdenken, ob ich das unter Ubuntu
zum Laufen bringe. Schaunmermal :-) Ich brauche den für den 6802 der
Eurocom 1 und zuallererst noch für einen Mitsubishi-Controller mit
6502-Kern, der im Tacho/Tripmaster von meinem Mopped sitzt, wo die
Software einen kleinen, aber bedeutenden Fehler hat. Ist Dir schon mal
der Tacho an Deinem Fahrzeug abgestürzt?

Danach ist der Code der RCA1802-Karte vom Apple ][ dran. Und die
ISA-Localtalk-Karte mit dem 6502, den Code vom 8748 aus dem Apple ][
wollte ich mir auch schon mal anschauen, und ... und ... und ...

> > DRAM 4-1-1-1 (burst read), Schreiben 2-1-1-1 (burst write). Zum
> > Nachrechnen: 150nsec zum Schreiben oder 210nsec zum Lesen von 16Byte.
> > Das sind extrapoliert 100MB/s schreibend und 72MB/s lesend. BTW im Jahr
> > 1993. Das wird mit SRAMs nicht mehr bedeutend schneller.
>
> Moment. Ich erinnere mich damals zu 386/486 Zeiten Cache-SRAMs gesehen
> zu haben die m.E. nur eine Zugriffszeit von um die 7-10 nsec. gehabt
> haben sollen. Und ich denke mir bei all den Fortschritten sollten doch
> heute deutlich größere Speichermengen mit dem Tempo drin sein. Macht
> aber offenbar keiner. Warum?

Diese 68040- und 68060-CPUs haben Zugriff auf das gesamte DRAM in dieser
Geschwindigkeit, also volle 256MB, nicht bloß ein paar kB Cache. BTW
schneller als 1-1-1-1 könnten die gar nicht. Nochwas: wenn der (externe)
Cache nicht liefern kann, dauern die Lesezugriffe etwas länger als wenn
kein Cache im Spiel wäre.

Gruß, Ralf

[Goetz Hoffart]

Ralf Kiefer <R.Kiefe...@gmx.de> wrote:

> Weil Götz gerne mit dem LC475 vergleicht :-) Der hatte 32bit breites
> RAM mit 80nsec Zugriffszeit drin. D.h. der hat schon mal für 16Bytes
> überschlägig 320nsec benötigt, d.h. schafft beim Schreiben weniger als
> die Hälfte und beim Lesen 2/3 des Durchsatzes.

Allerdings ging der halt auch für 1298 DM über die Theke. Ein prima
Preis-Leistungsverhältnis für 68k-Fans in der Zeit.

[Michael Heinrich]

Ralf Kiefer <R.Kiefe...@gmx.de> wrote:
> kay wrote:
>
>> Das scheint mir so das übliche Einmaleins zu sein, denke ich.
>
> Ja natürlich, aber in einem Floatingpoint-Format.
>
>
>> IMHO hat der 80387 auch 80bit Breite. Und ich erinnere dunkel das SQRT
>> einer der generell häufiger nützlichen Funktionen war. Frag nicht wofür,
>> hab ich vergessen.
>
> Wenn's nicht irgendwelche Bildbearbeitung ist, dann vielleicht Krypto?
>

Wurzel ziehen.

-Micha.