expertenaustausch > alt.* > alt.folklore.computer

Andreas Kohlbach (12.03.2017, 19:54)
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?
Christian Corti (12.03.2017, 20:26)
Andreas Kohlbach <ank> wrote:
> 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
kay (12.03.2017, 21:58)
Am 12.03.2017 um 19:54 schrob 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
Marcel Mueller (12.03.2017, 22:26)
On 12.03.17 20.26, Christian Corti wrote:
> Andreas Kohlbach <ank> wrote:
>> 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.

> Das Problem an der Geschichte ist der hohe Aufwand im Mikrocode bzw. der
> Hardware.


Und vor allem ziemlich unflexibel.

Marcel
Ralf Kiefer (12.03.2017, 22:59)
Andreas Kohlbach wrote:

> 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!

> 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 (12.03.2017, 23:13)
Andreas Kohlbach wrote:

[...]
> 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>
Michael van Elst (13.03.2017, 08:32)
kay <kay> writes:

>Am 12.03.2017 um 19:54 schrob 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.

--
Stefan Reuther (13.03.2017, 09:37)
Am 12.03.2017 um 19:54 schrieb 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
> ist. Das Thema dort:
> | A proposed inexpensive microprocessor that can directly execute a
> | high-level language. [...]
> 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
Klemens Krause (13.03.2017, 09:59)
Andreas Kohlbach wrote:
> Das BYTE Magazin hatte während seines Bestehens oft gute Voraussagen für ....
> | A proposed inexpensive microprocessor that can directly execute a
> | high-level language .....
> 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
Christian Corti (13.03.2017, 12:25)
Stefan Reuther <stefan.news> wrote:
> 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...


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.

> 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
Michael Engel (13.03.2017, 12:46)
Am Sonntag, 12. März 2017 19:54:11 UTC+1 schrieb Andreas Kohlbach:
> Das BYTE Magazin hatte während seines Bestehens oft gute Voraussagenfü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 nachFormat)
> 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:

(eines der Exemplare liegt hier auf meinem Schreibtisch...)



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:



-- Michael
Martin Peters (13.03.2017, 14:21)
Marcel Mueller schrieb:
[..]
> 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 (13.03.2017, 16:36)
Martin Peters wrote:
....
> 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 (13.03.2017, 16:53)
Marcel Mueller wrote:
> On 12.03.17 20.26, Christian Corti wrote:
> 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.
> 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.

>> 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 (13.03.2017, 21:32)
On 13.03.17 16.53, Klemens Krause wrote:
> Marcel Mueller wrote:
> ...
> 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.

> 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.

>>> 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

Ähnliche Themen