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

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

Dartmouth Time Shating System

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

Contents

  Dartmouth Time Shating System Thomas Koenig <tkoenig@netcologne.de> - 2024-06-27 16:52 +0000
    Re: Dartmouth Time Shating System Ignatios Souvatzis <u502sou@bnhb484.de> - 2024-06-28 12:59 +0000
    Re: Dartmouth Time Shating System Arno Welzel <usenet@arnowelzel.de> - 2024-06-29 11:30 +0200
    Re: Dartmouth Time Shating System "F. W." <me@home.invalid> - 2024-07-01 13:20 +0200
      Re: Dartmouth Time Shating System "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-07-01 17:26 +0200
        Re: Dartmouth Time Shating System Helmut Fischer <h_fischer@gmx.de> - 2024-07-03 09:56 +0200
          Re: Dartmouth Time Shating System "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-07-03 13:24 +0200
            Re: Dartmouth Time Shating System Thomas Klix <wotokl@web.de> - 2024-07-03 14:30 +0200
              Re: Dartmouth Time Shating System "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-07-03 15:22 +0200
                Re: Dartmouth Time Shating System Thomas Klix <wotokl@web.de> - 2024-07-03 17:49 +0200
                  Re: Dartmouth Time Shating System "Michael Kraemer @ home" <M.Kraemer@gsi.de> - 2024-07-03 18:12 +0200
                    Re: Dartmouth Time Shating System "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2024-07-04 08:44 +0000
                  Re: Dartmouth Time Shating System "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-07-03 20:10 +0200
                    Re: Dartmouth Time Shating System Thomas Koenig <tkoenig@netcologne.de> - 2024-07-04 15:10 +0000
                      Re: Dartmouth Time Shating System "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-07-04 18:32 +0200
                        Re: Dartmouth Time Shating System Thomas Koenig <tkoenig@netcologne.de> - 2024-07-04 17:39 +0000
                          Re: Dartmouth Time Shating System Stefan Reuther <stefan.news@arcor.de> - 2024-07-05 17:59 +0200
                            Re: Dartmouth Time Shating System Thomas Koenig <tkoenig@netcologne.de> - 2024-07-05 19:57 +0000
                              Re: Dartmouth Time Shating System Stefan Reuther <stefan.news@arcor.de> - 2024-07-06 09:36 +0200
                                Re: Dartmouth Time Shating System "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-07-06 12:51 +0200
                  Re: Dartmouth Time Shating System poc@pocnet.net - 2024-07-04 12:05 +0000
            Lernkurve (was: Dartmouth Time Shating System) Martin Klaiber <usenet.martinkl@gmx.de> - 2024-07-03 16:31 +0200
              Re: Lernkurve "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2024-07-03 18:02 +0200
              Re: Lernkurve Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-07-03 22:05 +0000
            Re: Dartmouth Time Shating System Christian Corti <use@reply.to> - 2024-07-03 17:03 +0200
            Re: Dartmouth Time Shating System Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2024-07-03 22:10 +0000

Page 1 of 2  [1] 2  Next page →

#44959 — Dartmouth Time Shating System

Heute kaum mehr bekannt, aber wegweisend:  Auf dem System sollten
Studenten die Furcht vor dem Computer ver- und das Programmieren
lernen, und dafür wurde BASIC entwickelt.

Aber die hatten noch was ganz anderes entwickelt, was die
heute allgegenwärtigen Pipes vorwegnahm, deutlich mächter
war und was heute keiner mehr kennt:  Communication Files.
Doug McIllroy (der damalige Chef der ganzen Unix-Nerds wie
Thompson, Ritchie etc, der damals auch die Pipes vorgeschlagen
hat) hat da einen schönen Artikel dazu geschrieben, unter
https://www.cs.dartmouth.edu/~doug/DTSS/commfiles.pdf

Faszinierend.

[toc] | [next] | [standalone]

#44960

Thomas Koenig wrote: 

> Aber die hatten noch was ganz anderes entwickelt, was die
> heute allgegenwärtigen Pipes vorwegnahm, deutlich mächter
> war und was heute keiner mehr kennt:  Communication Files.
> Doug McIllroy (der damalige Chef der ganzen Unix-Nerds wie
> Thompson, Ritchie etc, der damals auch die Pipes vorgeschlagen
> hat) hat da einen schönen Artikel dazu geschrieben, unter
> https://www.cs.dartmouth.edu/~doug/DTSS/commfiles.pdf

Hm, sowas wie named pipes, aber dem Text nach master-seitig noch
flexibler.

puffs, rumpkernel (unter NetBSD) und z.B. exokernel gehen in die
Richtung und teils darueber hinaus.

http://lib.tkk.fi/Diss/2012/isbn9789526049175/isbn9789526049175.pdf


	-is

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

#44961

Thomas Koenig, 2024-06-27 18:52:

> Heute kaum mehr bekannt, aber wegweisend:  Auf dem System sollten
> Studenten die Furcht vor dem Computer ver- und das Programmieren
> lernen, und dafür wurde BASIC entwickelt.
> 
> Aber die hatten noch was ganz anderes entwickelt, was die
> heute allgegenwärtigen Pipes vorwegnahm, deutlich mächter
> war und was heute keiner mehr kennt:  Communication Files.
> Doug McIllroy (der damalige Chef der ganzen Unix-Nerds wie
> Thompson, Ritchie etc, der damals auch die Pipes vorgeschlagen
> hat) hat da einen schönen Artikel dazu geschrieben, unter
> https://www.cs.dartmouth.edu/~doug/DTSS/commfiles.pdf

Dazu auch noch das hier, wobe ich nicht sicher bin, ob das vergleichbar ist:

<https://dev.to/leandronsp/inter-process-communication-files-1m34>

-- 
Arno Welzel
https://arnowelzel.de

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

#44964

Am 27.06.24 um 18:52 schrieb Thomas Koenig:

> Heute kaum mehr bekannt, aber wegweisend:  Auf dem System sollten 
> Studenten die Furcht vor dem Computer ver- und das Programmieren 
> lernen, und dafür wurde BASIC entwickelt.

Ich stehe zwar vermutlich ziemlich alleine, aber ich fand bei meinem
ersten Kontakt mit einem BASIC-Interpreter 1981 die Editierung durch
Zeilennummern, das Aufrufen anderer Programme durch CHAIN, die
Einfachheit der Sprache i. A. und die Flexibilität von PRINT i. B. schon
ziemlich beeindruckend.

FW

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

#44965

On 2024-07-01 11:20, F. W. <me@home.invalid> wrote:
> Am 27.06.24 um 18:52 schrieb Thomas Koenig:
>> Heute kaum mehr bekannt, aber wegweisend:  Auf dem System sollten 
>> Studenten die Furcht vor dem Computer ver- und das Programmieren 
>> lernen, und dafür wurde BASIC entwickelt.
>
> Ich stehe zwar vermutlich ziemlich alleine, aber ich fand bei meinem
> ersten Kontakt mit einem BASIC-Interpreter 1981 die Editierung durch
> Zeilennummern, das Aufrufen anderer Programme durch CHAIN, die
> Einfachheit der Sprache i. A. und die Flexibilität von PRINT i. B. schon
> ziemlich beeindruckend.

Die Lernkurve war jedenfalls sehr flach. Man konnte sehr schnell etwas
Herzeigbares programmieren. Zugegeben: Die Latte lag in einer Zeit, in
der die meisten Menschen noch keinen Computer gesehen hatten, auch recht
niedrig.

        hp

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

#44966

Am 01.07.24 um 17:26 schrieb Peter J. Holzer:

> ... Die Lernkurve war jedenfalls sehr flach. ...

Du meinst vermutlich "steil"?

Grüße, Helmut

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

#44967

On 2024-07-03 07:56, Helmut Fischer <h_fischer@gmx.de> wrote:
> Am 01.07.24 um 17:26 schrieb Peter J. Holzer:
>> ... Die Lernkurve war jedenfalls sehr flach. ...
>
> Du meinst vermutlich "steil"?

Nein, flach. Es war sehr leicht zu beginnen:

10 print "Hello, world"

und sehr leicht, inkrementell etwas dazuzulernen. Vom ersten Hello world
zu Ulams Vermutung in ein oder zwei Doppelstunden. Dann einfache Spiele
mit Text-"Graphik" und bald darauf richtige Graphik (und das hat nur so
lange gedauert, weil wir die Apple ][ erst Ende Dezember bekamen). Zu
keinem Zeitpunkt hatte ich das Gefühl, dass ich da etwas Schwieriges
lernen müsste.

Wenn ich heute eine neue Programmiersprache oder auch nur ein neues
Framework lerne, ist die Lernkurve viel steiler. Das mag damit
zusammenhängen, dass ich nicht mehr 16 bin, aber auch damit, dass es
viel mehr zu lernen gibt (schau dir nur mal die Standard-Library von
Python im Vergleich zu Apple-Basic an) und wenig Zeit dafür (das Projekt
soll ja möglichst gestern schon fertig sein).

        hp

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

#44968

Peter J. Holzer <hjp-usenet4@hjp.at> at Mi 03 Jul 2024 11:24:54 GMT:
> On 2024-07-03 07:56, Helmut Fischer <h_fischer@gmx.de> wrote:
>> Am 01.07.24 um 17:26 schrieb Peter J. Holzer:
>>> ... Die Lernkurve war jedenfalls sehr flach. ...
>>
>> Du meinst vermutlich "steil"?
>
> Nein, flach. Es war sehr leicht zu beginnen:
>
> 10 print "Hello, world"
>
> und sehr leicht, inkrementell etwas dazuzulernen. Vom ersten Hello world
> zu Ulams Vermutung in ein oder zwei Doppelstunden. Dann einfache Spiele
> mit Text-"Graphik" und bald darauf richtige Graphik (und das hat nur so
> lange gedauert, weil wir die Apple ][ erst Ende Dezember bekamen). Zu
> keinem Zeitpunkt hatte ich das Gefühl, dass ich da etwas Schwieriges
> lernen müsste.

Bis du auf etwas komplexeres stößt.
Es gibt "SUBMIT"/"RETURN", aber echte Unterprogramme im Sinne von
Funktionen / Subroutines gibt es nicht. Keine lokalen Variabalen.
"Beginners' All-purpose Symbolic Instruction Code" eben.
Wenns ernsthaft wird, wird die Lernkurve steiler.

> Wenn ich heute eine neue Programmiersprache oder auch nur ein neues
> Framework lerne, ist die Lernkurve viel steiler. Das mag damit
> zusammenhängen, dass ich nicht mehr 16 bin, aber auch damit, dass es
> viel mehr zu lernen gibt (schau dir nur mal die Standard-Library von
> Python im Vergleich zu Apple-Basic an) und wenig Zeit dafür (das Projekt
> soll ja möglichst gestern schon fertig sein).

Wenn du noch 16 wärst, würde ich dir Pascal empfehlen. :-)
Im Ernst, Pascal wurde nicht umsonst als Lehrsprache entwickelt. Mit
Turbo-Pascal habe ich strukturiertes Programmieren gelernt. Dann kam
Turbo-C++.

Aber es stimmt: Die grundsätzlichen Sprachbefehle sind in allen
Programmiersprachen einfach (Schleife, if, case, ...) - aber bis man
sich durch die Bibliotheken gewurstet hat, dauert. Und da habe ich noch
nicht einmal von den Windows-Libs angefangen...

Thomas

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

#44969

On 2024-07-03 12:30, Thomas Klix <wotokl@web.de> wrote:
> Peter J. Holzer <hjp-usenet4@hjp.at> at Mi 03 Jul 2024 11:24:54 GMT:
>> On 2024-07-03 07:56, Helmut Fischer <h_fischer@gmx.de> wrote:
>>> Am 01.07.24 um 17:26 schrieb Peter J. Holzer:
>>>> ... Die Lernkurve war jedenfalls sehr flach. ...
>>>
>>> Du meinst vermutlich "steil"?
>>
>> Nein, flach. Es war sehr leicht zu beginnen:
>>
>> 10 print "Hello, world"
>>
>> und sehr leicht, inkrementell etwas dazuzulernen. Vom ersten Hello world
>> zu Ulams Vermutung in ein oder zwei Doppelstunden. Dann einfache Spiele
>> mit Text-"Graphik" und bald darauf richtige Graphik (und das hat nur so
>> lange gedauert, weil wir die Apple ][ erst Ende Dezember bekamen). Zu
>> keinem Zeitpunkt hatte ich das Gefühl, dass ich da etwas Schwieriges
>> lernen müsste.
>
> Bis du auf etwas komplexeres stößt.
> Es gibt "SUBMIT"/"RETURN",

SUBMIT sagt mir nichts. Ich kenne nur GOSUB. War aber auch nicht
schwierig.

> aber echte Unterprogramme im Sinne von Funktionen / Subroutines gibt
> es nicht. Keine lokalen Variabalen. "Beginners' All-purpose Symbolic
> Instruction Code" eben.

Es gibt natürlich schwierige Probleme. Wir hatten z.B. einmal die Idee,
ein Programm zur Stundenplanerstellung zu schreiben. Daran wären wir
vermutlich gescheitert[1]. Aber nicht daran, dass wir dafür
BASIC-Features gebraucht hätten, die wir nicht verstanden, sondern
daran, dass wir keine Ahnung von Optimierungsstrategien hatten (und
unsere Lehrer auch nicht).

> Wenns ernsthaft wird, wird die Lernkurve steiler.

Ich habe ein "ernsthaftes" Programm in BASIC geschrieben (d.h. ich wurde
dafür bezahlt und es hatte nicht-triviale Länge). Man entwickelt
natürlich Strategien, wie man längere BASIC-Programme strukturiert,
damit sie wartbar bleiben (Wartung in der Telefonzelle FTW ;-)). Aber
auch da empfand ich die Lernkurve als flach. Da war nirgends ein
plötzlicher Komplexitätssprung. Es war einfach nur eine Progression.

>> Wenn ich heute eine neue Programmiersprache oder auch nur ein neues
>> Framework lerne, ist die Lernkurve viel steiler. Das mag damit
>> zusammenhängen, dass ich nicht mehr 16 bin, aber auch damit, dass es
>> viel mehr zu lernen gibt (schau dir nur mal die Standard-Library von
>> Python im Vergleich zu Apple-Basic an) und wenig Zeit dafür (das Projekt
>> soll ja möglichst gestern schon fertig sein).
>
> Wenn du noch 16 wärst, würde ich dir Pascal empfehlen. :-)

Das habe ich mit 17 gelernt ;-). Im Kasten hinten im EDV-Raum lagen die
Manuals für Apple-Pascal sowie die Disketten. Die habe ich irgendwann
dort entdeckt. Also habe ich im zweiten Jahr hauptsächlich in Pascal
programmiert (nur in der Schule. Für meinen Heimcomputer gab es keinen
leistbaren Pascal-Compiler - die große Programmiersprachenauswahl kam
dann erst mit dem PC und Zugang zur "Software-Tauschbörse" im Hörsaal).

> Im Ernst, Pascal wurde nicht umsonst als Lehrsprache entwickelt.

Pascal fand ich konzeptionell deutlich schwieriger als BASIC. Rekursion
war mir nicht auf Anhieb klar, und Pointer habe ich erst verstanden,
nachdem ich sie auch in C kennengelernt hatte. Da war die Lernkurve
schon deutlich steiler. Aber ja - immer noch recht flach.

Man muss auch dazusagen, dass die Lernkurve davon abhängt, was man
macht. Perl und Python haben einige ziemlich anspruchsvolle Konzepte,
aber man muss die nicht notwendigerweise kennen, um in diesen Sprachen
programmieren zu können. Als ich noch öfter auf Perl-Konferenzen war,
gab es einen, der ein großer Verfechter von "Baby-Perl" (wie er das
nannte) war, also nur so viel von der Sprache zu lernen, wie man für
seine Aufgaben braucht. (Ich selbst fühle mich unwohl, wenn ich kein
gutes gedankliches Modell habe. "Das funktioniert so, aber ich weiß
nicht warum" macht mir Bauchweh.)

        hp

[1] Ich habe dann ein paar Jahre später während des Studiums etwas
    Ähnliches geschrieben. Das hat funktioniert und war zumindest zum
    Zeitpunkt meiner Sponsion noch im praktischen Einsatz.

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

#44972

Peter J. Holzer <hjp-usenet4@hjp.at> at Mi 03 Jul 2024 13:22:21 GMT:
> On 2024-07-03 12:30, Thomas Klix <wotokl@web.de> wrote:
>> Peter J. Holzer <hjp-usenet4@hjp.at> at Mi 03 Jul 2024 11:24:54 GMT:
>> [...]
>> Bis du auf etwas komplexeres stößt.
>> Es gibt "SUBMIT"/"RETURN",
>
> SUBMIT sagt mir nichts. Ich kenne nur GOSUB. War aber auch nicht
> schwierig.

Sorry, ich meinte GOSUB. Meine BASIC-Zeit ist etwas her...
Aber an die GOTO-Schweinereien kann ich mich erinnern.
Da fällt mir ein (wir sind ja hier folkloristisch): Mit PL/1 hatte ich
da auch viel Spaß. Das kennt auch GOTO, und wenn man da versucht,
ein fremdes Programm zu verstehen, in dem wild in Unterprogramme und
wieder herausgehüpft wird - es war übel.

>> aber echte Unterprogramme im Sinne von Funktionen / Subroutines gibt
>> es nicht. Keine lokalen Variabalen. "Beginners' All-purpose Symbolic
>> Instruction Code" eben.
>
> Es gibt natürlich schwierige Probleme. Wir hatten z.B. einmal die Idee,
> ein Programm zur Stundenplanerstellung zu schreiben. Daran wären wir
> vermutlich gescheitert[1]. Aber nicht daran, dass wir dafür
> BASIC-Features gebraucht hätten, die wir nicht verstanden, sondern
> daran, dass wir keine Ahnung von Optimierungsstrategien hatten (und
> unsere Lehrer auch nicht).

Als Lehrling habe ich auch versucht, etwas Schwieriges in BASIC zu
realisieren - bin aber auf halber Strecke gescheitert. (Simulation
ESER-Rechner.) Sowohl BASIC als auch Technik waren überfordert. Okay,
ich vielleicht auch.

Stundenplanerstellung inklusive Raumplanung ist eine Wissenschaft für
sich - was die dafür Verantwortlichen an (Magnet-)Schildchen
rumschubsen, will ich gar nicht wissen.

> [...]
> Pascal fand ich konzeptionell deutlich schwieriger als BASIC. Rekursion
> war mir nicht auf Anhieb klar, und Pointer habe ich erst verstanden,
> nachdem ich sie auch in C kennengelernt hatte. Da war die Lernkurve
> schon deutlich steiler. Aber ja - immer noch recht flach.

Natürlich sind ernsthafte Programmiersprachen schwieriger als BASIC.
Gerade Rekursion oder Pointer gehen in BASIC überhaupt nicht.
Aber: Wenn du *das* noch als flache Lernkurve einstufst, bist du einsam
genial. :-)

> Man muss auch dazusagen, dass die Lernkurve davon abhängt, was man
> macht. Perl und Python haben einige ziemlich anspruchsvolle Konzepte,
> aber man muss die nicht notwendigerweise kennen, um in diesen Sprachen
> programmieren zu können. Als ich noch öfter auf Perl-Konferenzen war,
> gab es einen, der ein großer Verfechter von "Baby-Perl" (wie er das
> nannte) war, also nur so viel von der Sprache zu lernen, wie man für
> seine Aufgaben braucht. (Ich selbst fühle mich unwohl, wenn ich kein
> gutes gedankliches Modell habe. "Das funktioniert so, aber ich weiß
> nicht warum" macht mir Bauchweh.)

Ich frage mich auch, ob jemand "C"s Pragmas tatsächlich nutzt. Gesehen
habe ich es noch nicht.
Aber: "C&P"-Murks habe ich schon gesehen. Konnte nicht funktionieren.
Ich will verstehen, was ich release.

Thomas

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

#44974

Thomas Klix wrote:

> Ich frage mich auch, ob jemand "C"s Pragmas tatsächlich nutzt.

Ja.

 > Gesehen habe ich es noch nicht.

#pragma omp parallel for schedule(dynamic) default(none)\
private(xyz)\
shared(zyx)

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

#44979

Michael Kraemer @ home <M.Kraemer@gsi.de> wrote:
>Thomas Klix wrote:

>> Ich frage mich auch, ob jemand "C"s Pragmas tatsächlich nutzt.

>Ja.

>> Gesehen habe ich es noch nicht.

>#pragma omp parallel for schedule(dynamic) default(none)\
>private(xyz)\
>shared(zyx)

oder z.B.
#pragma pack(1)

Bei der Programmierung von PIC Mikrocontrollern mit MPLABX
wird die Konfigurierung (entspricht den Fuses bei AVRs) mit Pragmas
eingestellt.



-- 
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

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

#44976

On 2024-07-03 15:49, Thomas Klix <wotokl@web.de> wrote:
> Peter J. Holzer <hjp-usenet4@hjp.at> at Mi 03 Jul 2024 13:22:21 GMT:
>> Pascal fand ich konzeptionell deutlich schwieriger als BASIC. Rekursion
>> war mir nicht auf Anhieb klar, und Pointer habe ich erst verstanden,
>> nachdem ich sie auch in C kennengelernt hatte. Da war die Lernkurve
>> schon deutlich steiler. Aber ja - immer noch recht flach.
>
> Natürlich sind ernsthafte Programmiersprachen schwieriger als BASIC.
> Gerade Rekursion oder Pointer gehen in BASIC überhaupt nicht.

Ich glaube, dass GOSUB/RETURN bei den üblichen BASIC-Interpretern einen
Stack verwendet haben. Rekursion wäre somit technisch möglich gewesen.
Aber mangels lokaler Variablen nicht sehr nützlich. Wenn man sich selbst
um das Verwalten der Variablen im Call-Stack kümmern muss, wird jeder
nicht-triviale Algorithmus so kompliziert, dass man die Energie besser
ins "Flachklopfen" der Rekursion in eine Schleife steckt. Das ist zwar
auch schwer zu lesen (unser Lehrbuch enthielt eine Implementation von
Quicksort in BASIC als abschreckendes Beispiel), aber wenigstens nur auf
eine Art und nicht auf zwei widersprüchliche Arten.

> Aber: Wenn du *das* noch als flache Lernkurve einstufst, bist du einsam
> genial. :-)

Ich kenne ein paar geniale Programmierer, die sind deutlich über meinem
Niveau. Aber als etwas überdurchschnittlich schätze ich mich schon ein.

Rekursion empfinde ich eigentlich nicht als sehr schwierig, und ich weiß
nicht mehr, worin da meine anfängliche Verwirrung lag, oder wie ich sie
aufgelöst habe. Wahrscheinlich hat »Gödel, Escher, Bach« lesen geholfen
;-).

Pointer brauchte ich in Pascal erst mal nicht und konnte sie daher
aufschieben. In C brauchte ich sie dann und die Erklärungen in K&R kamen
mir einleuchtend vor. Aber da hatte ich dann auch schon einige
Assembler-Erfahrung, das hat sicher auch geholfen.


> Ich frage mich auch, ob jemand "C"s Pragmas tatsächlich nutzt.

Mittlerweile gibt es ja ein paar standardisierte. Soweit ich sehe, haben
die alle was mit Floating-Point-Arithmetik zu tun, werden also wohl in
numerisch anspruchsvollem Code verwendet werden.

Lange aber gab es nur compiler-spezifische Pragmas und die hat man eher
nur in plattform-spezifischem Code gesehen. Im Linux-Kernel kommen z.B.
etliche vor. Der konnte auch lange nur mit dem GCC kompiliert werden,
mittlerweile geht es meines Wissens auch mit Clang.

        hp

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

#44985

Peter J. Holzer <hjp-usenet4@hjp.at> schrieb:
> On 2024-07-03 15:49, Thomas Klix <wotokl@web.de> wrote:
>> Peter J. Holzer <hjp-usenet4@hjp.at> at Mi 03 Jul 2024 13:22:21 GMT:
>>> Pascal fand ich konzeptionell deutlich schwieriger als BASIC. Rekursion
>>> war mir nicht auf Anhieb klar, und Pointer habe ich erst verstanden,
>>> nachdem ich sie auch in C kennengelernt hatte. Da war die Lernkurve
>>> schon deutlich steiler. Aber ja - immer noch recht flach.
>>
>> Natürlich sind ernsthafte Programmiersprachen schwieriger als BASIC.
>> Gerade Rekursion oder Pointer gehen in BASIC überhaupt nicht.
>
> Ich glaube, dass GOSUB/RETURN bei den üblichen BASIC-Interpretern einen
> Stack verwendet haben.

Leider nein, zumindest für die Microsoft-Basic-Derivate wie
Commodore-Basic.  Wenn sowas wie ein Stack gewünscht war, dann
musste man den sich selber aus einem Array basteln, und
Variablen konnte man auch nicht lokal halten.

Sowas wie Turbo Basic hatte dann tatsächlich benannte
Unterpgrogramme mit lokalen Variablen usw.

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

#44986

On 2024-07-04 15:10, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Peter J. Holzer <hjp-usenet4@hjp.at> schrieb:
>> Ich glaube, dass GOSUB/RETURN bei den üblichen BASIC-Interpretern einen
>> Stack verwendet haben.
>
> Leider nein, zumindest für die Microsoft-Basic-Derivate wie
> Commodore-Basic.  Wenn sowas wie ein Stack gewünscht war, dann
> musste man den sich selber aus einem Array basteln, und
> Variablen konnte man auch nicht lokal halten.

Ich meinte für die Return-Adressen, und das funktioniert zumindest für
Applesoft-BASIC (auch ein MS-BASIC-Derivat):

5 home
10 a = 2
20 gosub 100
25 print 100
30 end
100 if a = 0 then return
110 print a
120 a = a - 1
130 gosub 100
140 return


Das gibt wie erwartet
2
1
100
aus.

Getestet auf <https://www.calormen.com/jsbasic/>, ich weiß nicht, wie
originalgetreu das ist.

Vielleicht kann das ja mal jemand auf richtiger Hardware ausprobieren.

        hp

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

#44987

Peter J. Holzer <hjp-usenet4@hjp.at> schrieb:
> On 2024-07-04 15:10, Thomas Koenig <tkoenig@netcologne.de> wrote:
>> Peter J. Holzer <hjp-usenet4@hjp.at> schrieb:
>>> Ich glaube, dass GOSUB/RETURN bei den üblichen BASIC-Interpretern einen
>>> Stack verwendet haben.
>>
>> Leider nein, zumindest für die Microsoft-Basic-Derivate wie
>> Commodore-Basic.  Wenn sowas wie ein Stack gewünscht war, dann
>> musste man den sich selber aus einem Array basteln, und
>> Variablen konnte man auch nicht lokal halten.
>
> Ich meinte für die Return-Adressen, und das funktioniert zumindest für
> Applesoft-BASIC (auch ein MS-BASIC-Derivat):

OK, das stimmt natürlich.

Beim 6502 mit seinen 256 Bytes war nur der Stack ziemlich schnell
voll...

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

#44992

Am 04.07.2024 um 19:39 schrieb Thomas Koenig:
> Peter J. Holzer <hjp-usenet4@hjp.at> schrieb:
>> Ich meinte für die Return-Adressen, und das funktioniert zumindest für
>> Applesoft-BASIC (auch ein MS-BASIC-Derivat):
> 
> OK, das stimmt natürlich.
> 
> Beim 6502 mit seinen 256 Bytes war nur der Stack ziemlich schnell
> voll...

Ein typischer Interpreter nutzt für GOSUB/RETURN nicht den
Prozessor-Stack, sondern baut sich da selbst was.

Das geht soweit, dass du bei den späteren BASIC-Dialekten sowas wie

   sub foo(a%)
     gosub 100
     print 10
    100 print 20
     if a%=1 then return
     exit sub
   end sub

machen konntest, und es dann zwei verschiedene Stacks gab, einen für
RETURN, einen für EXIT SUB. Beim QuickBasic-Compiler war EXIT SUB
tatsächlich der Prozessor-Stack.


  Stefan

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

#44994

Stefan Reuther <stefan.news@arcor.de> schrieb:
> Am 04.07.2024 um 19:39 schrieb Thomas Koenig:
>> Peter J. Holzer <hjp-usenet4@hjp.at> schrieb:
>>> Ich meinte für die Return-Adressen, und das funktioniert zumindest für
>>> Applesoft-BASIC (auch ein MS-BASIC-Derivat):
>> 
>> OK, das stimmt natürlich.
>> 
>> Beim 6502 mit seinen 256 Bytes war nur der Stack ziemlich schnell
>> voll...
>
> Ein typischer Interpreter nutzt für GOSUB/RETURN nicht den
> Prozessor-Stack, sondern baut sich da selbst was.

Beim C64 war es zumindest der Prozessor-Stack.

>
> Das geht soweit, dass du bei den späteren BASIC-Dialekten sowas wie
>
>    sub foo(a%)
>      gosub 100
>      print 10
>     100 print 20
>      if a%=1 then return
>      exit sub
>    end sub
>
> machen konntest,

Klar, aber das war ja auch kein BASIC mehr, das war dekadent :-)

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

#44999

Am 05.07.2024 um 21:57 schrieb Thomas Koenig:
> Stefan Reuther <stefan.news@arcor.de> schrieb:
>> Am 04.07.2024 um 19:39 schrieb Thomas Koenig:
>>> Beim 6502 mit seinen 256 Bytes war nur der Stack ziemlich schnell
>>> voll...
>>
>> Ein typischer Interpreter nutzt für GOSUB/RETURN nicht den
>> Prozessor-Stack, sondern baut sich da selbst was.
> 
> Beim C64 war es zumindest der Prozessor-Stack.

In der Tat.

https://github.com/mist64/msbasic/blob/master/flow2.s#L12
https://github.com/mist64/msbasic/blob/master/flow2.s#L79

Wer macht denn sowas?!


Wieder was gelernt,
Stefan

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

#45001

On 2024-07-06 07:36, Stefan Reuther <stefan.news@arcor.de> wrote:
> Am 05.07.2024 um 21:57 schrieb Thomas Koenig:
>> Stefan Reuther <stefan.news@arcor.de> schrieb:
>>> Am 04.07.2024 um 19:39 schrieb Thomas Koenig:
>>>> Beim 6502 mit seinen 256 Bytes war nur der Stack ziemlich schnell
>>>> voll...
>>>
>>> Ein typischer Interpreter nutzt für GOSUB/RETURN nicht den
>>> Prozessor-Stack, sondern baut sich da selbst was.
>> 
>> Beim C64 war es zumindest der Prozessor-Stack.
>
> In der Tat.
>
> https://github.com/mist64/msbasic/blob/master/flow2.s#L12
> https://github.com/mist64/msbasic/blob/master/flow2.s#L79
>
> Wer macht denn sowas?!

Guido? Bei CPython wird belegt Rekursion auch Platz am Prozessor-Stack.
IMHO eine etwas unglückliche Designentscheidung. Zwar sind Stacks heute
viel größer als damals, aber im Vergleich zum Gesamtspeicher eher
kleiner. Am C64 waren 256 Bytes ein 256stel des RAMs (bzw. ca. ein
150stel des sichtbaren RAMs). Auf einem Linux-Rechner mit angenommen
16 GB RAM sind 8 MB Stack nur ein 2048stel.

        hp

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web