R
Rolf Bombach
Guest
Gerhard Hoffmann schrieb:
Das waren auch Prozessoren und nicht Intel-Quark.
--
mfg Rolf Bombach
Das waren auch Prozessoren und nicht Intel-Quark.
--
mfg Rolf Bombach
Navigation
Install the app
How to install the app on iOS
Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
More options
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
R
Rolf Bombach
Guest
Gerhard Hoffmann schrieb:
Das waren auch Prozessoren und nicht Intel-Quark.
--
mfg Rolf Bombach
Und ja, UCSD-Pascal auf dem 68000 oder einer umprogrammierten
LSI-11Â ( aka Western Digital p-code machine) war schon geil.
Das waren auch Prozessoren und nicht Intel-Quark.
--
mfg Rolf Bombach
S
Sieghard Schicktanz
Guest
Hallo Helmut,
Du schriebst am Tue, 12 May 2020 15:09:41 +0200:
Nachdem auch C nur Turing-vollständig ist und sonst nix besonderes, geht
das umgekehrt auch. Man muà nur die teils verqueren C-Konstruktionen in
sinnvolle Bearbeitung umarbeiten.
Ja, direkt unsinnig. Das zeigen manche C-Programmierer überdeutlich.
Vor allem problematische und unsichere Konstrukte können sehr direkt in C
programmiert werden, darauf beruhen fast alle \"Exploits\".
Dann programmier\' doch mal verschachtelte Funktionen in Standard-C.
Also sowas in der Art (C-Syntax-artig):
int F1 (int p; bool c)
{
int lokal; ...
bool f2 (array f)
{
...
return f [lokal];
}
...
erg= f2 (wert1, flag);
...
}
Geht nicht? Gibt\'s doch nicht!
Geht doch ganz einfach in Pascal! Ging schon in grauer Vorzeit in Algol.
Und in anderen Programmiersprachen, die älter sind als C.
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen GrüÃen, S. Schicktanz
-----------------------------------------------------------
Du schriebst am Tue, 12 May 2020 15:09:41 +0200:
Man kann Quelltexte anderer Sprachen fast immer/vollständig direkt
in C übersetzen, aber umgekehrt geht das nicht.
Nachdem auch C nur Turing-vollständig ist und sonst nix besonderes, geht
das umgekehrt auch. Man muà nur die teils verqueren C-Konstruktionen in
sinnvolle Bearbeitung umarbeiten.
In C kann alles Denkbare direkt programmiert werden - in anderen
Sprachen nicht.
Die Betonung liegt auf \'direkt\'.
Ja, direkt unsinnig. Das zeigen manche C-Programmierer überdeutlich.
Vor allem problematische und unsichere Konstrukte können sehr direkt in C
programmiert werden, darauf beruhen fast alle \"Exploits\".
In C kann fast jede Syntaxkonstruktion beliebig verschachtelt werden.
(Inklusive Rekursion.)
In anderen Sprachen, wie z.B. PEARL, meist keine Verschachtelungen
möglich, oder nur bei wenigen Konstruktionen.
Dann programmier\' doch mal verschachtelte Funktionen in Standard-C.
Also sowas in der Art (C-Syntax-artig):
int F1 (int p; bool c)
{
int lokal; ...
bool f2 (array f)
{
...
return f [lokal];
}
...
erg= f2 (wert1, flag);
...
}
Geht nicht? Gibt\'s doch nicht!
Geht doch ganz einfach in Pascal! Ging schon in grauer Vorzeit in Algol.
Und in anderen Programmiersprachen, die älter sind als C.
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen GrüÃen, S. Schicktanz
-----------------------------------------------------------
S
Sieghard Schicktanz
Guest
Hallo Helmut,
Du schriebst am Tue, 12 May 2020 15:09:41 +0200:
Nachdem auch C nur Turing-vollständig ist und sonst nix besonderes, geht
das umgekehrt auch. Man muà nur die teils verqueren C-Konstruktionen in
sinnvolle Bearbeitung umarbeiten.
Ja, direkt unsinnig. Das zeigen manche C-Programmierer überdeutlich.
Vor allem problematische und unsichere Konstrukte können sehr direkt in C
programmiert werden, darauf beruhen fast alle \"Exploits\".
Dann programmier\' doch mal verschachtelte Funktionen in Standard-C.
Also sowas in der Art (C-Syntax-artig):
int F1 (int p; bool c)
{
int lokal; ...
bool f2 (array f)
{
...
return f [lokal];
}
...
erg= f2 (wert1, flag);
...
}
Geht nicht? Gibt\'s doch nicht!
Geht doch ganz einfach in Pascal! Ging schon in grauer Vorzeit in Algol.
Und in anderen Programmiersprachen, die älter sind als C.
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen GrüÃen, S. Schicktanz
-----------------------------------------------------------
Du schriebst am Tue, 12 May 2020 15:09:41 +0200:
Man kann Quelltexte anderer Sprachen fast immer/vollständig direkt
in C übersetzen, aber umgekehrt geht das nicht.
Nachdem auch C nur Turing-vollständig ist und sonst nix besonderes, geht
das umgekehrt auch. Man muà nur die teils verqueren C-Konstruktionen in
sinnvolle Bearbeitung umarbeiten.
In C kann alles Denkbare direkt programmiert werden - in anderen
Sprachen nicht.
Die Betonung liegt auf \'direkt\'.
Ja, direkt unsinnig. Das zeigen manche C-Programmierer überdeutlich.
Vor allem problematische und unsichere Konstrukte können sehr direkt in C
programmiert werden, darauf beruhen fast alle \"Exploits\".
In C kann fast jede Syntaxkonstruktion beliebig verschachtelt werden.
(Inklusive Rekursion.)
In anderen Sprachen, wie z.B. PEARL, meist keine Verschachtelungen
möglich, oder nur bei wenigen Konstruktionen.
Dann programmier\' doch mal verschachtelte Funktionen in Standard-C.
Also sowas in der Art (C-Syntax-artig):
int F1 (int p; bool c)
{
int lokal; ...
bool f2 (array f)
{
...
return f [lokal];
}
...
erg= f2 (wert1, flag);
...
}
Geht nicht? Gibt\'s doch nicht!
Geht doch ganz einfach in Pascal! Ging schon in grauer Vorzeit in Algol.
Und in anderen Programmiersprachen, die älter sind als C.
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen GrüÃen, S. Schicktanz
-----------------------------------------------------------
H
Helmut Schellong
Guest
On 05/12/2020 23:59, Sieghard Schicktanz wrote:
Eben.
Bei Ãbersetzung in C entfällt das (und Anderes).
C ist sehr wohl etwas Besonderes.
Z.B. der Präprozessor.
Die immense Verbreitung von C muà einen Grund haben.
Manche Programmierer machen Unsinniges in C - manche, nicht alle.
Das ist doch keine Argument.
Pascal und PEARL können verschachtelte Funktionen, aber keine Rekursion.
Bei C ist es umgekehrt.
Verschachtelte Funktions-Definitionen sind reichlich unwichtig
im Vergleich zur Rekursion.
--
Mit freundlichen GrüÃen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
http://www.schellong.de/htm/audio_proj.htm
http://www.schellong.de/htm/audio_unsinn.htm
Hallo Helmut,
Du schriebst am Tue, 12 May 2020 15:09:41 +0200:
Man kann Quelltexte anderer Sprachen fast immer/vollständig direkt
in C übersetzen, aber umgekehrt geht das nicht.
Nachdem auch C nur Turing-vollständig ist und sonst nix besonderes, geht
das umgekehrt auch. Man muà nur die teils verqueren C-Konstruktionen in
sinnvolle Bearbeitung umarbeiten.
Eben.
Bei Ãbersetzung in C entfällt das (und Anderes).
C ist sehr wohl etwas Besonderes.
Z.B. der Präprozessor.
Die immense Verbreitung von C muà einen Grund haben.
In C kann alles Denkbare direkt programmiert werden - in anderen
Sprachen nicht.
Die Betonung liegt auf \'direkt\'.
Ja, direkt unsinnig. Das zeigen manche C-Programmierer überdeutlich.
Vor allem problematische und unsichere Konstrukte können sehr direkt in C
programmiert werden, darauf beruhen fast alle \"Exploits\".
Manche Programmierer machen Unsinniges in C - manche, nicht alle.
In C kann fast jede Syntaxkonstruktion beliebig verschachtelt werden.
(Inklusive Rekursion.)
In anderen Sprachen, wie z.B. PEARL, meist keine Verschachtelungen
möglich, oder nur bei wenigen Konstruktionen.
Dann programmier\' doch mal verschachtelte Funktionen in Standard-C.
Also sowas in der Art (C-Syntax-artig):
[Quelltext]
Geht doch ganz einfach in Pascal! Ging schon in grauer Vorzeit in Algol.
Und in anderen Programmiersprachen, die älter sind als C.
Das ist doch keine Argument.
Pascal und PEARL können verschachtelte Funktionen, aber keine Rekursion.
Bei C ist es umgekehrt.
Verschachtelte Funktions-Definitionen sind reichlich unwichtig
im Vergleich zur Rekursion.
--
Mit freundlichen GrüÃen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
http://www.schellong.de/htm/audio_proj.htm
http://www.schellong.de/htm/audio_unsinn.htm
H
Helmut Schellong
Guest
On 05/12/2020 23:59, Sieghard Schicktanz wrote:
Eben.
Bei Ãbersetzung in C entfällt das (und Anderes).
C ist sehr wohl etwas Besonderes.
Z.B. der Präprozessor.
Die immense Verbreitung von C muà einen Grund haben.
Manche Programmierer machen Unsinniges in C - manche, nicht alle.
Das ist doch keine Argument.
Pascal und PEARL können verschachtelte Funktionen, aber keine Rekursion.
Bei C ist es umgekehrt.
Verschachtelte Funktions-Definitionen sind reichlich unwichtig
im Vergleich zur Rekursion.
--
Mit freundlichen GrüÃen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
http://www.schellong.de/htm/audio_proj.htm
http://www.schellong.de/htm/audio_unsinn.htm
Hallo Helmut,
Du schriebst am Tue, 12 May 2020 15:09:41 +0200:
Man kann Quelltexte anderer Sprachen fast immer/vollständig direkt
in C übersetzen, aber umgekehrt geht das nicht.
Nachdem auch C nur Turing-vollständig ist und sonst nix besonderes, geht
das umgekehrt auch. Man muà nur die teils verqueren C-Konstruktionen in
sinnvolle Bearbeitung umarbeiten.
Eben.
Bei Ãbersetzung in C entfällt das (und Anderes).
C ist sehr wohl etwas Besonderes.
Z.B. der Präprozessor.
Die immense Verbreitung von C muà einen Grund haben.
In C kann alles Denkbare direkt programmiert werden - in anderen
Sprachen nicht.
Die Betonung liegt auf \'direkt\'.
Ja, direkt unsinnig. Das zeigen manche C-Programmierer überdeutlich.
Vor allem problematische und unsichere Konstrukte können sehr direkt in C
programmiert werden, darauf beruhen fast alle \"Exploits\".
Manche Programmierer machen Unsinniges in C - manche, nicht alle.
In C kann fast jede Syntaxkonstruktion beliebig verschachtelt werden.
(Inklusive Rekursion.)
In anderen Sprachen, wie z.B. PEARL, meist keine Verschachtelungen
möglich, oder nur bei wenigen Konstruktionen.
Dann programmier\' doch mal verschachtelte Funktionen in Standard-C.
Also sowas in der Art (C-Syntax-artig):
[Quelltext]
Geht doch ganz einfach in Pascal! Ging schon in grauer Vorzeit in Algol.
Und in anderen Programmiersprachen, die älter sind als C.
Das ist doch keine Argument.
Pascal und PEARL können verschachtelte Funktionen, aber keine Rekursion.
Bei C ist es umgekehrt.
Verschachtelte Funktions-Definitionen sind reichlich unwichtig
im Vergleich zur Rekursion.
--
Mit freundlichen GrüÃen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
http://www.schellong.de/htm/audio_proj.htm
http://www.schellong.de/htm/audio_unsinn.htm
G
Gerhard Hoffmann
Guest
Am 12.05.20 um 23:59 schrieb Sieghard Schicktanz:
Und? Wofür soll dieser Schwachsinn gut sein? Nur, damit f2 ausserhalb
von f1 unbekannt ist? Oder dass lokal ausserhalb unbekannt ist? Tolles
feature. Eine Funktion, die Contexteigenheiten von ausserhalb braucht,
welch ein Gewinn an Abstraktion und Kapselung! Creeping featureism,
und was drinnen ist, ist nicht mehr als ein Textmakro ohne eigene Semantik.
Algol68 kannte _einige_ Sprachkonstrukte, die nie ein Compiler
hin-bekommen hat bis die Sprache irrelevant war. Der Mindset kotzt uns
in Ada und VHDL heute noch an, die sind aus der Algol68-Tradition.
10 Jahre alte Sprachstandards, die der Compiler des Marktführers dann
immer noch nicht beherrscht.
Ja, mit Simula hätte ich mich anfreunden können. Algol mit Klassen
und Pointern, ohne den Dreck. Aber C ist auch voll OK. Wer den Unix-
Kernel gelesen hat, der weiss wie\'s geht. Einfach nur schön.
Gerhard
Hallo Helmut,
Dann programmier\' doch mal verschachtelte Funktionen in Standard-C.
Also sowas in der Art (C-Syntax-artig):
int F1 (int p; bool c)
{
int lokal; ...
bool f2 (array f)
{
...
return f [lokal];
}
...
erg= f2 (wert1, flag);
...
}
Geht nicht? Gibt\'s doch nicht!
Geht doch ganz einfach in Pascal! Ging schon in grauer Vorzeit in Algol.
Und in anderen Programmiersprachen, die älter sind als C.
Und? Wofür soll dieser Schwachsinn gut sein? Nur, damit f2 ausserhalb
von f1 unbekannt ist? Oder dass lokal ausserhalb unbekannt ist? Tolles
feature. Eine Funktion, die Contexteigenheiten von ausserhalb braucht,
welch ein Gewinn an Abstraktion und Kapselung! Creeping featureism,
und was drinnen ist, ist nicht mehr als ein Textmakro ohne eigene Semantik.
Algol68 kannte _einige_ Sprachkonstrukte, die nie ein Compiler
hin-bekommen hat bis die Sprache irrelevant war. Der Mindset kotzt uns
in Ada und VHDL heute noch an, die sind aus der Algol68-Tradition.
10 Jahre alte Sprachstandards, die der Compiler des Marktführers dann
immer noch nicht beherrscht.
Ja, mit Simula hätte ich mich anfreunden können. Algol mit Klassen
und Pointern, ohne den Dreck. Aber C ist auch voll OK. Wer den Unix-
Kernel gelesen hat, der weiss wie\'s geht. Einfach nur schön.
Gerhard
G
Gerhard Hoffmann
Guest
Am 12.05.20 um 23:59 schrieb Sieghard Schicktanz:
Und? Wofür soll dieser Schwachsinn gut sein? Nur, damit f2 ausserhalb
von f1 unbekannt ist? Oder dass lokal ausserhalb unbekannt ist? Tolles
feature. Eine Funktion, die Contexteigenheiten von ausserhalb braucht,
welch ein Gewinn an Abstraktion und Kapselung! Creeping featureism,
und was drinnen ist, ist nicht mehr als ein Textmakro ohne eigene Semantik.
Algol68 kannte _einige_ Sprachkonstrukte, die nie ein Compiler
hin-bekommen hat bis die Sprache irrelevant war. Der Mindset kotzt uns
in Ada und VHDL heute noch an, die sind aus der Algol68-Tradition.
10 Jahre alte Sprachstandards, die der Compiler des Marktführers dann
immer noch nicht beherrscht.
Ja, mit Simula hätte ich mich anfreunden können. Algol mit Klassen
und Pointern, ohne den Dreck. Aber C ist auch voll OK. Wer den Unix-
Kernel gelesen hat, der weiss wie\'s geht. Einfach nur schön.
Gerhard
Hallo Helmut,
Dann programmier\' doch mal verschachtelte Funktionen in Standard-C.
Also sowas in der Art (C-Syntax-artig):
int F1 (int p; bool c)
{
int lokal; ...
bool f2 (array f)
{
...
return f [lokal];
}
...
erg= f2 (wert1, flag);
...
}
Geht nicht? Gibt\'s doch nicht!
Geht doch ganz einfach in Pascal! Ging schon in grauer Vorzeit in Algol.
Und in anderen Programmiersprachen, die älter sind als C.
Und? Wofür soll dieser Schwachsinn gut sein? Nur, damit f2 ausserhalb
von f1 unbekannt ist? Oder dass lokal ausserhalb unbekannt ist? Tolles
feature. Eine Funktion, die Contexteigenheiten von ausserhalb braucht,
welch ein Gewinn an Abstraktion und Kapselung! Creeping featureism,
und was drinnen ist, ist nicht mehr als ein Textmakro ohne eigene Semantik.
Algol68 kannte _einige_ Sprachkonstrukte, die nie ein Compiler
hin-bekommen hat bis die Sprache irrelevant war. Der Mindset kotzt uns
in Ada und VHDL heute noch an, die sind aus der Algol68-Tradition.
10 Jahre alte Sprachstandards, die der Compiler des Marktführers dann
immer noch nicht beherrscht.
Ja, mit Simula hätte ich mich anfreunden können. Algol mit Klassen
und Pointern, ohne den Dreck. Aber C ist auch voll OK. Wer den Unix-
Kernel gelesen hat, der weiss wie\'s geht. Einfach nur schön.
Gerhard
R
Roland Franzius
Guest
Am 12.05.2020 um 21:00 schrieb Rolf Bombach:
Klar, da konnte man beim Programmieren und Prozessieren nebenher noch
Blumen pflücken gehen. Meistens sass der gesamte Fachbereich in der
Cafeteria und wartete.
--
Roland Franzius
Gerhard Hoffmann schrieb:
Und ja, UCSD-Pascal auf dem 68000 oder einer umprogrammierten
LSI-11Â ( aka Western Digital p-code machine) war schon geil.
Das waren auch Prozessoren und nicht Intel-Quark.
Klar, da konnte man beim Programmieren und Prozessieren nebenher noch
Blumen pflücken gehen. Meistens sass der gesamte Fachbereich in der
Cafeteria und wartete.
--
Roland Franzius
M
Marc Haber
Guest
Willi Marquart <usenet@neppi.net> wrote:
https://www.mikrocontroller.net/topic/53447
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | \" Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom \" |
Nordisch by Nature | Lt. Worf, TNG \"Rightful Heir\" | Fon: *49 621 72739834
Marc Haber schrieb:
Willi Marquart <usenet@neppi.net> wrote:
Marc Haber schrieb:
google \"echte programmierer meiden Pascal\".
hing schon 1983 an meinem Gymnasium im Computerraum.
Die Lesbarkeit von C-Programmen ist wirklich vorbildlich, die
Ãbertragung nach Pascal ist mir leider nicht gelungen!
Thema verfehlt.
Wieso? Echte Programmierer meiden Pascal, weil man sowas nicht in
Pascal schreiben kann.
Passt doch.
https://www.mikrocontroller.net/topic/53447
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | \" Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom \" |
Nordisch by Nature | Lt. Worf, TNG \"Rightful Heir\" | Fon: *49 621 72739834
M
Marc Haber
Guest
Willi Marquart <usenet@neppi.net> wrote:
https://www.mikrocontroller.net/topic/53447
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | \" Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom \" |
Nordisch by Nature | Lt. Worf, TNG \"Rightful Heir\" | Fon: *49 621 72739834
Marc Haber schrieb:
Willi Marquart <usenet@neppi.net> wrote:
Marc Haber schrieb:
google \"echte programmierer meiden Pascal\".
hing schon 1983 an meinem Gymnasium im Computerraum.
Die Lesbarkeit von C-Programmen ist wirklich vorbildlich, die
Ãbertragung nach Pascal ist mir leider nicht gelungen!
Thema verfehlt.
Wieso? Echte Programmierer meiden Pascal, weil man sowas nicht in
Pascal schreiben kann.
Passt doch.
https://www.mikrocontroller.net/topic/53447
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | \" Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom \" |
Nordisch by Nature | Lt. Worf, TNG \"Rightful Heir\" | Fon: *49 621 72739834
C
Christian Treffler
Guest
Rolf Bombach schrieb:
Ich will jetzt Kurt nicht bestätigen, denn meiner Erfahrung nach gibt es
auf Transistor-Ebene keine Probleme durch Temperatur-Schwankungen.
Aber Schichten unterschiedlichen Materials gibt es bei jedem Transistor,
und wenn es nur (bei einem diskreten) das Al-Bond-Pad ist.
MOS-Transistoren haben zwingend eine Gate-Isolations-Schicht.
Moderne FINFETs (und bestimmt auch ältere Technologien) haben
zusätzliche Poly-Silizium-Aufbauten.
CU,
Christian
Kurt schrieb:
Das, worum es hier geht, hat doch nichts mit der Anzahl Fremdatome in Silizium zu tun.
Ein Transistor hat nunmal unterschiedliche Schichten, schliesslich müssen diese ja irgendwie dotiert werden.
Wenn man schon unterschiedliche Schichten hat, muss man nicht mehr dotieren.
Dotieren muss man, wenn man nur eine Schicht hat.
Logisch oder?
Ich will jetzt Kurt nicht bestätigen, denn meiner Erfahrung nach gibt es
auf Transistor-Ebene keine Probleme durch Temperatur-Schwankungen.
Aber Schichten unterschiedlichen Materials gibt es bei jedem Transistor,
und wenn es nur (bei einem diskreten) das Al-Bond-Pad ist.
MOS-Transistoren haben zwingend eine Gate-Isolations-Schicht.
Moderne FINFETs (und bestimmt auch ältere Technologien) haben
zusätzliche Poly-Silizium-Aufbauten.
CU,
Christian
C
Christian Treffler
Guest
Rolf Bombach schrieb:
Ich will jetzt Kurt nicht bestätigen, denn meiner Erfahrung nach gibt es
auf Transistor-Ebene keine Probleme durch Temperatur-Schwankungen.
Aber Schichten unterschiedlichen Materials gibt es bei jedem Transistor,
und wenn es nur (bei einem diskreten) das Al-Bond-Pad ist.
MOS-Transistoren haben zwingend eine Gate-Isolations-Schicht.
Moderne FINFETs (und bestimmt auch ältere Technologien) haben
zusätzliche Poly-Silizium-Aufbauten.
CU,
Christian
Kurt schrieb:
Das, worum es hier geht, hat doch nichts mit der Anzahl Fremdatome in Silizium zu tun.
Ein Transistor hat nunmal unterschiedliche Schichten, schliesslich müssen diese ja irgendwie dotiert werden.
Wenn man schon unterschiedliche Schichten hat, muss man nicht mehr dotieren.
Dotieren muss man, wenn man nur eine Schicht hat.
Logisch oder?
Ich will jetzt Kurt nicht bestätigen, denn meiner Erfahrung nach gibt es
auf Transistor-Ebene keine Probleme durch Temperatur-Schwankungen.
Aber Schichten unterschiedlichen Materials gibt es bei jedem Transistor,
und wenn es nur (bei einem diskreten) das Al-Bond-Pad ist.
MOS-Transistoren haben zwingend eine Gate-Isolations-Schicht.
Moderne FINFETs (und bestimmt auch ältere Technologien) haben
zusätzliche Poly-Silizium-Aufbauten.
CU,
Christian
H
Helmut Schellong
Guest
On 05/14/2020 09:33, Christian Treffler wrote:
Die Formulierung mit den unterschiedlichen Schichten führt zu
Mißverständnissen.
In das dicke Silizium-Substrat werden nur wenige µm dicke Bereiche
mit Fremdatomen versehen.
Dadurch entsteht nach meiner Meinung keine Bruchempfindlichkeit
an den Schnittstellen durch Temperaturwechsel.
--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
http://www.schellong.de/htm/audio_proj.htm
http://www.schellong.de/htm/audio_unsinn.htm
Rolf Bombach schrieb:
Kurt schrieb:
Das, worum es hier geht, hat doch nichts mit der Anzahl Fremdatome in Silizium zu tun.
Ein Transistor hat nunmal unterschiedliche Schichten, schliesslich müssen diese ja irgendwie dotiert werden.
Wenn man schon unterschiedliche Schichten hat, muss man nicht mehr dotieren.
Dotieren muss man, wenn man nur eine Schicht hat.
Logisch oder?
Ich will jetzt Kurt nicht bestätigen, denn meiner Erfahrung nach gibt es
auf Transistor-Ebene keine Probleme durch Temperatur-Schwankungen.
Aber Schichten unterschiedlichen Materials gibt es bei jedem Transistor,
und wenn es nur (bei einem diskreten) das Al-Bond-Pad ist.
MOS-Transistoren haben zwingend eine Gate-Isolations-Schicht.
Moderne FINFETs (und bestimmt auch ältere Technologien) haben
zusätzliche Poly-Silizium-Aufbauten.
Die Formulierung mit den unterschiedlichen Schichten führt zu
Mißverständnissen.
In das dicke Silizium-Substrat werden nur wenige µm dicke Bereiche
mit Fremdatomen versehen.
Dadurch entsteht nach meiner Meinung keine Bruchempfindlichkeit
an den Schnittstellen durch Temperaturwechsel.
--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
http://www.schellong.de/htm/audio_proj.htm
http://www.schellong.de/htm/audio_unsinn.htm
H
Helmut Schellong
Guest
On 05/14/2020 09:33, Christian Treffler wrote:
Die Formulierung mit den unterschiedlichen Schichten führt zu
Mißverständnissen.
In das dicke Silizium-Substrat werden nur wenige µm dicke Bereiche
mit Fremdatomen versehen.
Dadurch entsteht nach meiner Meinung keine Bruchempfindlichkeit
an den Schnittstellen durch Temperaturwechsel.
--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
http://www.schellong.de/htm/audio_proj.htm
http://www.schellong.de/htm/audio_unsinn.htm
Rolf Bombach schrieb:
Kurt schrieb:
Das, worum es hier geht, hat doch nichts mit der Anzahl Fremdatome in Silizium zu tun.
Ein Transistor hat nunmal unterschiedliche Schichten, schliesslich müssen diese ja irgendwie dotiert werden.
Wenn man schon unterschiedliche Schichten hat, muss man nicht mehr dotieren.
Dotieren muss man, wenn man nur eine Schicht hat.
Logisch oder?
Ich will jetzt Kurt nicht bestätigen, denn meiner Erfahrung nach gibt es
auf Transistor-Ebene keine Probleme durch Temperatur-Schwankungen.
Aber Schichten unterschiedlichen Materials gibt es bei jedem Transistor,
und wenn es nur (bei einem diskreten) das Al-Bond-Pad ist.
MOS-Transistoren haben zwingend eine Gate-Isolations-Schicht.
Moderne FINFETs (und bestimmt auch ältere Technologien) haben
zusätzliche Poly-Silizium-Aufbauten.
Die Formulierung mit den unterschiedlichen Schichten führt zu
Mißverständnissen.
In das dicke Silizium-Substrat werden nur wenige µm dicke Bereiche
mit Fremdatomen versehen.
Dadurch entsteht nach meiner Meinung keine Bruchempfindlichkeit
an den Schnittstellen durch Temperaturwechsel.
--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
http://www.schellong.de/htm/audio_proj.htm
http://www.schellong.de/htm/audio_unsinn.htm
H
Helmut Schellong
Guest
On 05/13/2020 23:12, Sieghard Schicktanz wrote:
Die Diskussion schweift ab.
Es ging darum, andere Sprachen in C zu übersetzen.
Das geht fast immer einfach und direkt.
Mit anderen Ãbersetzungs-Zielsprachen ist das nur schwer möglich.
Direkte Ãbersetzung meist unmöglich.
C hat auf (fast) jede Konstruktion einer anderen Sprache eine Antwort.
Meistens eine direkte Antwort.
Für fast alle anderen Sprachen gilt das nicht.
Der ist extrem sinnvoll und nützlich.
Die Hauptgründe für die immense Verbreitung von C sind andere.
Habe ich bereits beschrieben.
Du bist ein C-Feind.
Es ist daher reichlich sinnlos, sich mit Dir darüber zu unterhalten.
Mindestens 99% (eher 99,9%) aller C-Programmierer programmieren sinnvoll.
Diejenigen, die in C Quark programmieren, sind keine Profi-Programmierer,
sondern Quatschköppe, die mit anderen Absichten die Foren bevölkern.
> Du kennst halt nix anderes auÃer ein bisserl C.
Ich beherrsche etwa 15 Programmiersprachen unterschiedlich gut.
Und ich habe drei C-Bücher geschrieben.
http://www.amazon.de/exec/obidos/ISBN=3642544363
Es stimmt, daà Pascal rekursive Funktionen kann.
Aber PEARL m.W. nicht.
Das ist alles vollkommen irrelevant.
Denn es gilt jeweils immer nur der aktuelle C-Standard.
Ich wuÃte nicht, daà gcc verschachtelte Funktionsdefinitionen kann.
Dieses Merkmal ist unwichtig und es ist kein Bestandteil von C, sondern
ein nicht standard-konformer C-Dialekt.
Auf meinem System (FreeBSD) ist clang der C-Compiler.
--
Mit freundlichen GrüÃen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
http://www.schellong.de/htm/audio_proj.htm
http://www.schellong.de/htm/audio_unsinn.htm
Hallo Helmut,
Du schriebst am Wed, 13 May 2020 00:32:18 +0200:
Nachdem auch C nur Turing-vollständig ist und sonst nix besonderes, geht
das umgekehrt auch. Man muà nur die teils verqueren C-Konstruktionen in
sinnvolle Bearbeitung umarbeiten.
Eben.
Bei Ãbersetzung in C entfällt das (und Anderes).
Natürlich. Bei Ãbersetzung eines C-Programms in C entfällt fast alles,
was nach Arbeit aussieht. Jedenfalls dann, wenn der Compiler ein Kompilat
produziert.
Die Diskussion schweift ab.
Es ging darum, andere Sprachen in C zu übersetzen.
Das geht fast immer einfach und direkt.
Mit anderen Ãbersetzungs-Zielsprachen ist das nur schwer möglich.
Direkte Ãbersetzung meist unmöglich.
C hat auf (fast) jede Konstruktion einer anderen Sprache eine Antwort.
Meistens eine direkte Antwort.
Für fast alle anderen Sprachen gilt das nicht.
C ist sehr wohl etwas Besonderes.
Z.B. der Präprozessor.
Ja, der ist ein eigenes Höllenloch.
Der ist extrem sinnvoll und nützlich.
Die immense Verbreitung von C muà einen Grund haben.
Sicher: die Verbreitung von C.
Die Hauptgründe für die immense Verbreitung von C sind andere.
Habe ich bereits beschrieben.
Vor allem problematische und unsichere Konstrukte können sehr direkt in
C programmiert werden, darauf beruhen fast alle \"Exploits\".
Manche Programmierer machen Unsinniges in C - manche, nicht alle.
Umgedreht: Manche Programmierer machen Sinnvolles in C - manche, nicht alle.
Du bist ein C-Feind.
Es ist daher reichlich sinnlos, sich mit Dir darüber zu unterhalten.
Mindestens 99% (eher 99,9%) aller C-Programmierer programmieren sinnvoll.
Diejenigen, die in C Quark programmieren, sind keine Profi-Programmierer,
sondern Quatschköppe, die mit anderen Absichten die Foren bevölkern.
> Du kennst halt nix anderes auÃer ein bisserl C.
Ich beherrsche etwa 15 Programmiersprachen unterschiedlich gut.
Und ich habe drei C-Bücher geschrieben.
http://www.amazon.de/exec/obidos/ISBN=3642544363
Klar kann Pascal _auch_
Rekursion, es ist schlieÃlich ebenfalls Turing-vollständig.
(PEARL kenn\' ich dahingehend nicht, nur dem Namen nach.)
Es stimmt, daà Pascal rekursive Funktionen kann.
Aber PEARL m.W. nicht.
Verschachtelte Funktions-Definitionen sind reichlich unwichtig
im Vergleich zur Rekursion.
Abersicherdochjedenfalls. So unwichtig, daà einer der verbreitetsten
C-Compiler, der gcc, das als eine Erweiterung ebenfalls implementiert
gekriegt hat.
Und mit jeder neuen Version findet man wieder weitere Ãbernahmen aus den
alten Sprachen der Algol-Familie, von Syntaxerweiterungen über Typprüfungen
bis hin zu Bereichsprüfungen. Inzwischen fangen sie schon zum übertreiben
an und mosern auch über \"falsche\" Quellentext-Formatierung.
Das ist alles vollkommen irrelevant.
Denn es gilt jeweils immer nur der aktuelle C-Standard.
Ich wuÃte nicht, daà gcc verschachtelte Funktionsdefinitionen kann.
Dieses Merkmal ist unwichtig und es ist kein Bestandteil von C, sondern
ein nicht standard-konformer C-Dialekt.
Auf meinem System (FreeBSD) ist clang der C-Compiler.
--
Mit freundlichen GrüÃen
Helmut Schellong var@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
http://www.schellong.de/htm/audio_proj.htm
http://www.schellong.de/htm/audio_unsinn.htm
R
Rolf Bombach
Guest
Helmut Schellong schrieb:
In den USA war wohl der Entscheid der Militärs (oder JAN(N)AF, habs
vergessen) \"if possible use IC\" massgeblich für den Durchstart
der IC-Schaltungen. Das waren am Anfang lächerlich einfache IC
wie CA3028, und der scheint schon eine Verbesserung der Zuverlässigkeit
gebracht zu haben.
--
mfg Rolf Bombach
Generell steigt die Fehlerwahrscheinlichkeit
mit jeder vorhandenen Lötstelle.
Redundante Lötstellen und reine Befestigungslötungen sind nicht gemeint.
Deshalb ist ein IC mit 8 Pins sicherer als dessen Innenschaltung
diskret aufgebaut mit 350 Lötstellen.
Desweiteren ist ein IC nur 1 Bauelement.
In den USA war wohl der Entscheid der Militärs (oder JAN(N)AF, habs
vergessen) \"if possible use IC\" massgeblich für den Durchstart
der IC-Schaltungen. Das waren am Anfang lächerlich einfache IC
wie CA3028, und der scheint schon eine Verbesserung der Zuverlässigkeit
gebracht zu haben.
--
mfg Rolf Bombach
H
Hans-Peter Diettrich
Guest
Am 12.05.2020 um 23:59 schrieb Sieghard Schicktanz:
Manche Dinge gehen kaum, wie \"interrupt\" für die low-level
Programmierung und Tricks, die man ohne Preprozessor nicht von Hand
hinbekommt.
Aber mit \"alle\" Sprachen geht sowas nicht, probiere mal FORTH oder Lisp
in eine andere Sprachfamilie zu übersetzen.
Das gilt nur für Algorithmen (Syntax), nicht für Attribute.
Z.B. sind in Delphi die subranges sehr hilfreich, bei denen man den
zulässigen Wertebereich exakt vorgeben kann. Und dann kann man jede
Zuweisung zur Laufzeit überwachen lassen, und per Compilerswitch die
Ãberwachung ein- und ausschalten. Solche extrem hilfreichen Konstrukte
findet man in anderen Programmiersprachen eher nicht, und sie lassen
sich auch in C/C++ kaum bis garnicht nachbilden.
Auch Garbage Collection ist so eine Sache, die läuft in Delphi mit
Reference Counting sauber nebenbei, in anderen Sprachen geht nur
mark-sweep, mit Raten und zwangsläufiger Unterbrechung des Programms.
Das sind so Dinge, die mir keine andere Programmierumgebung bietet, egal
für welche Sprache.
DoDi
Hallo Helmut,
Du schriebst am Tue, 12 May 2020 15:09:41 +0200:
Man kann Quelltexte anderer Sprachen fast immer/vollständig direkt
in C übersetzen, aber umgekehrt geht das nicht.
Nachdem auch C nur Turing-vollständig ist und sonst nix besonderes, geht
das umgekehrt auch. Man muà nur die teils verqueren C-Konstruktionen in
sinnvolle Bearbeitung umarbeiten.
Manche Dinge gehen kaum, wie \"interrupt\" für die low-level
Programmierung und Tricks, die man ohne Preprozessor nicht von Hand
hinbekommt.
Aber mit \"alle\" Sprachen geht sowas nicht, probiere mal FORTH oder Lisp
in eine andere Sprachfamilie zu übersetzen.
In C kann alles Denkbare direkt programmiert werden - in anderen
Sprachen nicht.
Die Betonung liegt auf \'direkt\'.
Das gilt nur für Algorithmen (Syntax), nicht für Attribute.
Z.B. sind in Delphi die subranges sehr hilfreich, bei denen man den
zulässigen Wertebereich exakt vorgeben kann. Und dann kann man jede
Zuweisung zur Laufzeit überwachen lassen, und per Compilerswitch die
Ãberwachung ein- und ausschalten. Solche extrem hilfreichen Konstrukte
findet man in anderen Programmiersprachen eher nicht, und sie lassen
sich auch in C/C++ kaum bis garnicht nachbilden.
Auch Garbage Collection ist so eine Sache, die läuft in Delphi mit
Reference Counting sauber nebenbei, in anderen Sprachen geht nur
mark-sweep, mit Raten und zwangsläufiger Unterbrechung des Programms.
Das sind so Dinge, die mir keine andere Programmierumgebung bietet, egal
für welche Sprache.
DoDi