Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.alt.folklore.computer > #49939 > unrolled thread

Re: Der erste Computer

Back to article view | Back to de.alt.folklore.computer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Der erste Computer "F. W." <me@home.invalid> - 2025-05-14 10:54 +0200
    Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-14 09:02 +0000
      Re: Der erste Computer "F. W." <me@home.invalid> - 2025-05-14 11:37 +0200
        Re: Der erste Computer Andreas Bockelmann <xotzil@gmx.de> - 2025-05-14 13:37 +0200
        Re: Der erste Computer Bernd Laengerich <Bernd.Laengerich@web.de> - 2025-05-14 13:47 +0200
        Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-05-14 13:43 +0200
          Re: Der erste Computer "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2025-05-14 11:57 +0000
          Re: Der erste Computer Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-14 13:57 +0200
            Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-05-14 19:07 +0200
              Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-14 20:09 +0200
                Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-15 04:43 +0200
              Re: Der erste Computer Andreas Bockelmann <xotzil@gmx.de> - 2025-05-14 20:16 +0200
                Re: Der erste Computer "F. W." <me@home.invalid> - 2025-05-15 07:06 +0200
                  Re: Der erste Computer Andreas Bockelmann <xotzil@gmx.de> - 2025-05-15 09:57 +0200
          Re: Der erste Computer "F. W." <me@home.invalid> - 2025-05-15 07:04 +0200
            Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-15 09:55 +0200
              Re: Der erste Computer "F. W." <me@home.invalid> - 2025-05-15 14:50 +0200
        Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-14 13:55 +0200
          Re: Der erste Computer "F. W." <me@home.invalid> - 2025-05-15 07:11 +0200
            Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-15 08:51 +0200
              Re: Der erste Computer "F. W." <me@home.invalid> - 2025-05-15 14:52 +0200
                Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-15 21:24 +0000
                  Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-16 06:38 +0200
                  Re: Der erste Computer Christian Corti <use@reply.to> - 2025-05-16 10:11 +0200
                    Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-16 12:45 +0200
              Re: Der erste Computer Bernd Laengerich <Bernd.Laengerich@web.de> - 2025-05-15 15:48 +0200
                Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-15 17:22 +0200
                  Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-05-15 22:57 +0200
                    Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-15 21:39 +0000
            Re: Der erste Computer Thomas Koenig <tkoenig@netcologne.de> - 2025-05-15 20:03 +0000
              Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-05-15 23:14 +0200
                Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-15 21:51 +0000
                Re: Der erste Computer Thomas Koenig <tkoenig@netcologne.de> - 2025-05-16 05:31 +0000
                  Re: Der erste Computer Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-16 10:47 +0200
                    Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-16 12:39 +0200
                    Re: Der erste Computer Thomas Koenig <tkoenig@netcologne.de> - 2025-05-16 14:37 +0000
                  Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-16 11:02 +0200
        Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-15 21:05 +0000
          Re: Der erste Computer "F. W." <me@home.invalid> - 2025-05-16 07:18 +0200
          Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-16 11:21 +0200
            Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-05-18 23:03 +0200
        Re: Der erste Computer Thomas Koenig <tkoenig@netcologne.de> - 2025-05-16 05:24 +0000
    Re: Der erste Computer michaelnoeusenet@mac.com (Michael Noe) - 2025-05-14 19:03 +0200
    Re: Der erste Computer Marcel Mueller <news.5.maazl@spamgourmet.org> - 2025-05-19 19:01 +0200
      Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-19 20:25 +0000
        Re: Der erste Computer Marcel Mueller <news.5.maazl@spamgourmet.org> - 2025-05-19 23:56 +0200
          Re: Der erste Computer Thomas Koenig <tkoenig@netcologne.de> - 2025-05-30 12:11 +0000
      Re: Der erste Computer Arno Welzel <usenet@arnowelzel.de> - 2025-05-24 13:01 +0200
        Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-24 20:44 +0000
          Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-25 08:09 +0200
            Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-25 15:03 +0000
              Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-25 21:43 +0200
                Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-25 20:53 +0000
                  Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-26 14:50 +0200
              Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-25 20:38 +0000
            Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-26 09:01 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#50014

Am 16.05.25 um 11:21 schrieb Peter J. Holzer:
> On 2025-05-15 23:05, Sebastian Barthel <naitsabes@freenet.de> wrote:
>> Allerdings: ein großer Geschwindigkeitsvorteil von Maschinensprache ist
>> ja, daß es eben nicht interpretiert werden muß. Der fällt dann hier weg.
> 
> Diese Pseudo-Assembler-Instruktionen zu interpretieren, wäre natürlich
> kontraproduktiv. Die müssten direkt in Maschinencode umgesetzt und zur
> Laufzeit einfach angesprungen werden. So schwierig stelle ich mir das
> nicht vor. 

Inline-Assembler ist aber nun auch keine neue Erfindung. So weit ich das 
sehe ist dessen Problem eher das Interface von der Hochsprache auf die 
jeweiligen Register gewesen, hin- und zurück.

Typische Interpreter-sprachen (wie BASIC) sind bei so was doch eh eher 
ungeeignet. In anderen Sprachen die sowieso durch einen Compiler ein zur 
Laufzeit ausführbares Programm erzeugen macht das viel mehr Sinn.

Und da gibt es dann auch keinen Zeitverlust - aber irgendwo auch keinen 
Sinn mehr da "hochsprachige" Mnemonics zu erfinden.

Bye/
   /Kay

-- 
Posted via Leafnode

[toc] | [prev] | [next] | [standalone]

#49975

F. W. <me@home.invalid> schrieb:
> Am 14.05.2025 um 11:02 schrieb Sebastian Barthel:
>
>> Am Wed, 14 May 2025 10:54:39 +0200 schrieb F. W.:
>
>>> Was ich mich frage ist, wie die Entwicklung der 
>>> Programmiersprachen verlaufen wäre, wenn man alle Sprachen von 
>>> Assembler abgeleitet hätte.
>> 
>> Wie meinst Du "abgeleitet" ?
>> 
>
> Hmm...also nehmen wir mal an, dass aus
>
> LDA #200
> STA $400
>
> in einer "Hochsprache" würde
>
> 10 DECLARE Buffer $400
> 20 REM Hauptprogramm
> 30 AKKULOAD 200
> 40 AKKUSTORE Buffer
>
> dann könnte das doch theoretisch auf den drei 6502-Maschinen Apple ][,
> C64 und Atari 800 XL sehr schnell laufen könnte. Ein "Compiler" müsste
> dann doch nur AKKULOAD durch LDA ersetzen.

Bis auf unterschiedliche Anzahl von Registern, Anzahl der Bits
pro Register und unterschiedliche Adressierungsarten...

Versuch mal den 6502 und den Z80 über diesen einheitlichen Kamm
zu scheren, und dann pack da gerade noch einen 68000 dazu.

[toc] | [prev] | [next] | [standalone]

#49951

F. W. <me@home.invalid> wrote:

> In schlaflosen Nächten denke ich, dass es schon auf den 8-Bit-Büchsen
> vielleicht rasend schnelle BASIC-Interpreter gegeben hätte.

Ich gehe da in schlaflosen Nächten eher den Speiseplan für die nächste
Woche durch. ;-)

> Ich sage mal "BlitzBasic" auf dem C64.

Das Locomotive BASIC auf dem Amstrad CPC in dessen ROM war damals
ziemlich flott. Und hatte zudem einen großen Befehlsumfang auch für
Grafik, Sound, Bandlaufwerk und Floppy (AMSDOS). (Wenn ich da im
Vergleich an den Commodore 64 samt Diskettenlaufwerksverwaltung out of
the box denke, dafür hatte der aber halt wieder andere Vorteile, vor
allem für Gamer...)

Mit Fabacom gab es zudem einen Compiler dafür.

Weiterhin gut erweiterbar über sogenannte RSX-Befehle.

<https://www.cpcwiki.eu/index.php/RSX>
<https://www.cpcwiki.eu/index.php/AMSDOS>

"RSX command extensions can be implemented through ROMs (like AMSDOS or
other disk operating systems) or by programs."

Auch heutige Hardwareerweiterungen à la DDI-5

<https://www.sellmyretro.com/offer/details/ddi-5-floppy-interface%2C-ub-emulator-and-512-ram-in-one-36061>

machen samt eingeblendeter Firmware regen Gebrauch davon, also beileibe
nicht nur das 3"(sic!)-Diskettenlaufwerk von Amstrad namens DDI-1/FD-1.

-- 

 Gruß

 Michael

[toc] | [prev] | [next] | [standalone]

#50040

Am 14.05.25 um 10:54 schrieb F. W.:
> Am 11.05.2025 um 21:45 schrieb Stefan Ram:
> 
>> Der erste Computer wurde am 12. Mai 1941 von Konrad Zuse vorgestellt. 
>> - Ist das nur die deutsche Geschichtsschreibung, und in
>> den USA sagt man statt dessen etwas anderes?
> 
> Die USA leben in ihrer Mitte. Da hat Vorteile und Nachteile.
> 
> Was ich mich frage ist, wie die Entwicklung der Programmiersprachen
> verlaufen wäre, wenn man alle Sprachen von Assembler abgeleitet hätte.
> 
> In schlaflosen Nächten denke ich, dass es schon auf den 8-Bit-Büchsen
> vielleicht rasend schnelle BASIC-Interpreter gegeben hätte.
> 
> Ich sage mal "BlitzBasic" auf dem C64.

Man kann und konnte fast jedes Programm schnell und langsam 
implementieren. Schnell erfordert mehr Aufwand und ggf. an der einen 
oder anderen Ecke ein paar Einschränkungen.
Wir hatten in '79 auch einen Computer, der in Basic ungefähr so schnell 
war, wie der 64-er in Maschinensprache. Natürlich größer, aber der 
eigentliche Trick war, dass der Editor schon Tokens statt Quellcode in 
die Dateien gespeichert hat. Die haben einfach die Symbole 0x80-0xff für 
die Tokens benutzt. Naja, und Variablen waren wie damals üblich stark 
längenbegrenzt.

Und umgekehrt gab es auch damals schon stark unterschiedliche Assembler. 
Von der Vollkatastrophe 8051 über den kaum besseren 6502 zu den immer 
noch nervigen 8080 auf der einen Seite zu einem Z80, den man schon 
halbwegs in Assembler programmieren konnte zu Motorola 68000, wo es 
schon angenehm wurde, bis hin zu DEC F11 mit diversen Coprozessoren 
(z.B.CIS), deren (Makro-)Assembler mehr konnte und sich sich besser 
programmiert hat, als die meisten Basics. Alles bisher genannte müsste 
so grob um die 1982 verfügbar gewesen sein. Beim 68k bin jetzt nicht 
ganz sicher. Aber eine DEC Kiste hatten wir damals. Und damit meine ich 
nicht eine VAX mit Drehstromanschluss, sondern ein normales PC-Gehäuse 
mit F11 und VMS.


Marcel

[toc] | [prev] | [next] | [standalone]

#50049

An einem Mon, 19 May 2025 19:01:31 +0200 schrieb der Meister Marcel
Mueller:

> Am 14.05.25 um 10:54 schrieb F. W.:
>> Am 11.05.2025 um 21:45 schrieb Stefan Ram:
>> 
>>> Der erste Computer wurde am 12. Mai 1941 von Konrad Zuse vorgestellt.
>>> - Ist das nur die deutsche Geschichtsschreibung, und in den USA sagt
>>> man statt dessen etwas anderes?
>> 
>> Die USA leben in ihrer Mitte. Da hat Vorteile und Nachteile.
>> 
>> Was ich mich frage ist, wie die Entwicklung der Programmiersprachen
>> verlaufen wäre, wenn man alle Sprachen von Assembler abgeleitet hätte.
>> 
>> In schlaflosen Nächten denke ich, dass es schon auf den 8-Bit-Büchsen
>> vielleicht rasend schnelle BASIC-Interpreter gegeben hätte.
>> 
>> Ich sage mal "BlitzBasic" auf dem C64.
> 
> Man kann und konnte fast jedes Programm schnell und langsam
> implementieren. Schnell erfordert mehr Aufwand und ggf. an der einen
> oder anderen Ecke ein paar Einschränkungen.
> Wir hatten in '79 auch einen Computer, der in Basic ungefähr so schnell
> war, wie der 64-er in Maschinensprache. Natürlich größer, aber der
> eigentliche Trick war, dass der Editor schon Tokens statt Quellcode in
> die Dateien gespeichert hat. Die haben einfach die Symbole 0x80-0xff für
> die Tokens benutzt. Naja, und Variablen waren wie damals üblich stark
> längenbegrenzt.

Das macht der C64 aber exakt genau so - speichert die Tokens und hat nur 
die ersten beiden Buchstaben von Variablennamen zur Kenntnis genommen.



> Und umgekehrt gab es auch damals schon stark unterschiedliche Assembler.
> Von der Vollkatastrophe 8051 über den kaum besseren 6502 zu den immer
> noch nervigen 8080 auf der einen Seite zu einem Z80, den man schon
> halbwegs in Assembler programmieren konnte zu Motorola 68000, wo es
> schon angenehm wurde, bis hin zu DEC F11 mit diversen Coprozessoren
> (z.B.CIS), deren (Makro-)Assembler mehr konnte und sich sich besser
> programmiert hat, als die meisten Basics. Alles bisher genannte müsste
> so grob um die 1982 verfügbar gewesen sein. Beim 68k bin jetzt nicht
> ganz sicher. Aber eine DEC Kiste hatten wir damals. Und damit meine ich
> nicht eine VAX mit Drehstromanschluss, sondern ein normales PC-Gehäuse
> mit F11 und VMS.

Micro VAX II oder eine 3100 evtl ?

Was ist denn am 6502 so schrecklich ? Der ist doch eigentlich recht 
"straight", nur daß man für alles was mit 16Bit ist quasi den Code immer 
doppeln muß, weil es ja nur 8Bit gibt und keine Ausreden.

Wenn Du eine Preistabelle der angegebenen CPUs machst, weißt Du auch ganz 
schnell, wo das so her kommt, daß sich diese Reihenfolge ergibt.


-- 
holy miau is a snake

[toc] | [prev] | [next] | [standalone]

#50054

Am 19.05.25 um 22:25 schrieb Sebastian Barthel:
>>> Ich sage mal "BlitzBasic" auf dem C64.
>>
>> Man kann und konnte fast jedes Programm schnell und langsam
>> implementieren. Schnell erfordert mehr Aufwand und ggf. an der einen
>> oder anderen Ecke ein paar Einschränkungen.
>> Wir hatten in '79 auch einen Computer, der in Basic ungefähr so schnell
>> war, wie der 64-er in Maschinensprache. Natürlich größer, aber der
>> eigentliche Trick war, dass der Editor schon Tokens statt Quellcode in
>> die Dateien gespeichert hat. Die haben einfach die Symbole 0x80-0xff für
>> die Tokens benutzt. Naja, und Variablen waren wie damals üblich stark
>> längenbegrenzt.
> 
> Das macht der C64 aber exakt genau so - speichert die Tokens und hat nur
> die ersten beiden Buchstaben von Variablennamen zur Kenntnis genommen.

Ah, OK. Aber der Interpreter war trotzdem extrem lahm. Selbst für die 
Hasengurke.

>> Und umgekehrt gab es auch damals schon stark unterschiedliche Assembler.
>> Von der Vollkatastrophe 8051 über den kaum besseren 6502 zu den immer
>> noch nervigen 8080 auf der einen Seite zu einem Z80, den man schon
>> halbwegs in Assembler programmieren konnte zu Motorola 68000, wo es
>> schon angenehm wurde, bis hin zu DEC F11 mit diversen Coprozessoren
>> (z.B.CIS), deren (Makro-)Assembler mehr konnte und sich sich besser
>> programmiert hat, als die meisten Basics. Alles bisher genannte müsste
>> so grob um die 1982 verfügbar gewesen sein. Beim 68k bin jetzt nicht
>> ganz sicher. Aber eine DEC Kiste hatten wir damals. Und damit meine ich
>> nicht eine VAX mit Drehstromanschluss, sondern ein normales PC-Gehäuse
>> mit F11 und VMS.
> 
> Micro VAX II oder eine 3100 evtl ?

Keine Ahnung mehr. Das hatte für mich damals keine Bedeutung.

> Was ist denn am 6502 so schrecklich ?

Der kann nichts und die Adressierungsarten sind krank.

> Der ist doch eigentlich recht
> "straight", nur daß man für alles was mit 16Bit ist quasi den Code immer
> doppeln muß, weil es ja nur 8Bit gibt und keine Ausreden.

Das außerdem.
Z80 war auch 8 Bit, aber hatte wenigstens so viel Befehlssatz, dass man 
damit einigermaßen sinnvoll im 16 Bit Memory Model programmieren konnte.

> Wenn Du eine Preistabelle der angegebenen CPUs machst, weißt Du auch ganz
> schnell, wo das so her kommt, daß sich diese Reihenfolge ergibt.

Hmm, Z80 war doch auch Billigkram. Und den fand ich schon um eine Klasse 
besser als 6502. Und irgendwie konnte man die Dinger gnadenlos 
übertakten. Habe schon welche bei 20 MHz laufen sehen. Umgekehrt konnte 
man zum Hardware-Debuggen den Takt auch komplett anhalten, da die Z80 
alle Zustände statisch gehalten haben, jedenfalls, wenn man sie mit SRAM 
betrieben hat.

Was die 68k damals gekostet haben, weiß ich nicht. Darauf habe ich erst 
einige Jahre später programmiert. Da waren sie allemal preiswerter als 
die 286-er, bei denen IBM mit OS/2 eindrucksvoll bewiesen hat, dass sie 
sich nicht für Betriebssysteme eignen. Ja, F11 hatte auch ein Segmented 
Memory Model, da musste man sogar erst einen Befehl an die MMU geben um 
an andere Speicherseiten zu kommen, aber so schlimm wie die 286er fand 
ich die nicht. Wenigstens war man da nicht die Hälfte der Zeit damit 
beschäftigt, Registerinhalte zu verschieben, weil jedes Register etwas 
anderes konnte.

Motorola hat dann wirklich Spaß gemacht. Da habe ich zum ersten mal 
Search as you type programmiert. Habe damals allerdings auch 4MB 
Speicher bei einem ahnungslosen Händler im "Preisausschreiben" gewonnen, 
der zu faul war, die echten Preise für Speicherchips nachzuschlagen. Man 
hat den Mitarbeiter dann später in die Buchhaltung versetzt - fragt 
sich, wo er mehr Schaden anrichten konnte.


Marcel

[toc] | [prev] | [next] | [standalone]

#50352

Marcel Mueller <news.5.maazl@spamgourmet.org> schrieb:
> Am 19.05.25 um 22:25 schrieb Sebastian Barthel:

>> Das macht der C64 aber exakt genau so - speichert die Tokens und hat nur
>> die ersten beiden Buchstaben von Variablennamen zur Kenntnis genommen.
>
> Ah, OK. Aber der Interpreter war trotzdem extrem lahm. Selbst für die 
> Hasengurke.

Microsoft halt.

Ja, das Commodore-Basic war von der Ursünde abgeleitet, dem
Altair-Basic, was damals der Anfang von Microsoft war.

[toc] | [prev] | [next] | [standalone]

#50179

Marcel Mueller, 2025-05-19 19:01:

> Am 14.05.25 um 10:54 schrieb F. W.:
[...]
> Wir hatten in '79 auch einen Computer, der in Basic ungefähr so schnell 
> war, wie der 64-er in Maschinensprache. Natürlich größer, aber der 
> eigentliche Trick war, dass der Editor schon Tokens statt Quellcode in 
> die Dateien gespeichert hat. Die haben einfach die Symbole 0x80-0xff für 
> die Tokens benutzt. Naja, und Variablen waren wie damals üblich stark 
> längenbegrenzt.

Tokens hat der C64 auch benutzt - schon deshalb, um Speicherplatz zu
sparen. "Text" hat man nur beim Bearbeiten gesehen, aber intern wurden
alle Befehle nur als Token gespeichert:

<https://www.c64-wiki.de/wiki/Token>

Das hilft aber nicht, wenn man eine 8-Bit-CPU mit unter 1 MHz
Taktfrequenz hat - besonders schnell ist die Ausführung eines
BASIC-Programms dann trotzdem nicht, weil der Token ja trotzdem
verarbeitet werden muss und nicht ein Token nur einem einzigen
CPU-Befehl entspricht.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#50205

An einem Sat, 24 May 2025 13:01:16 +0200 schrieb der Meister Arno Welzel:

> Marcel Mueller, 2025-05-19 19:01:
> 
>> Am 14.05.25 um 10:54 schrieb F. W.:
> [...]
>> Wir hatten in '79 auch einen Computer, der in Basic ungefähr so schnell
>> war, wie der 64-er in Maschinensprache. Natürlich größer, aber der
>> eigentliche Trick war, dass der Editor schon Tokens statt Quellcode in
>> die Dateien gespeichert hat. Die haben einfach die Symbole 0x80-0xff
>> für die Tokens benutzt. Naja, und Variablen waren wie damals üblich
>> stark längenbegrenzt.
> 
> Tokens hat der C64 auch benutzt - schon deshalb, um Speicherplatz zu
> sparen. "Text" hat man nur beim Bearbeiten gesehen, aber intern wurden
> alle Befehle nur als Token gespeichert:
> 
> <https://www.c64-wiki.de/wiki/Token>
> 
> Das hilft aber nicht, wenn man eine 8-Bit-CPU mit unter 1 MHz
> Taktfrequenz hat - besonders schnell ist die Ausführung eines
> BASIC-Programms dann trotzdem nicht, weil der Token ja trotzdem
> verarbeitet werden muss und nicht ein Token nur einem einzigen
> CPU-Befehl entspricht.

Genau. Und das allerschlimmste ist, daß die meisten Tokenlisten in den 
BASICs wohl nicht so geordnet sein werden, daß das schnell geht. Ich habe 
da schon solche case/switches gesehen, wo also jedesmal und für jedes 
Token eine Liste durchlaufen wird, bis zu dem Punkt, wo der Vergleich 
dann paßt.
( switch(a) { case 21 : do xyz ; break ; case 255 : do xyz1 ; } )

Und ganz lustig sind dann so Befehle, wo innerhalb eines Tokens nochmal 
abgefragt werden muß, wieviele Parameter nun da jetzt mitgekommen sind 
und an welcher Stelle. Bsp1: die Farbe kann bei einem Grafikbefehl 
mitgegeben werden, wobei es aber sowie eine Colour Anweisung gibt, die 
das festlegt. Bsp2: Rotationswinkel für Rechtecke. Bsp3: Kreis mit einem 
Radius, Ellipse, wenn ein zweiter Radius mitgegeben wird.


Letztlich macht das aber ein C Compiler auch nicht soviel anders. Nur, daß 
er eben die Tokens erstmal selbst aus dem Quellcode generiert und jedem 
Befehl eine "Nummer" gibt.

Der Unterschied ist v.a. auch der, daß man heut nicht mehr nur 8 Bit 
dafür benutzen kann/muß.


Variablenlängenbegrenzungen gab es durchaus auch woanders. Und auch heute 
dürften beliebig lange Variablennamen nicht direkt das Übliche sein. 
Irgendeine - sehr weit gesteckte - Obergranze gibt es da bestimmt auch 
immer noch.


Gruß
SBn

-- 
holy miau is a snake

[toc] | [prev] | [next] | [standalone]

#50212

On 2025-05-24 22:44, Sebastian Barthel <naitsabes@freenet.de> wrote:
> An einem Sat, 24 May 2025 13:01:16 +0200 schrieb der Meister Arno Welzel:
>
>> Marcel Mueller, 2025-05-19 19:01:
>> 
>>> Am 14.05.25 um 10:54 schrieb F. W.:
>> [...]
>>> Wir hatten in '79 auch einen Computer, der in Basic ungefähr so schnell
>>> war, wie der 64-er in Maschinensprache. Natürlich größer, aber der
>>> eigentliche Trick war, dass der Editor schon Tokens statt Quellcode in
>>> die Dateien gespeichert hat. Die haben einfach die Symbole 0x80-0xff
>>> für die Tokens benutzt. Naja, und Variablen waren wie damals üblich
>>> stark längenbegrenzt.
>> 
>> Tokens hat der C64 auch benutzt - schon deshalb, um Speicherplatz zu
>> sparen. "Text" hat man nur beim Bearbeiten gesehen, aber intern wurden
>> alle Befehle nur als Token gespeichert:
>> 
>> <https://www.c64-wiki.de/wiki/Token>
>> 
>> Das hilft aber nicht, wenn man eine 8-Bit-CPU mit unter 1 MHz
>> Taktfrequenz hat - besonders schnell ist die Ausführung eines
>> BASIC-Programms dann trotzdem nicht, weil der Token ja trotzdem
>> verarbeitet werden muss

Ich glaube, gerade bei 8-Bit-CPUs hilft das viel: Ein einzelnes Byte
lesen und dann einen indirekten Sprung ausführen ist sehr viel
schneller, als Zeichen für Zeichen ein Befehlswort in einer Zeile
mit einer Liste zu vergleichen und dann irgendwohin zu springen.

Bei modernen CPUs bin ich mir da weniger sicher: Ein gut optimierter
Lexer bleibt sicher im L1 und hat sehr wenige falsche Branch
Predictions. Der indirekte Sprung hingegen ist hingegen für den
Predictor kaum vorauszusagen, führt also ziemlich sicher zu einem
Pipeline-Stall. Es könnte also sein, dass der relative Vorteil der
Tokenisierung deutlich kleiner ist.

>> und nicht ein Token nur einem einzigen CPU-Befehl entspricht.

Das ist gut, denn so amortisiert sich der Interpreter-Overhead.
Interpreter sind immer dort schnell, wo eine Operation viel Arbeit
erledigt (z.B. ein Regexp-Match in Perl oder eine große
Matrix-Multiplikation in R) und dort langsam, wo eine Operation sehr
wenig tut (z.B. eine Integer-Addition).


> Genau. Und das allerschlimmste ist, daß die meisten Tokenlisten in den 
> BASICs wohl nicht so geordnet sein werden, daß das schnell geht. Ich habe 
> da schon solche case/switches gesehen, wo also jedesmal und für jedes 
> Token eine Liste durchlaufen wird, bis zu dem Punkt, wo der Vergleich 
> dann paßt.
> ( switch(a) { case 21 : do xyz ; break ; case 255 : do xyz1 ; } )

Wenn das C-Code ist (und nicht Pseudo-Code, der Assembler visualisieren
soll) ist das gut: Der Compiler kann dann den optimalen Code daraus
machen.  Je nachdem, wieviele Cases es gibt und wie die Zahlenwerte
verteilt sind, kann das eine Folge von CMP/JMP werden, ein indirekter
Sprung durch eine Tabelle, eine binärer Baum, etc. Das konnten
C-Compiler schon ca. 1990.


> Und ganz lustig sind dann so Befehle, wo innerhalb eines Tokens nochmal 
> abgefragt werden muß, wieviele Parameter nun da jetzt mitgekommen sind 
> und an welcher Stelle. Bsp1: die Farbe kann bei einem Grafikbefehl 
> mitgegeben werden, wobei es aber sowie eine Colour Anweisung gibt, die 
> das festlegt. Bsp2: Rotationswinkel für Rechtecke. Bsp3: Kreis mit einem 
> Radius, Ellipse, wenn ein zweiter Radius mitgegeben wird.
>
>
> Letztlich macht das aber ein C Compiler auch nicht soviel anders. Nur, daß 
> er eben die Tokens erstmal selbst aus dem Quellcode generiert und jedem 
> Befehl eine "Nummer" gibt.

Der große Unterschied ist, dass ein C-Compiler Maschinencode erzeugt.
"Tokens" sind da nur eine temporäre Datenstruktur in einer sehr frühen
Phase der Übersetzung.

Moderne Interpreter sind irgendwo dazwischen. Die enthalten einen
vollständigen Compiler (d.h. sie tokenisieren nicht nur den Input,
sondern erzeugen ein Programm in einer anderen, assembler-ähnlichen
Sprache), aber der Output ist kein Maschinencode für die Maschine, auf
der er läuft und muss daher von einem Programm interpretiert werden (und
nicht von von der CPU). In manchen Fällen enthält dann dieser
nachgelagerte Interpreter wieder einen (JIT-)Compiler, der dann echten
Maschinencode erzeugt.


> Der Unterschied ist v.a. auch der, daß man heut nicht mehr nur 8 Bit 
> dafür benutzen kann/muß.

Und vor allem, dass Computer sehr viel schneller sind und sehr viel mehr
RAM haben. Eine hypothetische CPU mit 8-Bit-Datenregistern und
64-Bit-Adressregistern in moderner Fertigung wäre sehr viel mächtiger
als ein 6502.

        hjp

[toc] | [prev] | [next] | [standalone]

#50232

An einem Sun, 25 May 2025 08:09:02 +0200 schrieb der Meister Peter J.
Holzer:

> On 2025-05-24 22:44, Sebastian Barthel <naitsabes@freenet.de> wrote:
>> An einem Sat, 24 May 2025 13:01:16 +0200 schrieb der Meister Arno
>> Welzel:
>>
>>> Marcel Mueller, 2025-05-19 19:01:
>>> 
>>>> Am 14.05.25 um 10:54 schrieb F. W.:
>>> [...]
>>>> Wir hatten in '79 auch einen Computer, der in Basic ungefähr so
>>>> schnell war, wie der 64-er in Maschinensprache. Natürlich größer,
>>>> aber der eigentliche Trick war, dass der Editor schon Tokens statt
>>>> Quellcode in die Dateien gespeichert hat. Die haben einfach die
>>>> Symbole 0x80-0xff für die Tokens benutzt. Naja, und Variablen waren
>>>> wie damals üblich stark längenbegrenzt.
>>> 
>>> Tokens hat der C64 auch benutzt - schon deshalb, um Speicherplatz zu
>>> sparen. "Text" hat man nur beim Bearbeiten gesehen, aber intern wurden
>>> alle Befehle nur als Token gespeichert:
>>> 
>>> <https://www.c64-wiki.de/wiki/Token>
>>> 
>>> Das hilft aber nicht, wenn man eine 8-Bit-CPU mit unter 1 MHz
>>> Taktfrequenz hat - besonders schnell ist die Ausführung eines
>>> BASIC-Programms dann trotzdem nicht, weil der Token ja trotzdem
>>> verarbeitet werden muss
> 
> Ich glaube, gerade bei 8-Bit-CPUs hilft das viel: Ein einzelnes Byte
> lesen und dann einen indirekten Sprung ausführen ist sehr viel
> schneller, als Zeichen für Zeichen ein Befehlswort in einer Zeile mit
> einer Liste zu vergleichen und dann irgendwohin zu springen.

Ich nehm das jetzt mal auf, weil mir das gerade so einfiel: es wäre z.B 
auch eine SEHR interessante Variante, wenn das gelesene Byte (Token) 
einfach ein Index in eine Page wäre, wo dann direkt der Code für den 
Befehl steht.

Und 2tens: es wäre bestimmt immer noch schneller, wenn man für einen 
ausgeschriebenen Befehl (kein Token) einfach die Bytewerte der Befehls-
Buchstaben addiert und dann auswertet.

>> Genau. Und das allerschlimmste ist, daß die meisten Tokenlisten in den
>> BASICs wohl nicht so geordnet sein werden, daß das schnell geht. Ich
>> habe da schon solche case/switches gesehen, wo also jedesmal und für
>> jedes Token eine Liste durchlaufen wird, bis zu dem Punkt, wo der
>> Vergleich dann paßt.
>> ( switch(a) { case 21 : do xyz ; break ; case 255 : do xyz1 ; } )
> 
> Wenn das C-Code ist (und nicht Pseudo-Code, der Assembler visualisieren
> soll) ist das gut: Der Compiler kann dann den optimalen Code daraus
> machen.  Je nachdem, wieviele Cases es gibt und wie die Zahlenwerte
> verteilt sind, kann das eine Folge von CMP/JMP werden, ein indirekter
> Sprung durch eine Tabelle, eine binärer Baum, etc. Das konnten
> C-Compiler schon ca. 1990.

Ja, sollte C (-artig) sein. Es ging mir aber v.a. darum, daß, wenn da 
eine Liste draus wird, jeder Befehl immer die komplette Liste durchläuft 
mit ziemlich vielen unnötigen Vergleichen, wenn er z.B. ganz am Ende 
steht.

Geschickter wären evtl Befehlskategorien, die im Token mitcodiert sind 
und man für den Einzelbefehl dann nur noch die Subliste durchsuchen muß.
(etwa Grafikbefehl, Stringverarbeitung, I/O, Schleife, Daten 
(DATA,RESTORE))

Ich glaub ja nicht, daß ein Compiler das so geschickt anordnen kann, daß 
z.B. jeder Befehl nach 4 Vergleichen zugeordnet werden kann. Wobei 
Binärbaum das prinzipiell könnte (wenn der Compiler da wirklich sowas 
draus baut).

>> Der Unterschied ist v.a. auch der, daß man heut nicht mehr nur 8 Bit
>> dafür benutzen kann/muß.
> 
> Und vor allem, dass Computer sehr viel schneller sind und sehr viel mehr
> RAM haben. Eine hypothetische CPU mit 8-Bit-Datenregistern und
> 64-Bit-Adressregistern in moderner Fertigung wäre sehr viel mächtiger
> als ein 6502.

Sowas würd ich schon gern mal in "echt" sehen ... :)

Müssen auch nicht nur 8Bit sein, dürfen auch 10 oder 12 sein. Das 
ermöglicht dann noch paar Sachen mehr, die auf 8Bit immer sehr "hakelig" 
sind.

Ich habe mal irgendwo einen sehr schönen Text gelesen, der plausibel 
dargelegt hat, daß es NICHT die hohe Geschwindigkeit der CPUs ist, die 
die Computerentwicklung so schnell vorantreiben / -getrieben haben. 
Stattdessen die immense Zunahme an verfügbarem Speicherplatz. V.a. 
natürlich RAM - in schnell und billig.

Evtl steht ja der nächste Schritt kurz bevor, wenn die Flash Chips 
schneller werden. Gab es neulich (vor 2 -3 Wochen) mal einen 
interessanten heise Artikel dazu, wo es um eine evtl demnächst verfügbare 
neue Art von Flash / SSD ging.

VG,
SBn

-- 
holy miau is a snake

[toc] | [prev] | [next] | [standalone]

#50245

On 2025-05-25 17:03, Sebastian Barthel <naitsabes@freenet.de> wrote:
> An einem Sun, 25 May 2025 08:09:02 +0200 schrieb der Meister Peter J.
> Holzer:
>> On 2025-05-24 22:44, Sebastian Barthel <naitsabes@freenet.de> wrote:
>>> An einem Sat, 24 May 2025 13:01:16 +0200 schrieb der Meister Arno
>>> Welzel:
>>>> Marcel Mueller, 2025-05-19 19:01:
>>>>> Wir hatten in '79 auch einen Computer, der in Basic ungefähr so
>>>>> schnell war, wie der 64-er in Maschinensprache. Natürlich größer,
>>>>> aber der eigentliche Trick war, dass der Editor schon Tokens statt
>>>>> Quellcode in die Dateien gespeichert hat. Die haben einfach die
>>>>> Symbole 0x80-0xff für die Tokens benutzt. Naja, und Variablen waren
>>>>> wie damals üblich stark längenbegrenzt.
>>>> 
>>>> Tokens hat der C64 auch benutzt - schon deshalb, um Speicherplatz zu
>>>> sparen. "Text" hat man nur beim Bearbeiten gesehen, aber intern wurden
>>>> alle Befehle nur als Token gespeichert:
>>>> 
>>>> <https://www.c64-wiki.de/wiki/Token>
>>>> 
>>>> Das hilft aber nicht, wenn man eine 8-Bit-CPU mit unter 1 MHz
>>>> Taktfrequenz hat - besonders schnell ist die Ausführung eines
>>>> BASIC-Programms dann trotzdem nicht, weil der Token ja trotzdem
>>>> verarbeitet werden muss
>> 
>> Ich glaube, gerade bei 8-Bit-CPUs hilft das viel: Ein einzelnes Byte
>> lesen und dann einen indirekten Sprung ausführen ist sehr viel
>> schneller, als Zeichen für Zeichen ein Befehlswort in einer Zeile mit
>> einer Liste zu vergleichen und dann irgendwohin zu springen.
>
> Ich nehm das jetzt mal auf, weil mir das gerade so einfiel: es wäre z.B 
> auch eine SEHR interessante Variante, wenn das gelesene Byte (Token) 
> einfach ein Index in eine Page wäre, wo dann direkt der Code für den 
> Befehl steht.

Ich kenne einen Prozessor, bei dem die Interrupt-Tabelle so funkioniert.
Jeder Interrupt-Slot hat Platz für zwei Instruktionen, danach folgt ein
implizites RTI. Wenn das nicht reicht, muss eine der Instruktionen ein
JMP woanders hin sein.

Ist möglicherweise für einen Signal-Prozessor ein sinnvolles Design (die
Leute bei Motorola werden damals viele Anwendungen analysiert haben und
festgestellt haben, dass man mit 2 Instruktionen den Großteil der
Interrupts abarbeiten kann).

Für einen BASIC-Interpreter trifft das fast sicher nicht zu: Der Code
zur Verarbeitung jedes Tokens kann sehr unterschiedlich lang sein, man
verschwendet also entweder viel Platz oder muss erst wieder woanders hin
springen. Da ist eine Sprungtabelle sinnvoller (und auf Rechnern mit
sehr kurzer Pipeline wie dem 6502 war das ja auch performant).

> Und 2tens: es wäre bestimmt immer noch schneller, wenn man für einen 
> ausgeschriebenen Befehl (kein Token) einfach die Bytewerte der Befehls-
> Buchstaben addiert und dann auswertet.

1 Byte lesen ist sicher schneller als 3 Bytes lesen und addieren.

Abgesehen davon ist addieren eine sehr schlechte Hash-Funktion. Bei
etwas umfangreicheren BASIC-Dialekten hat man da Kollisionen, und simple
Buchstagendreher "TOGO" statt "GOTO" werden auch nicht erkannt.

>>> Genau. Und das allerschlimmste ist, daß die meisten Tokenlisten in den
>>> BASICs wohl nicht so geordnet sein werden, daß das schnell geht. Ich
>>> habe da schon solche case/switches gesehen, wo also jedesmal und für
>>> jedes Token eine Liste durchlaufen wird, bis zu dem Punkt, wo der
>>> Vergleich dann paßt.
>>> ( switch(a) { case 21 : do xyz ; break ; case 255 : do xyz1 ; } )
>> 
>> Wenn das C-Code ist (und nicht Pseudo-Code, der Assembler visualisieren
>> soll) ist das gut: Der Compiler kann dann den optimalen Code daraus
>> machen.  Je nachdem, wieviele Cases es gibt und wie die Zahlenwerte
>> verteilt sind, kann das eine Folge von CMP/JMP werden, ein indirekter
>> Sprung durch eine Tabelle, eine binärer Baum, etc. Das konnten
>> C-Compiler schon ca. 1990.
>
> Ja, sollte C (-artig) sein. Es ging mir aber v.a. darum, daß, wenn da 
> eine Liste draus wird, jeder Befehl immer die komplette Liste durchläuft 
> mit ziemlich vielen unnötigen Vergleichen, wenn er z.B. ganz am Ende 
> steht.

Das ist aber eben bei C genau NICHT der Fall. Da jeder case eindeutig
sein muss, kann der C-Compiler daraus Code erzeugen, der das nicht in
linearer Reihenfolge abarbeitet. Und wie bereits geschrieben: Spätestens
1990 war das Stand der Technik und wurde auch von einfachen Compilern
gemacht.

(Bei anderen Sprachen ist das nicht notwendigerweise der Fall: Da ist
oft ein switch nur syntaktischer Zucker für eine if-else-Kaskade.)


> Ich glaub ja nicht, daß ein Compiler das so geschickt anordnen kann, daß 
> z.B. jeder Befehl nach 4 Vergleichen zugeordnet werden kann. Wobei 
> Binärbaum das prinzipiell könnte (wenn der Compiler da wirklich sowas 
> draus baut).

Wenn es maximal 16 Instruktionen gibt ...

Es geht aber auch ganz ohne Vergleiche mit einer Sprungtabelle. (Ok,
einen braucht man für die Range-Überprüfung).

        hjp

[toc] | [prev] | [next] | [standalone]

#50253

An einem Sun, 25 May 2025 21:43:40 +0200 schrieb der Meister Peter J.
Holzer:

> On 2025-05-25 17:03, Sebastian Barthel <naitsabes@freenet.de> wrote:
>> An einem Sun, 25 May 2025 08:09:02 +0200 schrieb der Meister Peter J.
>> Holzer:
>>> On 2025-05-24 22:44, Sebastian Barthel <naitsabes@freenet.de> wrote:
>>>> An einem Sat, 24 May 2025 13:01:16 +0200 schrieb der Meister Arno
>>>> Welzel:
>>>>> Marcel Mueller, 2025-05-19 19:01:
>>>>>> Wir hatten in '79 auch einen Computer, der in Basic ungefähr so
>>>>>> schnell war, wie der 64-er in Maschinensprache. Natürlich größer,
>>>>>> aber der eigentliche Trick war, dass der Editor schon Tokens statt
>>>>>> Quellcode in die Dateien gespeichert hat. Die haben einfach die
>>>>>> Symbole 0x80-0xff für die Tokens benutzt. Naja, und Variablen waren
>>>>>> wie damals üblich stark längenbegrenzt.
>>>>> 
>>>>> Tokens hat der C64 auch benutzt - schon deshalb, um Speicherplatz zu
>>>>> sparen. "Text" hat man nur beim Bearbeiten gesehen, aber intern
>>>>> wurden alle Befehle nur als Token gespeichert:
>>>>> 
>>>>> <https://www.c64-wiki.de/wiki/Token>
>>>>> 
>>>>> Das hilft aber nicht, wenn man eine 8-Bit-CPU mit unter 1 MHz
>>>>> Taktfrequenz hat - besonders schnell ist die Ausführung eines
>>>>> BASIC-Programms dann trotzdem nicht, weil der Token ja trotzdem
>>>>> verarbeitet werden muss
>>> 
>>> Ich glaube, gerade bei 8-Bit-CPUs hilft das viel: Ein einzelnes Byte
>>> lesen und dann einen indirekten Sprung ausführen ist sehr viel
>>> schneller, als Zeichen für Zeichen ein Befehlswort in einer Zeile mit
>>> einer Liste zu vergleichen und dann irgendwohin zu springen.
>>
>> Ich nehm das jetzt mal auf, weil mir das gerade so einfiel: es wäre z.B
>> auch eine SEHR interessante Variante, wenn das gelesene Byte (Token)
>> einfach ein Index in eine Page wäre, wo dann direkt der Code für den
>> Befehl steht.
> 
> Ich kenne einen Prozessor, bei dem die Interrupt-Tabelle so funkioniert.
> Jeder Interrupt-Slot hat Platz für zwei Instruktionen, danach folgt ein
> implizites RTI. Wenn das nicht reicht, muss eine der Instruktionen ein
> JMP woanders hin sein.
> 
> Ist möglicherweise für einen Signal-Prozessor ein sinnvolles Design (die
> Leute bei Motorola werden damals viele Anwendungen analysiert haben und
> festgestellt haben, dass man mit 2 Instruktionen den Großteil der
> Interrupts abarbeiten kann).

Klingt als wäre das Teil dann auch relativ schnell.

2 Instruktionen ist natürlich für ein BASIC Kommando wirklich ein bißchen 
wenig.

>> Und 2tens: es wäre bestimmt immer noch schneller, wenn man für einen
>> ausgeschriebenen Befehl (kein Token) einfach die Bytewerte der Befehls-
>> Buchstaben addiert und dann auswertet.
> 
> 1 Byte lesen ist sicher schneller als 3 Bytes lesen und addieren.

Es ging auch um den Vergleich mit der Auswertung des vollen Codeworts 
(darum die "kein Token" Klammerbemerkung).

Gegen ein Token kommt es natürlich nicht an.
 
> Abgesehen davon ist addieren eine sehr schlechte Hash-Funktion. Bei
> etwas umfangreicheren BASIC-Dialekten hat man da Kollisionen, und simple
> Buchstagendreher "TOGO" statt "GOTO" werden auch nicht erkannt.

Das mag sein. War ja auch eher so ein spontaner Einfall, was noch gehen 
könnte. Die perfekte Variante ist ja mittlerweile auch schon 
vorgeschlagen worden (gperf).

>>>> Genau. Und das allerschlimmste ist, daß die meisten Tokenlisten in
>>>> den BASICs wohl nicht so geordnet sein werden, daß das schnell geht.
>>>> Ich habe da schon solche case/switches gesehen, wo also jedesmal und
>>>> für jedes Token eine Liste durchlaufen wird, bis zu dem Punkt, wo der
>>>> Vergleich dann paßt.
>>>> ( switch(a) { case 21 : do xyz ; break ; case 255 : do xyz1 ; } )
>>> 
>>> Wenn das C-Code ist (und nicht Pseudo-Code, der Assembler
>>> visualisieren soll) ist das gut: Der Compiler kann dann den optimalen
>>> Code daraus machen.  Je nachdem, wieviele Cases es gibt und wie die
>>> Zahlenwerte verteilt sind, kann das eine Folge von CMP/JMP werden, ein
>>> indirekter Sprung durch eine Tabelle, eine binärer Baum, etc. Das
>>> konnten C-Compiler schon ca. 1990.
>>
>> Ja, sollte C (-artig) sein. Es ging mir aber v.a. darum, daß, wenn da
>> eine Liste draus wird, jeder Befehl immer die komplette Liste
>> durchläuft mit ziemlich vielen unnötigen Vergleichen, wenn er z.B. ganz
>> am Ende steht.
> 
> Das ist aber eben bei C genau NICHT der Fall. Da jeder case eindeutig
> sein muss, kann der C-Compiler daraus Code erzeugen, der das nicht in
> linearer Reihenfolge abarbeitet. Und wie bereits geschrieben: Spätestens
> 1990 war das Stand der Technik und wurde auch von einfachen Compilern
> gemacht.

OK. Interessant.

> (Bei anderen Sprachen ist das nicht notwendigerweise der Fall: Da ist
> oft ein switch nur syntaktischer Zucker für eine if-else-Kaskade.)
 
>> Ich glaub ja nicht, daß ein Compiler das so geschickt anordnen kann,
>> daß z.B. jeder Befehl nach 4 Vergleichen zugeordnet werden kann. Wobei
>> Binärbaum das prinzipiell könnte (wenn der Compiler da wirklich sowas
>> draus baut).
> 
> Wenn es maximal 16 Instruktionen gibt ...

An der Stelle kämen dann die Kategorien wieder ins Spiel. Wenn man alle 
Befehle so verteilen kann, daß sich Gruppen mit maximal 16 Instruktionen 
ergeben, wird es passend.
 
> Es geht aber auch ganz ohne Vergleiche mit einer Sprungtabelle. (Ok,
> einen braucht man für die Range-Überprüfung).

Ja, das ist eine interessante und schnelle Lösung. Erfordert halt das 
Token und man "verschwendet" den Platz für die Tabelle. Bei 256 
Befehlstokens sind das ja immerhin schonmal 512 Bytes reiner 
Tabellenplatz.

Wenn man sich auf max. 128 Befehle festlegt, kann man das sogar mit 
direkter Indexierung durch das Token selbst machen.

Witzig ...


VG,
SBn


-- 
holy miau is a snake

[toc] | [prev] | [next] | [standalone]

#50284

On 2025-05-25 22:53, Sebastian Barthel <naitsabes@freenet.de> wrote:
> An einem Sun, 25 May 2025 21:43:40 +0200 schrieb der Meister Peter J.
> Holzer:
>> On 2025-05-25 17:03, Sebastian Barthel <naitsabes@freenet.de> wrote:
>>> Ich nehm das jetzt mal auf, weil mir das gerade so einfiel: es wäre z.B
>>> auch eine SEHR interessante Variante, wenn das gelesene Byte (Token)
>>> einfach ein Index in eine Page wäre, wo dann direkt der Code für den
>>> Befehl steht.
>> 
>> Ich kenne einen Prozessor, bei dem die Interrupt-Tabelle so funkioniert.
>> Jeder Interrupt-Slot hat Platz für zwei Instruktionen, danach folgt ein
>> implizites RTI. Wenn das nicht reicht, muss eine der Instruktionen ein
>> JMP woanders hin sein.
>> 
>> Ist möglicherweise für einen Signal-Prozessor ein sinnvolles Design (die
>> Leute bei Motorola werden damals viele Anwendungen analysiert haben und
>> festgestellt haben, dass man mit 2 Instruktionen den Großteil der
>> Interrupts abarbeiten kann).
>
> Klingt als wäre das Teil dann auch relativ schnell.

War es für damalige Zeiten (33 MHz, ich glaube 2 Taktzyklen pro
Instruktion (incl. 32 Bit floating-point Multiply-Add; 96-Bit war glaube
ich langsamer)).

Ich habe damit Bildverarbeitung gemacht mit einen ganz grauslich
selbstverdrahtetem ADC auf einem Breadboard - wundert mich heute noch,
dass das funktioniert hat).


>> Abgesehen davon ist addieren eine sehr schlechte Hash-Funktion. Bei
>> etwas umfangreicheren BASIC-Dialekten hat man da Kollisionen, und simple
>> Buchstagendreher "TOGO" statt "GOTO" werden auch nicht erkannt.
>
> Das mag sein. War ja auch eher so ein spontaner Einfall, was noch gehen 
> könnte.

Auf einem Gebiet, das seit 70 Jahren beackert wird, sind spontane
Einfälle selten neu. Den gleichen Einfall haben wahrscheinlich hundert
andere Leute auch schon gehabt. Der ist dann entweder Stand der Technik
oder doch nicht so gut.

> Die perfekte Variante ist ja mittlerweile auch schon 
> vorgeschlagen worden (gperf).

Ich kenne gperf seit schätzungsweise 30 Jahren und es hat noch nie ein
Problem gelöst, das ich hatte. Ich finde die Idee recht genial, aber in
der Praxis gibt es meistens bessere Ansätze.


>>> Ich glaub ja nicht, daß ein Compiler das so geschickt anordnen kann,
>>> daß z.B. jeder Befehl nach 4 Vergleichen zugeordnet werden kann. Wobei
>>> Binärbaum das prinzipiell könnte (wenn der Compiler da wirklich sowas
>>> draus baut).
>> 
>> Wenn es maximal 16 Instruktionen gibt ...
>
> An der Stelle kämen dann die Kategorien wieder ins Spiel. Wenn man alle 
> Befehle so verteilen kann, daß sich Gruppen mit maximal 16 Instruktionen 
> ergeben, wird es passend.

Die Kategorien musst Du aber auch abfragen, das sind weitere Vergleiche.


>> Es geht aber auch ganz ohne Vergleiche mit einer Sprungtabelle. (Ok,
>> einen braucht man für die Range-Überprüfung).
>
> Ja, das ist eine interessante und schnelle Lösung. Erfordert halt das 
> Token und man "verschwendet" den Platz für die Tabelle. Bei 256 
> Befehlstokens sind das ja immerhin schonmal 512 Bytes reiner 
> Tabellenplatz.

256 CMP/JMP brauchen aber auch nicht weniger Platz. Irgendwo muss halt
für jedes Token kodiert sein, wo der zugehörige Code steht.

        hjp

[toc] | [prev] | [next] | [standalone]

#50251

An einem Sun, 25 May 2025 15:19:21 +0000 schrieb der Meister Stefan Ram:

> Sebastian Barthel <naitsabes@freenet.de> schrieb oder zitierte:
>>Und 2tens: es wäre bestimmt immer noch schneller, wenn man für einen
>>ausgeschriebenen Befehl (kein Token) einfach die Bytewerte der Befehls-
>>Buchstaben addiert und dann auswertet.
> 
>   Für perfekte Streuung kann man beispielsweise "gperf" verwenden:
> 
>   1. gperf installieren
> ...
>   2. Schlüsselwortliste erstellen
> ...
>   3. Streufunktion generieren
> ...
>   4. Verwendung des generierten Codes
> ...
>   5. Kompilieren und Ausführen
> 
>   sh:
> 
> gcc -o basic_keywords main.c ./basic_keywords
> 
>   Erwartete Ausgabe:
> 
> PRINT ist ein BASIC-Schlüsselwort (Token 1)
> INPUT ist ein BASIC-Schlüsselwort (Token 2)
> GOTO ist ein BASIC-Schlüsselwort (Token 3)
> XYZ ist KEIN BASIC-Schlüsselwort END ist ein BASIC-Schlüsselwort (Token
> 10)

Interessante Variante.

Hat bißchen was von "Kanonen auf Spatzen" aber funktioniert vmtl gut. 
V.a. ist es auch dank der Liste nachträglich schön erweiterbar.

Danke für den Hinweis auf das gperf Paket.


VG,
SBn

-- 
holy miau is a snake

[toc] | [prev] | [next] | [standalone]

#50268

Am 25.05.25 um 08:09 schrieb Peter J. Holzer:

> Und vor allem, dass Computer sehr viel schneller sind und sehr viel mehr
> RAM haben. Eine hypothetische CPU mit 8-Bit-Datenregistern und
> 64-Bit-Adressregistern in moderner Fertigung wäre sehr viel mächtiger
> als ein 6502.

Hypothetischer computer:
CPU Z80 oder 6502
2 KB RAM 2 kB EPROM
Serieller Chip.
+ Steuerung von einem Kassettenrecoder.

Emuliert wird damit eine moderne CPU.
deren Register und etwas cache liegen im 2 kB RAM,
als Hauptspeicher wird der Kassettenrecorder verwendet.
Als größerer Hauptspeicher käme vielleicht ein Videorecorder in Frage.

Viel Spaß in den ewigen Bitgründen.

-- 
<http://www.hermann-riemann.de>

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | de.alt.folklore.computer

csiph-web