Discussion:
Hochsprache direkt für Mikroprozessoren
(zu alt für eine Antwort)
Andreas Kohlbach
2017-03-12 18:54:10 UTC
Permalink
Raw Message
Das BYTE Magazin hatte während seines Bestehens oft gute Voraussagen für
die Zukunft gemacht. Eben lese ich die 1/1983 Ausgabe, wo dem nicht so
ist. Das Thema dort:

| A proposed inexpensive microprocessor that can directly execute a
| high-level language.

Hier <https://archive.org/details/byte-magazine-1983-01> kann man ein
Format zur Ansicht wählen. Der Artikel müsste irgendwo (je nach Format)
aber Seite 600, etwa in der Hälfte, zu finden sein.

Als Kandidat wird dort FORTH genannt, auch weil es viel mit Stack
arbeitet.

Unüberlegt IMO die Aussage, dass Compiler unerwünscht sind, weil teuer
und sie viel RAM brauchen. 1982, als der Artikel geschrieben wurde,
sollte man schon gesehen haben, dass sich das mit den Kosten sehr bald
zum Positiven wenden wird.

Aber nun ist es AFAIK nicht dazu gekommen, Hochsprachen direkt vom
Prozessor ausführen zu lassen. Woran liegt das? Eben weil Compiler und
RAM schnell billig wurden?
--
Andreas
You know you are a redneck if
you ever driven down the road with your seat belt hanging out of
the door making sparks.
Christian Corti
2017-03-12 19:26:21 UTC
Permalink
Raw Message
Post by Andreas Kohlbach
Aber nun ist es AFAIK nicht dazu gekommen, Hochsprachen direkt vom
Prozessor ausführen zu lassen. Woran liegt das? Eben weil Compiler und
Doch, Wang 2200 haben BASIC direkt "interpretiert", das war quasi die
Maschinensprache. Das BASIC war entsprechend flott.
Das Problem an der Geschichte ist der hohe Aufwand im Mikrocode bzw. der
Hardware.

Christian
Marcel Mueller
2017-03-12 21:26:20 UTC
Permalink
Raw Message
Post by Christian Corti
Post by Andreas Kohlbach
Aber nun ist es AFAIK nicht dazu gekommen, Hochsprachen direkt vom
Prozessor ausführen zu lassen. Woran liegt das? Eben weil Compiler und
Doch, Wang 2200 haben BASIC direkt "interpretiert", das war quasi die
Maschinensprache. Das BASIC war entsprechend flott.
Stimmt. Das Ding war in BASIC etwa so schnell wie ein C64 in Assembler.

Allerdings haben die Kisten BASIC nie direkt interpretiert. Die Systeme
haben im Editor das Basic schon tokenisiert. Und dieser Code wurde dann
interpretiert. 7 Bit waren ASCII und die oberen 128 Werte waren die
Token für die ganzen BASIC-Befehle. Das hat auch eine ganze Menge
Speicher gespart.

Ich hatte mal die BASIC-Dateien auf der Platte per Direktzugriff
geöffnet. Dann konnte man mit Kenntnis des echten Quellcodes die
Codierung recht leicht entschlüsseln. Es gab sogar ein paar
undokumentierte Befehle, und ich meine jetzt nicht $INIT.

Ich habe aber nie so genau heraus bekommen, mit welcher Hardware das
gelöst wurde. Da waren zwar jede Menge 74-er Gräber drin, aber so
richtig eine CPU konnte ich nicht identifizieren. Nur im Terminal, da
steckte ein Z80.
Post by Christian Corti
Das Problem an der Geschichte ist der hohe Aufwand im Mikrocode bzw. der
Hardware.
Und vor allem ziemlich unflexibel.


Marcel
Martin Peters
2017-03-13 13:21:42 UTC
Permalink
Raw Message
Post by Marcel Mueller
Post by Christian Corti
Post by Andreas Kohlbach
Aber nun ist es AFAIK nicht dazu gekommen, Hochsprachen direkt vom
Prozessor ausführen zu lassen. Woran liegt das? Eben weil Compiler und
Doch, Wang 2200 haben BASIC direkt "interpretiert", das war quasi die
Maschinensprache. Das BASIC war entsprechend flott.
Stimmt. Das Ding war in BASIC etwa so schnell wie ein C64 in Assembler.
Allerdings haben die Kisten BASIC nie direkt interpretiert. Die Systeme
haben im Editor das Basic schon tokenisiert. Und dieser Code wurde dann
interpretiert. 7 Bit waren ASCII und die oberen 128 Werte waren die
Token für die ganzen BASIC-Befehle. Das hat auch eine ganze Menge
Speicher gespart.
Ich hatte mal die BASIC-Dateien auf der Platte per Direktzugriff
geöffnet. Dann konnte man mit Kenntnis des echten Quellcodes die
Codierung recht leicht entschlüsseln. Es gab sogar ein paar
undokumentierte Befehle, und ich meine jetzt nicht $INIT.
Mir ist nicht klar, was an diesem Tokenizing hier staendig so
hervorzuheben ist (vor ein paar Monaten schon einmal). Ich kenne das
seit jeher so und glaube nicht, dass es einen BASIC-_Interpreter_ (mit
Kommandomodus) auf diesem Planeten gibt oder gab, der das je anders
gemacht hat. Wenn doch wuerde ich mich ueber einen Hinweis freuen.

Schluesselworte, Zahlen u.v.m. bekommen bei praktisch allen
BASIC-Interpretern eine interne Darstellung und im Befehlsmodus wird
jeder Eingabe sofort in diese interne Darstellung umgewandelt, egal, ob
es eine Programmeingabe (mit Zeilennummer) ist oder ein Kommando, das
sofort ausgefuehrt wird. Ein LIST-Kommando (oder wie es sonst noch
heissen koennte) wandelt diese interne Darstellung wieder in ein
lesbares Programm um, wobei irrelevante Informationen aus der
Programmausgabe in der internen Darstellung oft garnicht beurecksichtigt
werden, z.B. manchmal mehrere Leerzeichen, Gross-/Kleinschreibung,
uebergenau Konstanten u.s.w. Auch ob z.B. ein "?" oder ein
"PRINT"-Kommando urspruenglich eingegeben wurde, ist fuer die interne
Darstellung irrelevant.
Klemens Krause
2017-03-13 15:36:08 UTC
Permalink
Raw Message
Martin Peters wrote:
...
Post by Martin Peters
Mir ist nicht klar, was an diesem Tokenizing hier staendig so
hervorzuheben ist (vor ein paar Monaten schon einmal). Ich kenne das
seit jeher so und glaube nicht, dass es einen BASIC-_Interpreter_ (mit
Kommandomodus) auf diesem Planeten gibt oder gab, der das je anders
gemacht hat. Wenn doch wuerde ich mich ueber einen Hinweis freuen.
Schluesselworte, Zahlen u.v.m. bekommen bei praktisch allen
BASIC-Interpretern eine interne Darstellung und im Befehlsmodus wird
jeder Eingabe sofort in diese interne Darstellung umgewandelt, egal, ob
Hinweis:
CINET-BASIC auf dem na?

Eingabe:
10 LET X=3
20 PRINT X
30 PRI X
40 PRINTXYZ X
LIST
0010 LET X=3
0020 PRINT X
0030 PRI X
0040 PRINTXYZ X
RUN
3.
3.
3.

Daraus folgt: dieses BASIC speichert den Text ab, wie er ist, beim
Interpretieren schaut es sich die ersten drei Zeichen an und überliest
den Rest bis zum nächsten Blank, oder Sonderzeichen.
Ich denke, dass es die meisten Tiny-Basics auch so gemacht haben.
Schliesslich kostet die Tokenisier- und die Detokenisier-Routine ebenfalls
Speicherplatz.

Ich vermute, irgendeiner hat mal damit angefangen und danach haben es alle
anderen nachgemacht.

Ich hoffe, ich konnte Dich hiermit erfreuen. ;-)

Klemens
Klemens Krause
2017-03-13 15:53:11 UTC
Permalink
Raw Message
...
Post by Marcel Mueller
Post by Christian Corti
Doch, Wang 2200 haben BASIC direkt "interpretiert", das war quasi die
Maschinensprache. Das BASIC war entsprechend flott.
...
Post by Marcel Mueller
Allerdings haben die Kisten BASIC nie direkt interpretiert. Die Systeme
haben im Editor das Basic schon tokenisiert. Und dieser Code wurde dann
interpretiert. 7 Bit waren ASCII und die oberen 128 Werte waren die
Token für die ganzen BASIC-Befehle. Das hat auch eine ganze Menge
Speicher gespart.
Ich hatte mal die BASIC-Dateien auf der Platte per Direktzugriff
geöffnet. Dann konnte man mit Kenntnis des echten Quellcodes die
Codierung recht leicht entschlüsseln. Es gab sogar ein paar
undokumentierte Befehle, und ich meine jetzt nicht $INIT.
Das habe ich auch gemacht, beim WANG PCS-2, der war etwas später und
hatte seine BASIC-Maschinensprache schon in Halbleiter-ROMS. Die 2200er
hatten, glaube ich noch die gefädelten ROMs der Vorgänger WANG 600 und
WANG 700.
Post by Marcel Mueller
Ich habe aber nie so genau heraus bekommen, mit welcher Hardware das
gelöst wurde. Da waren zwar jede Menge 74-er Gräber drin, aber so
richtig eine CPU konnte ich nicht identifizieren.
Die hatten als ALU ein 74181, also ein 4-Bit-Bitslice. Und ich meine,
diese undokumentierten nicht-BASIC-Tokens hätten den oder einigen der
Funktionscodes des 74181 entsprochen.
Post by Marcel Mueller
Post by Christian Corti
Das Problem an der Geschichte ist der hohe Aufwand im Mikrocode bzw. der
Hardware.
Und vor allem ziemlich unflexibel.
eben. Auf der anderen Seite steht eben die Laderei von damals noch üblichen
Kassetten oder gar Lochstreifen.

Klemens




.
Marcel Mueller
2017-03-13 20:32:44 UTC
Permalink
Raw Message
Post by Klemens Krause
...
Post by Marcel Mueller
Post by Christian Corti
Doch, Wang 2200 haben BASIC direkt "interpretiert", das war quasi die
Maschinensprache. Das BASIC war entsprechend flott.
[...]
Ich habe aber nie so genau heraus bekommen, mit welcher Hardware das
gelöst wurde. Da waren zwar jede Menge 74-er Gräber drin, aber so
richtig eine CPU konnte ich nicht identifizieren.
Die hatten als ALU ein 74181, also ein 4-Bit-Bitslice.
Ja, die Biester waren da AFAIK drin. Aber die können nicht wirklich
viel, weit davon entfernt alleine nur den LET Befehl mit geklammerten
Expressions und Punkt vor Strich auszuführen. Selbst für damalige
Verhältnisse fand ich das ungewöhnlich diskret. Das hat mich eher an die
SMD-Gräber der alten Crays erinnert, nur eben als DIL.
Post by Klemens Krause
Und ich meine,
diese undokumentierten nicht-BASIC-Tokens hätten den oder einigen der
Funktionscodes des 74181 entsprochen.
Kann sein. Ich habe mal damit herumexperimentiert, die Dateien zu
manipulieren. Aber das ist eher in Abstürzen geendet. Das mag aber auch
daran liegen, dass ich nicht die richtigen Operanden hatte.
Post by Klemens Krause
Post by Marcel Mueller
Post by Christian Corti
Das Problem an der Geschichte ist der hohe Aufwand im Mikrocode bzw. der
Hardware.
Und vor allem ziemlich unflexibel.
eben. Auf der anderen Seite steht eben die Laderei von damals noch üblichen
Kassetten oder gar Lochstreifen.
Wir hatten bei der 2200SVP schon HDD und 8"-FDD. Beides hinreichend
schnell für die Klasse. Die Ladezeiten waren kein echtes Problem.

Kurze Zeit Später hatten wir aber eine DEC Kiste. Die hatte die
legendäre F11 CPU mit CIS-Coprozessor für String-Befehle. Das Ding hat
sich in Assembler fast so programmiert wie die Wang in BASIC -
jedenfalls mit gescheitem Makroassembler. Definitiv keine RISC-CPU.


Marcel
kay
2017-03-12 20:58:55 UTC
Permalink
Raw Message
Post by Andreas Kohlbach
| A proposed inexpensive microprocessor that can directly execute a
| high-level language.
Als Kandidat wird dort FORTH genannt, auch weil es viel mit Stack
arbeitet.
Bei Hochsprache und CPU fällt mir spontan nur Itanium ein. Aber bei
Forth erinnere ich dunkel das es damals zumindest eines; vielleicht nur
ein Test- System gab das diesen Spagat versuchte. Mehr erinnere ich
leider nicht mehr.

Und: War ADA nicht mit einem ähnlichen Ansatz angetreten?

Kay
--
Posted via SN
Michael van Elst
2017-03-13 07:32:14 UTC
Permalink
Raw Message
Post by Andreas Kohlbach
| A proposed inexpensive microprocessor that can directly execute a
| high-level language.
Als Kandidat wird dort FORTH genannt, auch weil es viel mit Stack
arbeitet.
Bei Hochsprache und CPU fällt mir spontan nur Itanium ein.
Vielleicht eher iAPX432.
--
--
Michael van Elst
Internet: ***@serpens.de
"A potential Snark may lurk in every tree."
Ralf Kiefer
2017-03-12 21:59:16 UTC
Permalink
Raw Message
Post by Andreas Kohlbach
Als Kandidat wird dort FORTH genannt, auch weil es viel mit Stack
arbeitet.
Mir fällt dazu die P-Maschine vom UCSD-System ein, die zumindestens
Pascal sehr kompakt kodiert, aber noch weit davon entfernt war
Native-Pascal auszuführen. Obwohl die P-Maschine meist in einer
Emulation lief, gab's die auch in Chips gegossen. Nur war dieser Rechner
nicht gerade einer der erfolgreichsten.

Falls Du dieses Thema verfolgen möchtest, schau Dir auch Transputer und
Occam an!
Post by Andreas Kohlbach
Aber nun ist es AFAIK nicht dazu gekommen, Hochsprachen direkt vom
Prozessor ausführen zu lassen. Woran liegt das? Eben weil Compiler und
RAM schnell billig wurden?
Ab Ende der 1980er Jahre war man für etliche Jahre eher den RISC-CPUs
zugewandt, also dem Gegenteil. Danach wurden die typischen PC-CPUs immer
mehr mit speziellen Befehlssatzerweiterungen ausgestattet, z.B. MMX oder
Altivec. Mit der Vielfalt der Befehlssatzvorräte war das Thema
vermutlich endgültig erledigt.

Die Inflation sogenannter Hochsprachen schafft die Prozessorentwicklung
heute ganz sicher nicht mehr. Die wären erst dann mit ihrem Stückchen
Silizium fertig, wenn die Sprache schon wieder auf dem absteigenden Ast
wäre. Bei der weitergegehenden Vorstellung, daß moderne,
objektorientierte Hochsprachen direkt ausgeführt werden könnten, grinse
ich :-) Da weiß ja schon der Coder nicht mehr, welcher Code
letztendlich ausgeführt wird (Stichworte automatische Typwandlungen,
Vererbung), wie soll das dann so eine CPU wissen, was sie ausführen
soll? ;-)

Gruß, Ralf
Arno Welzel
2017-03-12 22:13:03 UTC
Permalink
Raw Message
Andreas Kohlbach wrote:

[...]
Post by Andreas Kohlbach
Aber nun ist es AFAIK nicht dazu gekommen, Hochsprachen direkt vom
Prozessor ausführen zu lassen. Woran liegt das? Eben weil Compiler und
RAM schnell billig wurden?
Einerseits und andererseits, weil es einfach sehr viele Sprachen gibt,
teilweise sehr spezialisiert für bestimmte Anwendungsgebiete:

<http://www.99-bottles-of-beer.net/abc.html>
--
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de
Stefan Reuther
2017-03-13 08:37:01 UTC
Permalink
Raw Message
Post by Andreas Kohlbach
Das BYTE Magazin hatte während seines Bestehens oft gute Voraussagen für
die Zukunft gemacht. Eben lese ich die 1/1983 Ausgabe, wo dem nicht so
| A proposed inexpensive microprocessor that can directly execute a
| high-level language.
[...]
Post by Andreas Kohlbach
Aber nun ist es AFAIK nicht dazu gekommen, Hochsprachen direkt vom
Prozessor ausführen zu lassen. Woran liegt das? Eben weil Compiler und
RAM schnell billig wurden?
Verglichen mit 6502-Assembler ist x86-Assembler ziemlich High-Level:
Multiplikation/Division/Trigonometrie, Speicherschutz, Auf- und Abbau
von Stackrahmen, indexierte Adressierung, das ganze SIMD-Zeugs...

Letztlich hat man da schon einige Bausteine, die für eine Hochsprache
nötig sind, in den Chip reingenommen. Aber soweit gehen, dass der Chip
direkt den ASCII-Text liest, wollte nach meinem Verständnis auch der
BYTE-Artikel nicht.


Stefan
Christian Corti
2017-03-13 11:25:57 UTC
Permalink
Raw Message
Post by Stefan Reuther
Multiplikation/Division/Trigonometrie, Speicherschutz, Auf- und Abbau
von Stackrahmen, indexierte Adressierung, das ganze SIMD-Zeugs...
Du träumst wohl... ;-) Zumindest bei Standard-x86 gibt es bis auf zwei/drei
der oben genannten Dingen nichts.
Trigonometrie ist den Coprozessoren x87 vorbehalten. Speicherschutz erst
ab 80286. Stackrahmen erst ab 80186 (ENTER/LEAVE). SIMD-Zeugs jenseits
der klassischen x86.
Was Du meinst sind die heutigen Pseudo-x86, aber Du kannst die nicht mit
einem 20 Jahre älteren Prozessor vergleichen.
Post by Stefan Reuther
Letztlich hat man da schon einige Bausteine, die für eine Hochsprache
nötig sind, in den Chip reingenommen. Aber soweit gehen, dass der Chip
Nunja, da C gemeinhin auch als Hochsprache zählt, sei erwähnt, daß man
da eher Sachen, die der Prozessor kann, aus der Sprache entfernt hat
(insb. die Rotierbefehle) ;-)

Christian
Marcel Mueller
2017-03-13 20:54:16 UTC
Permalink
Raw Message
Post by Christian Corti
Post by Stefan Reuther
Multiplikation/Division/Trigonometrie, Speicherschutz, Auf- und Abbau
von Stackrahmen, indexierte Adressierung, das ganze SIMD-Zeugs...
Du träumst wohl... ;-) Zumindest bei Standard-x86 gibt es bis auf zwei/drei
der oben genannten Dingen nichts.
Trigonometrie ist den Coprozessoren x87 vorbehalten. Speicherschutz erst
ab 80286. Stackrahmen erst ab 80186 (ENTER/LEAVE). SIMD-Zeugs jenseits
der klassischen x86.
Was Du meinst sind die heutigen Pseudo-x86, aber Du kannst die nicht mit
einem 20 Jahre älteren Prozessor vergleichen.
Ack. Und das ist eigentlich alles zu zwei drittel nur Marketing-Müll mit
dem man versucht, dem Kunden neue CPUs schmackhaft zu machen. Software,
die diese ganzen Features wirklich sinnvoll nutzt, kann man nach wie vor
mit der Lupe suchen. Zuweilen fliegen die Features schneller wieder raus
als die Software sie jemals nutzt. Wer erinnert sich noch an 3DNow!? War
konzeptionell nicht schlecht, aber wen interessiert's?
Die allermeiste Zeit verbringen diese ganzen zusätzlichen
Funktionseinheiten damit, immer schneller zu warten. Abgesehen von
wenigen Spezialanwendungen, braucht das Zeug kein normaler Mensch.
Selbst die FPU dreht heute noch bei vielen Anwendungen Däumchen.
Post by Christian Corti
Post by Stefan Reuther
Letztlich hat man da schon einige Bausteine, die für eine Hochsprache
nötig sind, in den Chip reingenommen. Aber soweit gehen, dass der Chip
Nunja, da C gemeinhin auch als Hochsprache zählt, sei erwähnt, daß man
da eher Sachen, die der Prozessor kann, aus der Sprache entfernt hat
(insb. die Rotierbefehle) ;-)
Ja, leider. Aber die scheitern halt daran, dass man dazu erst mal eine
definierte Bitbreite braucht. Und darauf wollte man sich bei C nicht
festnageln lassen. Ob das im Nachhinein betrachtet ein Vorteil war,
lassen wir mal dahingestellt.

Ich habe erst kürzlich einen Expression-Parser geschrieben, der diese
Lücke füllt, mit >>< und ><< für ror und rol.


Marcel
Ralf Kiefer
2017-03-13 22:00:23 UTC
Permalink
Raw Message
Post by Marcel Mueller
Aber die scheitern halt daran, dass man dazu erst mal eine
definierte Bitbreite braucht. Und darauf wollte man sich bei C nicht
festnageln lassen.
C ist wann entstanden? Und auf welchen Sorten von CPUs gibt's C? Ich
definiere mir meine Bitbreiten selbst. Explizit und zentral. Wenn der
Quelltext später von einem Compiler zum nächsten umziehen sollte, geht
die Anpassung an einer Stelle nach ein paar Überlegungen wg.
Rechengenauigkeiten u.ä., und genau deswegen definiere *ich* das.
Post by Marcel Mueller
Ich habe erst kürzlich einen Expression-Parser geschrieben, der diese
Lücke füllt, mit >>< und ><< für ror und rol.
Wozu braucht man die Rotate-Anweisungen in einer Hochsprache außer in
Gerätetreibern?

Gruß, Ralf
Peter Heitzer
2017-03-14 08:59:10 UTC
Permalink
Raw Message
Post by Ralf Kiefer
Post by Marcel Mueller
Aber die scheitern halt daran, dass man dazu erst mal eine
definierte Bitbreite braucht. Und darauf wollte man sich bei C nicht
festnageln lassen.
C ist wann entstanden? Und auf welchen Sorten von CPUs gibt's C? Ich
definiere mir meine Bitbreiten selbst. Explizit und zentral. Wenn der
Quelltext später von einem Compiler zum nächsten umziehen sollte, geht
die Anpassung an einer Stelle nach ein paar Überlegungen wg.
Rechengenauigkeiten u.ä., und genau deswegen definiere *ich* das.
Post by Marcel Mueller
Ich habe erst kürzlich einen Expression-Parser geschrieben, der diese
Lücke füllt, mit >>< und ><< für ror und rol.
Wozu braucht man die Rotate-Anweisungen in einer Hochsprache außer in
Gerätetreibern?
In der Cryptographie z.B. Hier wird sehr oft geschoben und rotiert.
Sinnvoll wird es aber erst, wenn der Compiler native Rotierbefehle für die
jeweilige CPU erzeugt.
--
Dipl.-Inform(FH) Peter Heitzer, ***@rz.uni-regensburg.de
Stefan Reuther
2017-03-14 09:03:32 UTC
Permalink
Raw Message
Post by Christian Corti
Post by Stefan Reuther
Multiplikation/Division/Trigonometrie, Speicherschutz, Auf- und Abbau
von Stackrahmen, indexierte Adressierung, das ganze SIMD-Zeugs...
Du träumst wohl... ;-) Zumindest bei Standard-x86 gibt es bis auf zwei/drei
der oben genannten Dingen nichts.
Trigonometrie ist den Coprozessoren x87 vorbehalten. Speicherschutz erst
ab 80286. Stackrahmen erst ab 80186 (ENTER/LEAVE). SIMD-Zeugs jenseits
der klassischen x86.
Der Artikel ist von 1983. Da war der 80286 schon ein Jahr alt. Und der
x87 ist natürlich Bestandteil des x86-Ökosystems.
Post by Christian Corti
Was Du meinst sind die heutigen Pseudo-x86, aber Du kannst die nicht mit
einem 20 Jahre älteren Prozessor vergleichen.
Der Artikel bezog sich ja auf die damalige Zukunft. Für MMX musste man
damals 14 Jahre in die Zukunft schauen. Heute schaut man 20 Jahre in die
Vergangenheit.
Post by Christian Corti
Post by Stefan Reuther
Letztlich hat man da schon einige Bausteine, die für eine Hochsprache
nötig sind, in den Chip reingenommen. Aber soweit gehen, dass der Chip
Nunja, da C gemeinhin auch als Hochsprache zählt, sei erwähnt, daß man
da eher Sachen, die der Prozessor kann, aus der Sprache entfernt hat
(insb. die Rotierbefehle) ;-)
Solange der Compiler mir aus

uint32_t rol32(uint32_t a) {
return (a << 1) | (a >> 31);
}

wieder einen rol-Befehl macht, bin ich zufrieden.


Stefan
Ralf Kiefer
2017-03-14 10:32:40 UTC
Permalink
Raw Message
Post by Stefan Reuther
Solange der Compiler mir aus
uint32_t rol32(uint32_t a) {
return (a << 1) | (a >> 31);
}
wieder einen rol-Befehl macht, bin ich zufrieden.
Erzähl mal! :-) Welcher Compiler macht's, und welcher nicht? Bzw. mit
welchen Optimierungsoptionen und für welche CPU?

Gruß, Ralf

Klemens Krause
2017-03-13 08:59:11 UTC
Permalink
Raw Message
Post by Andreas Kohlbach
Das BYTE Magazin hatte während seines Bestehens oft gute Voraussagen für
...
Post by Andreas Kohlbach
| A proposed inexpensive microprocessor that can directly execute a
| high-level language
....
Post by Andreas Kohlbach
Aber nun ist es AFAIK nicht dazu gekommen, Hochsprachen direkt vom
Prozessor ausführen zu lassen. Woran liegt das?
...

Ich denke der große Vorteil der frei programmierbaren Computer ist ihre
Flexibilität. Und eine in Silizium gegossene Hochsprache ist starrer als
ein Betonklotz. Das gilt auch für den ganzen Commodore-Kinderkram, wo
das Basic "nur" in ROMs eingemeisselt ist.
Ein PDP-8 kann BASIC, kann LISP, kann COBOL, kann FORTRAN, kann ALGOL,
kann PASCAL, kann ...

btw: FORTH als "Hochsprache" zu bezeichnen, naja.

Klemens
Michael Engel
2017-03-13 11:46:41 UTC
Permalink
Raw Message
Post by Andreas Kohlbach
Das BYTE Magazin hatte während seines Bestehens oft gute Voraussagen für
die Zukunft gemacht. Eben lese ich die 1/1983 Ausgabe, wo dem nicht so
| A proposed inexpensive microprocessor that can directly execute a
| high-level language.
Hier <https://archive.org/details/byte-magazine-1983-01> kann man ein
Format zur Ansicht wählen. Der Artikel müsste irgendwo (je nach Format)
aber Seite 600, etwa in der Hälfte, zu finden sein.
Als Kandidat wird dort FORTH genannt, auch weil es viel mit Stack
arbeitet.
Relativ nah dran (und der Vollständigkeit halber sicher erwähnenswert) waren
die LISP-Maschinen, angefangen von den Forschungssystemen beim MIT und
bei Xerox bis zu kommerziellen Implementierungen bei Symbolics, LMI und TI.
Mittlerweile sind die auch ganz gut dokumentiert, auf den TI Explorern liefen
eine Reihe komplexer Anwendungen (Flugbuchungssystem der Swiss, Steuerung
des Atomkraftwerks in Cattenom).

Symbolics ist irgendwann in den 80er Jahren am allgemeinen KI-Desinteresse
gestorben, LMI hat ihre Technologie (da kam auch der NuBus her, der dann in
Macs und NeXTs landete) an TI verkauft. Die TI-Entwicklung ist dann (wie so
vieles Andere, z.B. Apollo-Workstations, die TI1500-Unix-Systeme, ...) von HP
aufgekauft und vernichtet worden...

Buchtip dazu: "The Architecture of Symbolic Computers" von Peter M. Kogge.

Im Zuge der 80er-Jahre KI-Forschung gab es dann auch Prozessoren, die
PROLOG-Code ausführen konnten, genaugenommen den Instruktionssatz
der oft verwendeten Warren Abstract Machine. Sowas gab's dann sogar in
einem Studentenprojekt an der TU Dortmund:

http://imgur.com/a/BWkxx (eines der Exemplare liegt hier auf meinem Schreibtisch...)

http://ls12-www.cs.tu-dortmund.de/daes/media/documents/publications/downloads/1993-eurochips-albrecht.pdf

Ansonsten gab's den CRISP und Hobbit (der im Prototyp der BeBox drinsteckte)
von AT&T, die für die Ausführung von C-Code entworfen wurden. Da hat David Ditzel
dran mitentwickelt, der später u.a. auch für die Transmeta-CPUs verantwortlich war.

Hier ist noch ein schöner Überblick:
http://www.cpushack.com/CPU/cpu7.html
https://github.com/larsbrinkhoff/awesome-cpus

-- Michael
Loading...