Mit Tachyonen und Gold-Chip gegen Handystrahlen...

[Thomas 'Tom' Malkus]

MaWin meinte:

Es ist die effizienteste Moeglichkeit, geladenen Code vor
anderem Code zu schuetzen. Man kann nicht mitten reinspringen,
man kann keine Daten manipulieren, und das funktioniert sogar,
wenn verschiedene Prozesse den Code nutzen.

Wenn du Programm A (mit Daten und Code) und Programm B (mit
Daten und Code) eine DLL C (mit Code, statischen Daten und
prozessbezogenen Daten) betrachtest, zur Steigerung noch
in Programm A ein Treiber D (mit Code, statischen Daten und
prozessbezogenen Daten) und in Programm B ein Treiber E
(mit Code, statischen Daten und prozessbezogenen Daten) dir
vorstellst, wobei Treiber D von C verwendet wird wenn es
durch A lief, nur mit den Zugriffsrechten von A erlaubt
(nur A hat die Signatur die eine Verwendung von D erlaubt),
und Treiber E von C verwendet wird bei Programm B nur mit
den Zugriffsrechten von B, und das ganze nicht nur zufaellig
(richtig programmiert), sondern systembedingt sicher sein
soll, sind Segmente mit Abstand das rechenzeiteffektivste.

Im Grunde stimmt es, weil es schon in die Hardware gegossen ist.

Flat Memory ist die einfachste Möglichkeit für die Entwicklung
aber nicht immer die die beste. Segmentierung ist aber auch
nicht immer schön. Es hat halt alles seine Vor- und Nachteile.

73 de Tom
--
Thomas 'Tom' Malkus, DL7BJ
Locator JO43GC * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19

 

[MaWin]

"Gunther Mannigel" <newsgroups@mannigel.net> schrieb im Newsbeitrag
news:612utdF1tom4bU2@mid.individual.net...

Damals, als auf dem Mac zum umschalten zwischen zwei Programmen noch die
ersten 128kB umkopiert wurden?

Damals, als der Mac noch eine 68k hatte, heute ist es aber auch
nicht anders, man bildet Segmentierung mit langsamen Software-Kruecken
nach, egal ob PowerPC oder Pentium, auch unter Windows.
--
Manfred Winterhoff

 

[Falk Brunner]

MaWin schrieb:

Damals, als der Mac noch eine 68k hatte, heute ist es aber auch
nicht anders, man bildet Segmentierung mit langsamen Software-Kruecken
nach, egal ob PowerPC oder Pentium, auch unter Windows.

???
Und was macht die MMU? Däumchen drehen?

MFg
Falk

 

[Gerrit Heitsch]

MaWin wrote:

"Gerrit Heitsch" <gerrit@laosinh.s.bawue.de> schrieb im Newsbeitrag
news:fogjst$uva$1@news.bawue.net...

Segmentierung gab es keine (wozu auch?)

Tja, lern noch ein paar Jahre, vielleicht begreifst du dann.

Es gibt genug Beweise dafuer, dass man sie nicht braucht.
Diverse Multitasking-OS incl. shared libs auf 680x0 beweisen
dieses.

Wozu ist das gut?

Es ist die effizienteste Moeglichkeit, geladenen Code vor
anderem Code zu schuetzen. Man kann nicht mitten reinspringen,
man kann keine Daten manipulieren, und das funktioniert sogar,
wenn verschiedene Prozesse den Code nutzen.

Sowas macht man per MMU und nicht per Segmentregister. Letzteres
schuetzt naemlich nicht gegen boeswillen Code. Die Segmentierung
gabs beim x86 nur weil man sonst Probleme hatte mit 16Bit-Registern
mehr als 64KB anzusprechen. War ein Hack den wirklich keiner braucht.

Macintosh, gilt aber auch fuer Amiga und Sun, war wohl A5
statt A13, richtig, halt das vorletzte Adressregister als
Datensegmentzeiger, verwaltet ja der Compiler, da merkt
man sich die Nummer nicht.

Du kennst merkwuerdige 680x0... Das einzige Spezialregister
war A7, der Stackpointer. Alles andere hast du benutzen koennen
wie du wolltest.

Gerrit

 

[Falk Brunner]

Gerrit Heitsch schrieb:

Du kennst merkwuerdige 680x0... Das einzige Spezialregister
war A7, der Stackpointer. Alles andere hast du benutzen koennen
wie du wolltest.

Meine Rede. Die einzige Softwarekonvention war noch A6, das als
Basisregister für Library-aufrufe genutzt werden musste, Wenn ich ich
mich recht erinnere (puhh, ist schon laaange her, schön wars *seufs*)
Der 68000 hatte vollen 24 Bit Adressbus, die grossen Brüder dann 32 Bit
und die ganz grossen 040 und 060 sogar MMU (oder auch schon der 030?)

MfG
Falk

 

[Gerrit Heitsch]

Falk Brunner wrote:

Gerrit Heitsch schrieb:

Du kennst merkwuerdige 680x0... Das einzige Spezialregister
war A7, der Stackpointer. Alles andere hast du benutzen koennen
wie du wolltest.

Meine Rede. Die einzige Softwarekonvention war noch A6, das als
Basisregister für Library-aufrufe genutzt werden musste, Wenn ich ich
mich recht erinnere (puhh, ist schon laaange her, schön wars *seufs*)

A6 ist frei verwendbar, es haengt von deinem OS ab was damit
gemacht wird. Wenn du einen Microcontroller mit 68K-Core benutzt
und den Code selber schreibst brauchst du keine Ruecksicht zu
nehmen.

Der 68000 hatte vollen 24 Bit Adressbus, die grossen Brüder dann 32 Bit
und die ganz grossen 040 und 060 sogar MMU (oder auch schon der 030?)

Der 68030 hatte eine integrierte MMU, fuer den 68020 gab es eine
externe MMU.

Gerrit

 

[Falk Brunner]

Gerrit Heitsch schrieb:

A6 ist frei verwendbar, es haengt von deinem OS ab was damit
gemacht wird. Wenn du einen Microcontroller mit 68K-Core benutzt

Ja, ich meinte implizit Amiga-OS, Kickstart!

und den Code selber schreibst brauchst du keine Ruecksicht zu
nehmen.

Schon klar.

Mfg
Falk

 

[Henry Kiefer]

Falk Brunner schrieb:

MaWin schrieb:

Falls du mal den 680x0 programmiert hast weisst du was
ich meine.

Genau. Keine Segmentregister, sondern A13 zweckentfremdet.
Da war bei 32k Daten Schluss (statt 64k) und Programme wurden

???
Welche Kiste war das denn? Der Amiga hat solchen Zirkus nicht gemacht.

Vielleicht meinte er einfach nur die Begrenzung beim original 68000 für
relative Sprungziele. Die ist nämlich auf 32K begrenzt gewesen.


- Henry


--
www.ehydra.dyndns.info

 

[Henry Kiefer]

MaWin schrieb:

Welche Kiste war das denn

Macintosh, gilt aber auch fuer Amiga und Sun, war wohl A5
statt A13, richtig, halt das vorletzte Adressregister als
Datensegmentzeiger, verwaltet ja der Compiler, da merkt
man sich die Nummer nicht.

Hm. Also ich habe Programmiererfahrung in Assembler auf Mac 68K. Die
sogenannten 'Segmente' wurden durch den 'Memory Manager' verwaltet. Die
Programme waren daher typischerweise in Brocken von max. 32K aufgeteilt,
die dann dynamisch nachgeladen wurden. Bei Speicherknappheit auch
gelöscht und notfalls wiederum geladen, wenn sie gebraucht wurden.

Das typische Symptom eines zugelaufenen Macs war dann auch das langsamer
werden und ständige Gerödel auf der Platte.


- Henry


--
www.ehydra.dyndns.info

 

[Henry Kiefer]

Gunther Mannigel schrieb:

MaWin schrieb:
Welche Kiste war das denn

Macintosh, gilt aber auch fuer Amiga und Sun, war wohl A5
statt A13, richtig, halt das vorletzte Adressregister als
Datensegmentzeiger, verwaltet ja der Compiler, da merkt
man sich die Nummer nicht.

Damals, als auf dem Mac zum umschalten zwischen zwei Programmen noch die
ersten 128kB umkopiert wurden?

Kenne ich nicht. Erkläre mal.


Gruß -
Henry



--
www.ehydra.dyndns.info

 

[Henry Kiefer]

Falk Brunner schrieb:

Gerrit Heitsch schrieb:

Du kennst merkwuerdige 680x0... Das einzige Spezialregister
war A7, der Stackpointer. Alles andere hast du benutzen koennen
wie du wolltest.

Meine Rede. Die einzige Softwarekonvention war noch A6, das als
Basisregister für Library-aufrufe genutzt werden musste, Wenn ich ich
mich recht erinnere (puhh, ist schon laaange her, schön wars *seufs*)
Der 68000 hatte vollen 24 Bit Adressbus, die grossen Brüder dann 32 Bit
und die ganz grossen 040 und 060 sogar MMU (oder auch schon der 030?)

Die 030 hatte als erste intern ne MMU. Aber warum bleibst du nicht bei 68K?


- Henry



--
www.ehydra.dyndns.info

 

[Heiko Nocon]

Henry Kiefer wrote:

Vielleicht meinte er einfach nur die Begrenzung beim original 68000 für
relative Sprungziele. Die ist nämlich auf 32K begrenzt gewesen.

Unsinn, das displacement war 16 Bit breit, konnte also 64k adressieren.

Nur manche Leute, denen die Geheimnisse der Binärarithmetik wohl auf
ewig verschlossen bleiben werden, kamen (und kommen) wohl mit der
Tatsache nicht klar, daß es "signed" war...

 

[Falk Brunner]

Henry Kiefer schrieb:

Vielleicht meinte er einfach nur die Begrenzung beim original 68000 für
relative Sprungziele. Die ist nämlich auf 32K begrenzt gewesen.

Das ist ja was anderes, und als relativer Sprung wohl ausreichend.

MfG
Falk

 

[Henry Kiefer]

Heiko Nocon schrieb:

Henry Kiefer wrote:

Vielleicht meinte er einfach nur die Begrenzung beim original 68000 für
relative Sprungziele. Die ist nämlich auf 32K begrenzt gewesen.

Unsinn, das displacement war 16 Bit breit, konnte also 64k adressieren.

Nur manche Leute, denen die Geheimnisse der Binärarithmetik wohl auf
ewig verschlossen bleiben werden, kamen (und kommen) wohl mit der
Tatsache nicht klar, daß es "signed" war...

Ich habe das nie nachkontrolliert. Der Compiler machte das automatisch.

Ansonsten finde ich deine Vermutung etwas frech.


- Henry


--
www.ehydra.dyndns.info

 

[Falk Brunner]

Henry Kiefer schrieb:

Die 030 hatte als erste intern ne MMU. Aber warum bleibst du nicht
bei 68K?

Öhhm, welcher Desktop PC mit brauchbarer Software hat die denn noch? Und
vor allem, welche 68k CPU hat die Leistung für einen heutigen PC? Der
Film ist doch schon längst zuende. Der Amiga ist schon längst in der
Bedeutungslosigkeit versunken. Bitte jetzt keine "aber bei mir im Keller
läuft noch mein A4000 mit Blabla PowerPC Karte und Graka und wasweiss ich".
Und im Embedded Bereich hab ich bisher noch kein Projekt mit 68K gemacht.

"Es war ne geile Zeit, es tut mir leid, es ist vorbei . . ."

MfG
Falk

 

[Henry Kiefer]

Falk Brunner schrieb:

Henry Kiefer schrieb:

Die 030 hatte als erste intern ne MMU. Aber warum bleibst du nicht
bei 68K?

Öhhm, welcher Desktop PC mit brauchbarer Software hat die denn noch? Und
vor allem, welche 68k CPU hat die Leistung für einen heutigen PC? Der
Film ist doch schon längst zuende. Der Amiga ist schon längst in der
Bedeutungslosigkeit versunken. Bitte jetzt keine "aber bei mir im Keller
läuft noch mein A4000 mit Blabla PowerPC Karte und Graka und wasweiss ich".
Und im Embedded Bereich hab ich bisher noch kein Projekt mit 68K gemacht.

"Es war ne geile Zeit, es tut mir leid, es ist vorbei . . ."

Ist es ein Zeichen von beginnende Umnachtung oder gesetzter gußeiserner
Mentalität, wenn man bei einer Plattform bleibt? Zumindest für Embedded.


Fragt -
Henry


--
www.ehydra.dyndns.info

 

[MaWin]

"MaWin" <me@private.net> schrieb im Newsbeitrag news:fohjh2$adi$1@online.de...


Falk, Gerrit, schoen euer endloser Thread der aus meinen News-Reader faellt,
aber sinnlos so lange ihr noch nicht mal ansatzweise nachvollzieht, was in
geschildertem Beispiel zu passieren hat, sondern palavert. Spielt weiter,
so belastet ihr euere Gehirn wenigstens nicht mit Erkenntnis.
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

 

[Heiko Nocon]

Henry Kiefer wrote:

Ich habe das nie nachkontrolliert. Der Compiler machte das automatisch.

Sag' ich doch: Leute, denen die Geheimnisse der Binärarithmetik auf ewig
verschlossen bleiben werden. Compilerbenutzer halt. Die sind auch noch
stolz darauf, daß ihr Compiler es "automatisch" (und vielleicht
automatisch falsch) macht. Sie sind nicht in der Lage oder willens,
sowas zu überprüfen. Sie nehmen es einfach hin und machen auch noch eine
Weisheit draus, die sie dann noch als "Fakt" öffentlich verbreiten.

Ansonsten finde ich deine Vermutung etwas frech.

Wo siehst du da eine Vermutung?

Der 68k erlaubt nunmal tatsächlich ein 16Bit-Displacement für relative
Sprünge. Das steht so in der Dokumentation des Befehlssatzes und ist
auch an vielen Millionen Exemplaren der CPU jederzeit nachprüfbar. Also
ich würde sowas definitiv als FAKT bezeichnen, nicht als Vermutung.

 

[Henry Kiefer]

Heiko Nocon schrieb:

Henry Kiefer wrote:

Ich habe das nie nachkontrolliert. Der Compiler machte das automatisch.

Sag' ich doch: Leute, denen die Geheimnisse der Binärarithmetik auf ewig
verschlossen bleiben werden. Compilerbenutzer halt. Die sind auch noch
stolz darauf, daß ihr Compiler es "automatisch" (und vielleicht
automatisch falsch) macht. Sie sind nicht in der Lage oder willens,
sowas zu überprüfen. Sie nehmen es einfach hin und machen auch noch eine
Weisheit draus, die sie dann noch als "Fakt" öffentlich verbreiten.

Das 'Fakt' stammt aus der Dokumentation von Apple. Dicke schwere Bücher.
Und nein, man hat nicht die Zeit oder Lust vor lauter Fehlersuche auch
noch die Wahrheit des Compilers zu überprüfen.

Der erste Code für Mac war in Pascal und Assembler geschrieben. Später
erst wurde C populär. Was Pascal in diesem Zusammenhang bedeutet, wirst
du wissen.

Ansonsten finde ich deine Vermutung etwas frech.

Wo siehst du da eine Vermutung?

Das du meinst ich könne nicht binär rechnen.

Der 68k erlaubt nunmal tatsächlich ein 16Bit-Displacement für relative
Sprünge. Das steht so in der Dokumentation des Befehlssatzes und ist
auch an vielen Millionen Exemplaren der CPU jederzeit nachprüfbar. Also
ich würde sowas definitiv als FAKT bezeichnen, nicht als Vermutung.

Und selbst wenn es so ist. Wenn der Compiler sich weigert, hat man
kaum/keine Chance.
Ich jedenfalls habe noch nie Segmente beim Mac mit mehr als 32K
absoluter Länge gesehen. Und ich habe ne Menge Code disassembliert.

Damit dürfte das Thema gegessen sein.


Gruß -
Henry



--
www.ehydra.dyndns.info

 

[Falk Brunner]

MaWin schrieb:

Falk, Gerrit, schoen euer endloser Thread der aus meinen News-Reader faellt,
aber sinnlos so lange ihr noch nicht mal ansatzweise nachvollzieht, was in
geschildertem Beispiel zu passieren hat, sondern palavert. Spielt weiter,
so belastet ihr euere Gehirn wenigstens nicht mit Erkenntnis.

Jaja, da isser wieder MaWin wie der leibt und lebt. Und immer hoch zu
Ross unterwegs. Der Pöbel ist es nicht würdig, des hohen Herrn Weisheit
zu vernehmen.

Schönen Abend noch.
Falk