🚀 go-pugleaf

Stefan Werner <009wcqf02@sneakemail.com> wrote:
> Der Mann, der den einzigen Computer herstellte, den ich wirklich 
> vollst?ndig verstand: Den C64.

> R.I.P

Und auch den ATARI ST.

In der Tat, R.I.P.

- Felix

-- 
              Felix Rauch, http://www.trash.net/~xilef/
This article contains my personal view only! Use of my addresses for marketing
    purposes is hereby strictly prohibited according to applicable laws.

Am 12.04.12 05:03, schrieb Felix Rauch:
> Stefan Werner<009wcqf02@sneakemail.com>  wrote:
>> Der Mann, der den einzigen Computer herstellte, den ich wirklich
>> vollst?ndig verstand: Den C64.
>
>> R.I.P
>
> Und auch den ATARI ST.

Wobei TOS/AES/GEM doch immer etwas zusammengeschustert wirkte. Aber ja, 
stimmt: Verglichen mit den damaligen IBM PC wirkte der ST �usserst 
modern. Und ausserdem: Mit dem Ataris ST und Aladdin sowie einer 
gecrackten Mac-Systemdisk hatte man einen bezahlbaren Mac :-)

Das Faszinierende am C64 war, dass er so einfach war. Der 6502/6510 
Prozessor war im Prinzip einfach ein PLA, nichts mit Microcode und so 
sondern alles fest verdrahtet. Jede Bitkombination am Eingang gab einen 
Taktzyklus sp�ter eine entsprechende Reaktion. Manche 
Eingangskombinationen waren dokumentiert, das waren die "offiziellen" 
Maschinenbefehle, und manche waren undokumentiert, die erlaubten zum 
Teil coole Abk�rzungen. Und eine Stufe h�her, das "Betriebssystem", war 
ebenfalls leicht �berschaubar. 8KB und es gab dokumentierte 
ROM-Listings.  Man konnte das System wirklich /verstehen/. Und mit einer 
simplen Port-Anweisung konnte man des Betriebssystem ganz ausblenden und 
hatte den ganzen gigantischen 64KB Adressraum f�r sich :-)

Ich denke, der C64 mit ein Grund daf�r, dass die Nerds meiner Generation 
sich mehr daf�r interessierten, wie ein Programm unter der Haube 
funktioniert, w�hrend die Nerds der "digital natives" sich vor allem 
daf�r interessieren, wie man die Eigenschaften eines Programms ausreizt 
(und nicht, warum es diese Eigenschaften hat).

Ich bin noch nicht sicher, ob ich es gut oder schlecht finde, dass ich 
die Hardware und das Betriebssystem der PC's meiner Kinder viel besser 
behrrsche als sie, w�hrend ich keinerlei Chance habe mitzukommen, wenn 
sie ein aktuelles Spiel oder "Facebook" bedienen. Ich sehe nur schnell 
wechselnde Bildschirminhalte, kann diese aber selber nicht vern�nftig 
interpretieren oder beeinflussen.
Aber wehe, die Grafikkarte oder der Treiber des Gamecontrollers streikt. 
Dann muss Papa wieder ran. Eigentlich sollte es ihnen doch ein Anliegen 
sein zu verstehen, /warum/ der Controller nicht das tut was er soll? Ist 
es aber nicht....

Soweit der philospohische Exkurs zm Abschied von Jack Tramiel, der das 
Volk zum Computer und den Computer zum Volk brachte. (Denn eigentlich 
m�sste man die Story ja beim Commodore PET beginnen, dem ersten 
"personal electronic transactor", sp�ter auch PC genannt.)

-stef

Am 12.04.12 09:54, schrieb Stefan Werner:

> Aber wehe, die Grafikkarte oder der Treiber des Gamecontrollers streikt.
> Dann muss Papa wieder ran. Eigentlich sollte es ihnen doch ein Anliegen
> sein zu verstehen, /warum/ der Controller nicht das tut was er soll? Ist
> es aber nicht....

Naja, fr�her hatten halt Leute Computer um des Computers willen. Heute 
ist er nur noch ein Werkzeug. Und genau so wenig wie jeder 
Waschmaschinenbenutzer wissen will, wie man die Repariert oder jeder 
Autofahrer sein Auto verstehen will, wollen deine Kinder halt den Compi 
verstehen.
Das gab's �brigens durchaus auch schon vor 20, 30 Jahren, nur war es 
seltener.
Ich find's auch schade, andererseits w�re es aber auch seltsam, wenn 
pl�tzlich jeder Mensch ein 'Computerfreak' sein wollte - und benutzten 
tut die Dinger heute ja fast jeder.

Aber ich find's auch lustig... sys 64738, sys 49152, poke 53281,x poke 
53280,x das weiss ich alles noch auswendig. Dann war irgendwas von 0,x 0 
oder 1,x um das ROM auszublenden...? In HEX kenne ich die Adressen nicht 
mehr, auch wenn der C64 das einzige System ist, das ich 'ernsthaft' in 
Assembler programmiert habe.

Am 12.04.12 15:25, schrieb Patrick Kormann:
> Am 12.04.12 09:54, schrieb Stefan Werner:
>
>> Aber wehe, die Grafikkarte oder der Treiber des Gamecontrollers streikt.
>> Dann muss Papa wieder ran. Eigentlich sollte es ihnen doch ein Anliegen
>> sein zu verstehen, /warum/ der Controller nicht das tut was er soll? Ist
>> es aber nicht....
>
> Naja, fr�her hatten halt Leute Computer um des Computers willen. Heute
> ist er nur noch ein Werkzeug. Und genau so wenig wie jeder
> Waschmaschinenbenutzer wissen will, wie man die Repariert oder jeder
> Autofahrer sein Auto verstehen will, wollen deine Kinder halt den Compi
> verstehen.

Ja, da hast Du schon Recht. Wobei beim Auto find ich's auch schade. Bei 
meinem ersten Auto konnte ich den Vergaser noch selber zerlegen, 
durchpusten und neu einstellen, wenn es nicht mehr starten wollte. Beim 
heutigen Auto w�sste ich nicht mal, wo die Einspritzpumpe genau ist, 
geschweige denn, dass ich irgendwas daran reparieren k�nnte. 
Andererseits kommt es allerdings auch gar nicht mehr vor, dass es nicht 
starten will.
Trotzdem: Man wird immer abh�ngiger von Spezialisten und man wird selber 
immer mehr zum Spezialisten.

> Aber ich find's auch lustig... sys 64738, sys 49152, poke 53281,x poke
> 53280,x das weiss ich alles noch auswendig. Dann war irgendwas von 0,x 0
> oder 1,x um das ROM auszublenden...? In HEX kenne ich die Adressen nicht
> mehr, auch wenn der C64 das einzige System ist, das ich 'ernsthaft' in
> Assembler programmiert habe.

Naja, aber dass "sys 49152" in C64-Assembler "jmp $C000" war, weisst Du 
aber schon noch, oder? Sowas vergisst man doch nicht mehr, das ist wie 
Velofahren :-)

-stef

Am 13.04.12 18:37, schrieb Stefan Werner:

> Ja, da hast Du schon Recht. Wobei beim Auto find ich's auch schade. Bei
> meinem ersten Auto konnte ich den Vergaser noch selber zerlegen,
> durchpusten und neu einstellen, wenn es nicht mehr starten wollte. Beim
> heutigen Auto w�sste ich nicht mal, wo die Einspritzpumpe genau ist,
> geschweige denn, dass ich irgendwas daran reparieren k�nnte.
> Andererseits kommt es allerdings auch gar nicht mehr vor, dass es nicht
> starten will.
> Trotzdem: Man wird immer abh�ngiger von Spezialisten und man wird selber
> immer mehr zum Spezialisten.

Schade find ich's auch! Ich w�rd mein Auto gern selbst reparieren k�nnen 
:) ... Mein Vater und mein Bruder sind ja gute Mechaniker, allerdings 
zumindest der Papa halt eher bei der rustikaleren Technik. Bruder hat 
glaub ich auch schon mit Fahrzeugelektronik etwas erfahrung, aber 
naja... Ohne richtige Werkstatt kommst du wohl selbst mit dem Knowhow 
nicht weiter.
Was den Rest angeht, werd ich langsam schon noch zum Heimwerker, ich 
k�mpf hier mit Elektrik, �lheizung und Elektroboiler gleichzeitig ;)

> Naja, aber dass "sys 49152" in C64-Assembler "jmp $C000" war, weisst Du
> aber schon noch, oder? Sowas vergisst man doch nicht mehr, das ist wie
> Velofahren :-)

Ne, das wusste ich nicht mehr. Aus dem Basic hab ich halt eher den sys 
gebraucht und im Assembler war's ja dann eher ne andere Adresse, an die 
man springt. ($C020 oder so ;) ) Mit Labels hat man da ja wohl noch 
nicht gearbeitet? Weiss es nicht mehr ;)

Patrick Kormann wrote:
> Am 13.04.12 18:37, schrieb Stefan Werner:
>> Naja, aber dass "sys 49152" in C64-Assembler "jmp $C000" war, weisst Du
>> aber schon noch, oder? Sowas vergisst man doch nicht mehr, das ist wie
>> Velofahren :-)
>
> Ne, das wusste ich nicht mehr. Aus dem Basic hab ich halt eher den sys
> gebraucht und im Assembler war's ja dann eher ne andere Adresse, an die
> man springt. ($C020 oder so ;) ) Mit Labels hat man da ja wohl noch
> nicht gearbeitet? Weiss es nicht mehr ;)

Naja, mit Hex scheinst Du wohl auf Kriegsfuss zu stehen, sonst w�sstest 
Du, so wie Stefan es erw�hnt, dass $C000 eben #49152 entspricht. Und sys 
war eben das Commodore-Basic-�quivalent f�r den 6510-Befehl jmp.

Der C64 war schon ein geniales Kistchen bei welche ich auch beinahe 
alles verstand. Assembler hab ich mit dem Ding auch gemacht. Aber noch 
so richtig alles zu Fuss :)

Also Assemblercode auf Papier geschrieben.
Assembler-Code per Nachschlagewerk in Hex-Ziffern auf Papier 
umgeschrieben. Die Hex-Werte in Dezimalwerte umgesetzt. Basic-Loader 
geschrieben:

10 FOR X=1TO105
20 READ A
30 POKE 1000+X,A
40 NEXT A
50 SYS 1001
60 DATA 123,232,123,221,...

Ja, das waren noch Zeiten. Aber der VC20 und die Nachfolger waren daf�r 
verantwortlich, was ich heute bin :)

cu
Mario

Am 16.04.12 09:46, schrieb Mario Rothacher:

> Naja, mit Hex scheinst Du wohl auf Kriegsfuss zu stehen, sonst w�sstest
> Du, so wie Stefan es erw�hnt, dass $C000 eben #49152 entspricht. Und sys
> war eben das Commodore-Basic-�quivalent f�r den 6510-Befehl jmp.

Was du nicht sagst. Aber wenn ich ein Programm lade, bin ich im Basic. 
Dann starte ich das mit sys 49152, wenn es dort im Speicher steht. Im 
Programm selbst springe ich relativ selten an die aller erste Adresse 
des Programms, sondern an eine h�here. Darum mein Beispiel mit $C020 
(was auch andeuten sollte, dass die Programme nicht allzu lang waren)

> Also Assemblercode auf Papier geschrieben.
> Assembler-Code per Nachschlagewerk in Hex-Ziffern auf Papier
> umgeschrieben. Die Hex-Werte in Dezimalwerte umgesetzt. Basic-Loader
> geschrieben:

Uff, also so wie die Listings in den Heftchen standen fast. Etwas aufw�ndig.

> 10 FOR X=1TO105
> 20 READ A
> 30 POKE 1000+X,A
> 40 NEXT A
> 50 SYS 1001
> 60 DATA 123,232,123,221,...

Siehe Zeile 50.. oder stehst du auch mit Hex auf Kriegsfuss ;)

Patrick Kormann wrote:
> Am 16.04.12 09:46, schrieb Mario Rothacher:
>> Also Assemblercode auf Papier geschrieben.
>> Assembler-Code per Nachschlagewerk in Hex-Ziffern auf Papier
>> umgeschrieben. Die Hex-Werte in Dezimalwerte umgesetzt. Basic-Loader
>> geschrieben:
>
> Uff, also so wie die Listings in den Heftchen standen fast. Etwas
> aufw�ndig.
>
>> 10 FOR X=1TO105
>> 20 READ A
>> 30 POKE 1000+X,A
>> 40 NEXT A
>> 50 SYS 1001
>> 60 DATA 123,232,123,221,...
>
> Siehe Zeile 50.. oder stehst du auch mit Hex auf Kriegsfuss ;)

Nein, aber Commodore Basic :) Sonst h�tte man noch einen 
Hex-Dez-Umrechner im Basic-Loader einbauen m�ssen.

Aber mein Beispiel ist trotzdem nicht so sch�n, ab 1024 schrieb man 
direkt auf den Bildschirm. Man konnte zwar auch dort Programmcode 
hinschreiben, aber  der wurde dann relativ rasch �berschrieben...

Wie hast Du den Assembler programmiert? Hattest Du dazu tats�chlich 
einen Assemblierer?

cu
Mario

Am 17.04.12 08:48, schrieb Mario Rothacher:

er der wurde dann relativ rasch �berschrieben...
>
> Wie hast Du den Assembler programmiert? Hattest Du dazu tats�chlich
> einen Assemblierer?

Also ich hatte den "Data Becker ProfiMat".

Mein erstes grosses Projekt war, den Assembler selber selber zu 
dissasemblieren und zu patchen, um den Kopierschutz zu knacken. Dieser 
war n�mlich besonders fies: Wenn man ihn von einer Sicherungskopie 
startete, st�rzte er nach ca. einer halben Stunde mit der Meldung 
"Sorry, Hacker" ab und man hatte alles noch Ungesicherte verloren....
Gl�cklicherweise war der Kopierschutz naiv implementiert. Er testete auf 
einen bestimmten kaputten Sektor auf der Originaldiskette. Man konnte 
aber den "jsr <testroutine>" einfach mit "nop" �berschreiben, das war's 
dann :-)

Davon abgesehen war es ein gutes Werkzeug. Man konnte richtig grosse 
Projekte damit erstellen. Und auch der dazugeh�rige Disassembler und 
Debugger waren richtig gut.
Mit Basic konnte ich mich erst viel sp�ter anfreunden, auf dem Atari ST 
mit GFA-Basic.

-stef

Stefan Werner wrote:
> Davon abgesehen war es ein gutes Werkzeug. Man konnte richtig grosse
> Projekte damit erstellen. Und auch der dazugeh�rige Disassembler und
> Debugger waren richtig gut.
> Mit Basic konnte ich mich erst viel sp�ter anfreunden, auf dem Atari ST
> mit GFA-Basic.

Mit Basic hab ich �berhaupt angefangen mich mit Computern zu intressieren...
Auf dem VC20 hab ich in Basic im zur Verf�gung stehenden RAM von Sage 
und schreibe 3.5kByte Pac-Man programmiert. Leider hatte es einen Fehler 
und man konnte den Pac-Man aus dem Bildschirmspeicher laufen lassen :). 
Der lief dann durch den Speicher und ver�nderte nat�rlich den Basic-Code 
oder in entgegengesetzter Richtung Systembereiche. Hatte ganz sch�ne 
Effekte.

Heute ist ja schon das d�mmste Programm mindestens 1MByte gross... 
Damals musste man noch Bit z�hlen :)

Am 17.04.12 09:59, schrieb Mario Rothacher:
> Stefan Werner wrote:
>> Davon abgesehen war es ein gutes Werkzeug. Man konnte richtig grosse
>> Projekte damit erstellen. Und auch der dazugeh�rige Disassembler und
>> Debugger waren richtig gut.
>> Mit Basic konnte ich mich erst viel sp�ter anfreunden, auf dem Atari ST
>> mit GFA-Basic.
>
> Mit Basic hab ich �berhaupt angefangen mich mit Computern zu
> intressieren...
> Auf dem VC20 hab ich in Basic im zur Verf�gung stehenden RAM von Sage
> und schreibe 3.5kByte Pac-Man programmiert. Leider hatte es einen Fehler
> und man konnte den Pac-Man aus dem Bildschirmspeicher laufen lassen :).
> Der lief dann durch den Speicher und ver�nderte nat�rlich den Basic-Code
> oder in entgegengesetzter Richtung Systembereiche. Hatte ganz sch�ne
> Effekte.

Du h�ttest Dir das patentieren lassen sollen ;-). Das Konzept von 
Programmen, die durch den Speicher marodieren hat sp�ter ja Alex Dewdney 
mit seinen "core wars" aufgegriffen. Es gab da glaube ich sogar richtige 
Meisterschaften.

  Heute ist ja schon das d�mmste Programm mindestens 1MByte gross...
> Damals musste man noch Bit z�hlen :)

Ja, das hinterliess bei mir gewisse Sch�den. Ich hab auch dann noch viel 
zuviel Zeit mit Speicher- und Taktzyklen optimieren vergeudet, als das 
l�ngst nicht mehr n�tig war...

-stef

Stefan Werner wrote:
> Am 17.04.12 09:59, schrieb Mario Rothacher:
> Heute ist ja schon das d�mmste Programm mindestens 1MByte gross...
>> Damals musste man noch Bit z�hlen :)

> Ja, das hinterliess bei mir gewisse Sch�den. Ich hab auch dann noch viel
> zuviel Zeit mit Speicher- und Taktzyklen optimieren vergeudet, als das
> l�ngst nicht mehr n�tig war...

Taktzyklen z�hlen war dann erst wieder in der Elektronikerlehre ein 
Thema. Als wir mit einem Mikroprozessorkit (Genauer Typ weiss ich nicht 
mehr, aber Motorola, �hnlich einfach wie 6510) und einem Roboterbausatz 
ein Assemblerprogramm erstellt haben, welches den Turm zu Hanoi physisch 
l�ste. Da der Roboterbausatz ziemlich doof war (Widerstandsmessung zur 
Positionsbestimmung mit reichlich Spiel), hat man die ungef�hre Position 
mit Vollspeed �berfahren, dann getaktet (somit kontroliert langsamer) 
zur�ckgefahren bis die Zielposition erreicht wurde. So konnte man das 
Spiel einwenig aufheben und der Roboter hat Tagaus Tagein Stapel von 
einer S�ule zur anderen verschoben. Irgendwann war die so erreichte 
Genauigkeit jedoch trotzdem noch zu ungenau und der Turm st�rzte ein.

Seit diesem Programm weiss ich rekursives Programmieren zu sch�tzen :)

Am 17.04.12 08:48, schrieb Mario Rothacher:

> Aber mein Beispiel ist trotzdem nicht so sch�n, ab 1024 schrieb man
> direkt auf den Bildschirm. Man konnte zwar auch dort Programmcode
> hinschreiben, aber der wurde dann relativ rasch �berschrieben...

Ach, das wusste ich auch nicht mehr. Das gab's ja noch oft, dass 
Programme 'sich' erst auf den Schirm geschrieben haben und dann von dort 
ausgef�hrt.. Hatte ich v�llig vergessen.

> Wie hast Du den Assembler programmiert? Hattest Du dazu tats�chlich
> einen Assemblierer?

Aber sicher doch ;) ... Frag mich nicht mehr wie der hiess. Ehrlich 
gesagt hatte ich auf dem C64 auch praktisch nur Raubkopien. Meine Mama 
hat mir mal das Game Elite zu Weihnachten geschenkt. Ich war bass 
erstaunt ab der Geldverschwendung :) ... Aber ich habe das Game dann 
doch mehr gesch�tzt als jedes andere und irgendwie hat's doch Eindruck 
hinterlassen.
Aber ich bin so ehrlich: Ohne schier endlose Zufuhr an Raubkopien h�tte 
ich mich wohl gar nie f�r den Compi interessiert. Ich kann mich noch 
erinnern, dass ich auf nem Sharm MZ 80a oder so Basic programmiert habe 
(so ne langweilige B�romaschine mit Gr�nstufen-Display) und den C64 gar 
nie beachtet habe, weil das Basic so grottenschlecht war. Bis da jemand 
mal das Game 'Benji' geladen hat. Nicht die Graphik hat mich umgehauen 
(obwohl die auch ganz passabel war), sondern der Sound. Von da an wusste 
ich, was ich haben musste.

Irgendwann hatte ich �brigens ein SFD 1001. Brauchte ein modifiziertes 
ROM, welches ich in Form eines EPROM-Umschalters im Ger�t hatte. Wow das 
war heiss, 1 MB pro Diskette sichern, da ging der Platz nie mehr aus. 
Und relativ schnell war es auch noch, auch wenn gewisse Fastloader aus 
dem 1541 ja auch schon einiges raus holten ;)

Stefan Werner <009wcqf02@sneakemail.com> wrote:
> Am 12.04.12 05:03, schrieb Felix Rauch:
> > Stefan Werner<009wcqf02@sneakemail.com>  wrote:
> >> Der Mann, der den einzigen Computer herstellte, den ich wirklich
> >> vollst?ndig verstand: Den C64.
> >
> >> R.I.P
> >
> > Und auch den ATARI ST.

> Wobei TOS/AES/GEM doch immer etwas zusammengeschustert wirkte.

Naja, sobald ich Assembler beherrschate, hatte ich die Maschine jeweils
lieber selber uebernommen. Das war noch toll damals, die ganze Hardware
hatte man selber direkt zur Verfuegung :-)

- Felix

-- 
              Felix Rauch, http://www.trash.net/~xilef/
This article contains my personal view only! Use of my addresses for marketing
    purposes is hereby strictly prohibited according to applicable laws.

Stefan Werner <009wcqf02@sneakemail.com> wrote:
[...]
> Trotzdem: Man wird immer abh?ngiger von Spezialisten und man wird selber 
> immer mehr zum Spezialisten.

Heute reicht's nicht unbedingt mehr einen Spezialisten zu haben, der
muss auch noch die richtige Software haben um das Auto zu debuggen :-/

- Felix

-- 
              Felix Rauch, http://www.trash.net/~xilef/
This article contains my personal view only! Use of my addresses for marketing
    purposes is hereby strictly prohibited according to applicable laws.

Stefan Werner <009wcqf02@sneakemail.com> wrote:
[...]
> Mit Basic konnte ich mich erst viel sp?ter anfreunden, auf dem Atari ST 
> mit GFA-Basic.

Ach, Gfa-Basic, das war noch was. Zuerst angefangen hatte ich mit dem
Atari ST Basic, aber Gfa-Basic war natuerlich um einiges besser. Leider
immer noch nicht ausreichend fuer meine Zwecke, deshalb hatte ich dann
Assembler gelernt. 68000er-Assembler war ja eigentlich recht komfortabel.

- Felix

-- 
              Felix Rauch, http://www.trash.net/~xilef/
This article contains my personal view only! Use of my addresses for marketing
    purposes is hereby strictly prohibited according to applicable laws.

Am 20.04.12 13:23, schrieb Felix Rauch:

> Naja, sobald ich Assembler beherrschate, hatte ich die Maschine jeweils
> lieber selber uebernommen. Das war noch toll damals, die ganze Hardware
> hatte man selber direkt zur Verfuegung :-)

Ja aber der Atari... b�h.. :)
Aber ernsthaft, das k�nnte man ja heute genau so machen. Nur irgendwie 
lohnt es sich einfach nicht mehr. Heute weiss der Compiler wohl einfach 
besser um die Eigenheiten der Hardware als der Programmierer. Und 
sp�testens mehrere Cores gleichm�ssig zu befeuern d�rfte manuell echt 
kompliziert werden.

Patrick Kormann wrote:
> Am 20.04.12 13:23, schrieb Felix Rauch:
>
>> Naja, sobald ich Assembler beherrschate, hatte ich die Maschine jeweils
>> lieber selber uebernommen. Das war noch toll damals, die ganze Hardware
>> hatte man selber direkt zur Verfuegung :-)
>
> Ja aber der Atari... b�h.. :)
> Aber ernsthaft, das k�nnte man ja heute genau so machen. Nur irgendwie
> lohnt es sich einfach nicht mehr. Heute weiss der Compiler wohl einfach
> besser um die Eigenheiten der Hardware als der Programmierer. Und
> sp�testens mehrere Cores gleichm�ssig zu befeuern d�rfte manuell echt
> kompliziert werden.

Normalerweise l�uft ein Programm in n-threads. Jeder einzelner Thread 
wird wohl kaum auf mehrere Cores verteilt. Jedenfalls wenn ich ein 
Endlosloop-Programmiere sieht man im Taskmanager dass bei einem 
Dual-Core die Auslastung eines einzelnen Cores auf 100% ansteigt...

Das mit dem mehrere Cores gleichm�ssig zu befeuern passiert eben quasi 
automatisch, da selten nur ein Prozess auf einer Kiste l�uft. Insofern 
sollte das nicht so wirklich kompliziert sein.

Aber so tief mit Hardware habe ich mich seit �ber 20 Jahren eigentlich 
nicht mehr befasst. Damals als die Prozessoren noch im 1-2 stelligen 
MHz-Bereich getaktet wurden, spielte die Ausf�hrungszeit nat�rlich noch 
eine viel wichtigere Rolle als heute... Da darf man ruhig in 
Hochsprachen entwickeln die dann wieder interpretiert werden (Analog 
Commodore Basic) wie zum Beispiel Java. Ein Compiler der in 
Maschinencode �bersetzt ist meiner Meinung trotzdem vorzuziehen, zum 
Beispiel C,C++ oder das untersch�tzte Delphi.

cu
Mario

Am 20.04.12 15:32, schrieb Mario Rothacher:

> Normalerweise l�uft ein Programm in n-threads. Jeder einzelner Thread
> wird wohl kaum auf mehrere Cores verteilt. Jedenfalls wenn ich ein
> Endlosloop-Programmiere sieht man im Taskmanager dass bei einem
> Dual-Core die Auslastung eines einzelnen Cores auf 100% ansteigt...

Ja richtig. Aber mach nur schon mal mehrere Threads und handle die... 
Ohne OS, mein ich.

> Das mit dem mehrere Cores gleichm�ssig zu befeuern passiert eben quasi
> automatisch, da selten nur ein Prozess auf einer Kiste l�uft. Insofern
> sollte das nicht so wirklich kompliziert sein.

Wir hatten es gerade von 'totaler Kontrolle' am OS vorbei. Da stell ich 
mir das auch noch irgendwie kompliziert vor.
Ausserdem meinte ich auch andere Dinge. Mal schauen ob ich die richtigen 
Begriffe zusammenkriege. Der Compiler sortiert ja z.B. je nach dem 
Befehle, die voneinander unabh�ngig sind so um, dass m�glichst wenige 
Wartezyklen entstehen (der Pentium 4 hatte ja irgendwie ne unendlich 
lange prefetch Queue) , sorgt daf�r, dass Funktionseinheiten, die 
parallel betrieben werden k�nnen (das ist nicht dasselbe wie 
Multithreading) auch dementsprechend Daten kriegen etc. etc.
Ich stell mir das schon noch sau kompliziert vor.

> Aber so tief mit Hardware habe ich mich seit �ber 20 Jahren eigentlich
> nicht mehr befasst. Damals als die Prozessoren noch im 1-2 stelligen
> MHz-Bereich getaktet wurden, spielte die Ausf�hrungszeit nat�rlich noch
> eine viel wichtigere Rolle als heute... Da darf man ruhig in
> Hochsprachen entwickeln die dann wieder interpretiert werden (Analog
> Commodore Basic) wie zum Beispiel Java. Ein Compiler der in
> Maschinencode �bersetzt ist meiner Meinung trotzdem vorzuziehen, zum
> Beispiel C,C++ oder das untersch�tzte Delphi.

Ich weiss nicht, Java fand ich immer schon grottig. Ich les mich (mal 
wieder) in Objective C ein, das ist schon noch elegant. Delphi, ja, da 
war mal was... Ehrlich gesagt k.a. mehr ob ich damit wirklich was 
gemacht habe oder nicht. Ich weiss nur noch, dass es eigentlich immer 
als untersch�tzt galt ;)

Am 20.04.12 15:32, schrieb Mario Rothacher:
> Patrick Kormann wrote:
>> Am 20.04.12 13:23, schrieb Felix Rauch:
>>
>>> Naja, sobald ich Assembler beherrschate, hatte ich die Maschine jeweils
>>> lieber selber uebernommen. Das war noch toll damals, die ganze Hardware
>>> hatte man selber direkt zur Verfuegung :-)
>>
>> Ja aber der Atari... b�h.. :)
>> Aber ernsthaft, das k�nnte man ja heute genau so machen. Nur irgendwie
>> lohnt es sich einfach nicht mehr. Heute weiss der Compiler wohl einfach
>> besser um die Eigenheiten der Hardware als der Programmierer. Und
>> sp�testens mehrere Cores gleichm�ssig zu befeuern d�rfte manuell echt
>> kompliziert werden.
>
> Normalerweise l�uft ein Programm in n-threads. Jeder einzelner Thread
> wird wohl kaum auf mehrere Cores verteilt. Jedenfalls wenn ich ein

Aeh, Threads sind aber ein OS-Konzept. Also wenn Du die Maschine ganz 
�bernimmst, also das OS aussen vor l�sst (d.h. eigentlich: Dein eigenes 
Programm als OS bootest), dann hast Du kein Thread-Management. Ich weiss 
nichtmal mehr, was dann auf einem aktuellen Intel- oder AMD-Prozessor 
passiert. Vermutlich l�uft das Programm dann nur auf einem Core und die 
anderen h�ngen faul in der Gegend rum.

Oder liege ich da jetzt v�llig falsch?
(Wie gesagt, der C64 war der einzige Computer, den ich vollst�ndig 
verstand. Heute kenne ich mich nur noch mit Java und Scala aus und den 
Rest �berlasse ich dem Compiler und dem OS. Was den netten Nebeneffekt 
hat, dass es letztlich auch egal ist, ob auf dem Computer nun Linux, 
Windows oder MacOS l�uft :-))

-stef

Stefan Werner wrote:

> Am 20.04.12 15:32, schrieb Mario Rothacher:
>> Patrick Kormann wrote:
>>> Am 20.04.12 13:23, schrieb Felix Rauch:
>>>
>>>> Naja, sobald ich Assembler beherrschate, hatte ich die Maschine jeweils
>>>> lieber selber uebernommen. Das war noch toll damals, die ganze Hardware
>>>> hatte man selber direkt zur Verfuegung :-)
>>>
>>> Ja aber der Atari... b�h.. :)
>>> Aber ernsthaft, das k�nnte man ja heute genau so machen. Nur irgendwie
>>> lohnt es sich einfach nicht mehr. Heute weiss der Compiler wohl einfach
>>> besser um die Eigenheiten der Hardware als der Programmierer. Und
>>> sp�testens mehrere Cores gleichm�ssig zu befeuern d�rfte manuell echt
>>> kompliziert werden.
>>
>> Normalerweise l�uft ein Programm in n-threads. Jeder einzelner Thread
>> wird wohl kaum auf mehrere Cores verteilt. Jedenfalls wenn ich ein
> 
> Aeh, Threads sind aber ein OS-Konzept. Also wenn Du die Maschine ganz
> �bernimmst, also das OS aussen vor l�sst (d.h. eigentlich: Dein eigenes
> Programm als OS bootest), dann hast Du kein Thread-Management. Ich weiss
> nichtmal mehr, was dann auf einem aktuellen Intel- oder AMD-Prozessor
> passiert. Vermutlich l�uft das Programm dann nur auf einem Core und die
> anderen h�ngen faul in der Gegend rum.
> 
Vermutlich, h�ngt davon ab wie das BIOS die CPU konfiguriert hat (SMP
aktiviert?, SMT [Hyperthreading] aktiviert?, etc). Moderne CPUs sind
immerhin so intelligent nicht benutze Funktionseinheiten schlafen zu legen
(weiss jetzt nicht, ob das auch erst vom Bios aktiviert werden muss).

> Oder liege ich da jetzt v�llig falsch?
> (Wie gesagt, der C64 war der einzige Computer, den ich vollst�ndig
> verstand. 
> 
Ich bin zu jung um je einen vollst�ndig verstanden zu haben :-)

Gruss,
Peter

Patrick Kormann wrote:

> Am 20.04.12 15:32, schrieb Mario Rothacher:
> 
>> Das mit dem mehrere Cores gleichm�ssig zu befeuern passiert eben quasi
>> automatisch, da selten nur ein Prozess auf einer Kiste l�uft. Insofern
>> sollte das nicht so wirklich kompliziert sein.
> 
> Ausserdem meinte ich auch andere Dinge. Mal schauen ob ich die richtigen
> Begriffe zusammenkriege. Der Compiler sortiert ja z.B. je nach dem
> Befehle, die voneinander unabh�ngig sind so um, dass m�glichst wenige
> Wartezyklen entstehen (der Pentium 4 hatte ja irgendwie ne unendlich
> lange prefetch Queue) , sorgt daf�r, dass Funktionseinheiten, die
> 
Der P4 war auch ne Elektroheizung mit Abrechenleistung, die Verantwortlichen
die DAS verbrochen haben m�ssten echt mal �ffentlich bestraft werden :-|

> parallel betrieben werden k�nnen (das ist nicht dasselbe wie
> 
Superskalare CPUs

> Multithreading) auch dementsprechend Daten kriegen etc. etc.
> Ich stell mir das schon noch sau kompliziert vor.
> 
Der Compiler ist das eine, vieles wird aber immer noch von der CPU
optimiert, merkt man gut am Atom. Der hat keine Out of Order Execution (Das
heisst die CPU kann Befehle nicht umsortieren um die Auslastung der
Pipeline zu verbessern), dementsprechend bringt Hyperthreading (welches
einen zweiten CPU-Kern simuliert, welcher die freien Funktionseinheiten
nutzt) viel mehr (relativ gesehen) als auf anderen Intel-Chips.
Allgemein kann man sagen, das heutige CPUs extrem gut sind darin das was an
Code ankommt optimal umzusortieren und bei Spr�ngen richtig zu sch�tzen.
Ansonsten w�rde wesentlich weniger von der theoretischen Rechenleistung
beim Anwender ankommen.
Ich habe mal ein interessantes Paper zu dem ganzen gelesen, finde es aber
nicht mehr. Als Nicht-Proprammierer liest sich das immer sehr interessant,
aber hat wenig Einfluss auf meine Arbeit als Sysadmin.

Was heute zusehends wichtiger wird sind die ganzen SSE-Instruktionen als
Erg�nzung zu x86, da muss man glaub ich aber auch Quellcode teilweise etwas
pr�parieren, damit der Compiler das nutzt. Abgesehen von wenigen Ausnahmen
(Irgendwie muss Intel ja demonstrieren, wozu man das braucht) werden die
Funktionen im Massenmarkt gesch�tzt 10 Jahre nach Markteinf�hrung genutzt,
damit garantiert jeder potentielle Kunde auch kompatible Hardware hat.
Eine interessante Ausnahme ist die AES-Verschl�sselung, welche Intel in den
Core i eingef�hrt hat, und welche vom Markt sehr schnell aufgenommen wurde.

>> Aber so tief mit Hardware habe ich mich seit �ber 20 Jahren eigentlich
>> nicht mehr befasst. Damals als die Prozessoren noch im 1-2 stelligen
>> MHz-Bereich getaktet wurden, spielte die Ausf�hrungszeit nat�rlich noch
>> eine viel wichtigere Rolle als heute... Da darf man ruhig in
>> Hochsprachen entwickeln die dann wieder interpretiert werden (Analog
>> Commodore Basic) wie zum Beispiel Java. Ein Compiler der in
>> Maschinencode �bersetzt ist meiner Meinung trotzdem vorzuziehen, zum
>> Beispiel C,C++ oder das untersch�tzte Delphi.
> 
> Ich weiss nicht, Java fand ich immer schon grottig.
> 
Ich wundere mich immer, wieso die ganzen Hersteller von Hardware Java nicht
noch mehr pushen. Das Zeugs scheint immer wahnsinnig viel CPU und Ram zu
fressen, zumindest verglichen mit C-Programmen.

Gruss,
Peter

Am 20.04.12 18:35, schrieb Stefan Werner:

> Aeh, Threads sind aber ein OS-Konzept. Also wenn Du die Maschine ganz
> �bernimmst, also das OS aussen vor l�sst (d.h. eigentlich: Dein eigenes
> Programm als OS bootest), dann hast Du kein Thread-Management. Ich weiss
> nichtmal mehr, was dann auf einem aktuellen Intel- oder AMD-Prozessor
> passiert. Vermutlich l�uft das Programm dann nur auf einem Core und die
> anderen h�ngen faul in der Gegend rum.

Irgendwie muss man die Cores ja per Befehl bef�llen k�nnen, sonst k�nnte 
das OS das auch nicht. Aber ich habe keine Ahnung, wie das geht.
INTEL Assembler fand ich sowieso immer... scheusslich.

Am 20.04.12 20:16, schrieb Peter Rohrer:

> Ich wundere mich immer, wieso die ganzen Hersteller von Hardware Java nicht
> noch mehr pushen. Das Zeugs scheint immer wahnsinnig viel CPU und Ram zu
> fressen, zumindest verglichen mit C-Programmen.

Ich spreche aber nicht unbedingt nur von der Performance, sondern davon, 
dass Java meist benutzt wird um OS-Unabh�ngige Programme zu schreiben. 
Die sehen dann auf *jedem* OS aus wie ein 20 j�hriger Fremdk�rper. In 
wiefern man mit Java z.B. an die ganze Cocoa API �berhaupt ran k�me 
weiss ich wiederum nicht.
Aber IMHO spielt es eh keine Rolle, ob man da nun Java oder Objective C 
nimmt. Die Sprache ist ja nicht das Problem. Das API zu verstehen, das 
ist die grosse Kunst. OS X kann in etwa alles schon, nur ist der 
API-Aufruf teilweise so komplex wie ein mittelkompliziertes Programm ;) 
Und vor allem muss man erst mal WISSEN dass es den Aufruf schon gibt und 
dann muss man ihn noch finden...

Am 21.04.12 00:29, schrieb Patrick Kormann:
> Am 20.04.12 20:16, schrieb Peter Rohrer:
>
>> Ich wundere mich immer, wieso die ganzen Hersteller von Hardware Java
>> nicht
>> noch mehr pushen. Das Zeugs scheint immer wahnsinnig viel CPU und Ram zu
>> fressen, zumindest verglichen mit C-Programmen.
>
> Ich spreche aber nicht unbedingt nur von der Performance, sondern davon,
> dass Java meist benutzt wird um OS-Unabh�ngige Programme zu schreiben.
> Die sehen dann auf *jedem* OS aus wie ein 20 j�hriger Fremdk�rper. In
> wiefern man mit Java z.B. an die ganze Cocoa API �berhaupt ran k�me
> weiss ich wiederum nicht.


Also da muss ich jetzt doch mal eine Lanze brechen: Das h�ngt doch sehr 
davon ab, welches Grafik-Toolkit man verwendet. Was Du schreibst, stimmt 
f�r AWT. Wenn ein Programm aber z.B. mit SWT programmiert ist, dann 
sieht dasselbe Programm unter Windows aus wie ein Windows-Programm und 
unter MacOS wie ein Mac-Programm. Inlusive Mac-spezifische UI-Details 
wie die abgerundeten Suchfelder oder die angedockten modalen Dialoge 
etc. Man muss dazu nicht ans Cocoa-API (Soll man ja nicht, sonst w�re es 
nicht mehr systemunabh�ngig)

Und @Peter zum Ressourcenhunger: Kann man so eigentlich nicht mehr 
sagen. Aktuelle Java-Compiler und JVM's sind ziemlich effizient 
geworden. Nat�rlich nie ganz so, wie f�r den verwendeten Prozessor 
optimierter Maschinencode eines C-Compilers, klar.
Spielt aber eigentlich f�r die meisten Zwecke eh keine Rolle, da bei den 
meisten Standardaufgaben die CPU 90% ihrer Zeit mit Warten verbringt und 
Speichermangel nicht mehr wirklich ein Problem ist.

Was hingegen einschenkt ist die eingesparte Entwicklungszeit. Ein 
nichttriviales Programm in C/C++ zu entwickeln, zu debuggen und auf 
mehrere Plattformen zu portieren braucht locker das 5-fache an 
Entwicklerstunden, wie in Java. Und da freie Entwickler zwischen 100.- 
und 150.- pro Stunde kosten, kann die Differenz zwischen 50 und 250 
Stunden schon ziemlich matchentscheidend sein.

Nat�rlich kommt es auch immer aufs Umfeld an, in dem man sich bewegt. 
Bei IT-Dienstleistern liegt Java klar vorne (S. z.B. hier: 
http://www.heise.de/developer/meldung/Umfrage-Java-ist-verbreitetste-Programmiersprache-bei-IT-Dienstleistern-1198249.html), 
w�hrend im high performance computing Bereich C/C++ vermutlich seinen 
Platz noch lange halten wird.

-stef

Am 20.04.12 13:24, schrieb Felix Rauch:
> Stefan Werner<009wcqf02@sneakemail.com>  wrote:
> [...]
>> Trotzdem: Man wird immer abh?ngiger von Spezialisten und man wird selber
>> immer mehr zum Spezialisten.
>
> Heute reicht's nicht unbedingt mehr einen Spezialisten zu haben, der
> muss auch noch die richtige Software haben um das Auto zu debuggen :-/


Meine Werkstatt hat da einen ganz pragmatischen Ansatz: Wenn eine 
Warnmeldung kommt, das Auto aber problemlos l�uft, dann st�pseln sie 
ihren Computer ein, setzen die Warnmeldung zur�ck und sagen, es sei 
jetzt repariert :-)
Gl�cklicherweise verlangen sie daf�r auch nichts....

Entspricht wohl dem obligaten Neustart bei Windows, wenn irgendwas nicht 
geht. Ist in 90% der F�lle die beste Reparaturmethode :-)

-stef

Am 21.04.12 07:43, schrieb Stefan Werner:

> Also da muss ich jetzt doch mal eine Lanze brechen: Das h�ngt doch sehr
> davon ab, welches Grafik-Toolkit man verwendet. Was Du schreibst, stimmt
> f�r AWT. Wenn ein Programm aber z.B. mit SWT programmiert ist, dann
> sieht dasselbe Programm unter Windows aus wie ein Windows-Programm und
> unter MacOS wie ein Mac-Programm. Inlusive Mac-spezifische UI-Details
> wie die abgerundeten Suchfelder oder die angedockten modalen Dialoge
> etc. Man muss dazu nicht ans Cocoa-API (Soll man ja nicht, sonst w�re es
> nicht mehr systemunabh�ngig)

Hast du mir ein Beispiel f�r ne App, die darin geschrieben ist?

Am 21.04.12 07:46, schrieb Stefan Werner:

> Meine Werkstatt hat da einen ganz pragmatischen Ansatz: Wenn eine
> Warnmeldung kommt, das Auto aber problemlos l�uft, dann st�pseln sie
> ihren Computer ein, setzen die Warnmeldung zur�ck und sagen, es sei
> jetzt repariert :-)
> Gl�cklicherweise verlangen sie daf�r auch nichts....

Bei uns geht der Fehler meist irgendwann von selbst wieder weg.
�rgerlicher all die getauschten Gl�hbirnen, die gar nicht durchgebrannt 
waren, sondern nur vom Bordcomputer gemeldet werden. Man kann das beim 
Anmelden des Autos noch so oft sagen, die wechseln es trotzdem. Wenn 
daf�r dann noch die Hundebox ausgebaut wird, um so schlimmer.
Das ganze kam von einem schlechten Kontakt bei der Fassung her, inkl. 
weggeschmortem Kontakt. Irgendwann hab ich das dann mal irgendwie 
'geflickt'.

> Entspricht wohl dem obligaten Neustart bei Windows, wenn irgendwas nicht
> geht. Ist in 90% der F�lle die beste Reparaturmethode :-)

Aber unbefriedigend, irgendwie. Vor allem wenn man dann im Internet so 
tips liest wie 'wenn pl�tzlich ein Fehler des ESP gemeldet wird, liegt 
das meist am Bremsschalter'.

Patrick Kormann schrieb:

> Und relativ schnell war es auch noch, auch wenn gewisse Fastloader aus
> dem 1541 ja auch schon einiges raus holten ;)

Turbo Copy. Der kopierte so schnell, dass man gleich schnell war wie auf 
dem PC eine 3.5" zu kopieren. Das ratterte richtig die Sektoren ab :-)

Gruss, Markus, den Keller noch gef�llt haben mit Hard- und Software.

Stefan Werner schrieb:

> Also da muss ich jetzt doch mal eine Lanze brechen: Das h�ngt doch sehr
> davon ab, welches Grafik-Toolkit man verwendet. Was Du schreibst, stimmt
> f�r AWT. Wenn ein Programm aber z.B. mit SWT programmiert ist, dann

Ich stimme f�r Qt ;-)

Gruss, Markus, Java nicht so sehr liebend, da er mit Objekten seine 
liebe M�he hat ;-)

Am 22.04.12 00:53, schrieb Markus Grob:

> Turbo Copy. Der kopierte so schnell, dass man gleich schnell war wie auf
> dem PC eine 3.5" zu kopieren. Das ratterte richtig die Sektoren ab :-)

Naja, waren auch einige Daten weniger ;)
Aber ich meinte mehr so Hardwarel�sungen die das Laden etc. 
verschnellerten. Das hatte ich nie.
Es gab ja sowas L�sungen die Disketten komplett in ein RAM luden. So 
viel brauchte das ja eigentich auch nicht, was passte nochmal drauf? 144 KB?

Patrick Kormann schrieb:
> Am 22.04.12 00:53, schrieb Markus Grob:
>
>> Turbo Copy. Der kopierte so schnell, dass man gleich schnell war wie auf
>> dem PC eine 3.5" zu kopieren. Das ratterte richtig die Sektoren ab :-)
>
> Naja, waren auch einige Daten weniger ;)

Nene, hochgerechnet.


> Es gab ja sowas L�sungen die Disketten komplett in ein RAM luden. So
> viel brauchte das ja eigentich auch nicht, was passte nochmal drauf? 144
> KB?

Das waren 360kB f�r beide Seiten. Eine Seite hatte also um die 180kB. 
Evtl. auch nur 170.

Gruss, Markus

Am 21.04.12 16:40, schrieb Patrick Kormann:
> Am 21.04.12 07:43, schrieb Stefan Werner:
>
>> Also da muss ich jetzt doch mal eine Lanze brechen: Das h�ngt doch sehr
>> davon ab, welches Grafik-Toolkit man verwendet. Was Du schreibst, stimmt
>> f�r AWT. Wenn ein Programm aber z.B. mit SWT programmiert ist, dann
>> sieht dasselbe Programm unter Windows aus wie ein Windows-Programm und
>> unter MacOS wie ein Mac-Programm. Inlusive Mac-spezifische UI-Details
>> wie die abgerundeten Suchfelder oder die angedockten modalen Dialoge
>> etc. Man muss dazu nicht ans Cocoa-API (Soll man ja nicht, sonst w�re es
>> nicht mehr systemunabh�ngig)
>
> Hast du mir ein Beispiel f�r ne App, die darin geschrieben ist?
>

Eclipse (www.eclipse.org)

Am 22.04.12 00:59, schrieb Markus Grob:
> Stefan Werner schrieb:
>
>> Also da muss ich jetzt doch mal eine Lanze brechen: Das h�ngt doch sehr
>> davon ab, welches Grafik-Toolkit man verwendet. Was Du schreibst, stimmt
>> f�r AWT. Wenn ein Programm aber z.B. mit SWT programmiert ist, dann
>
> Ich stimme f�r Qt ;-)
>
> Gruss, Markus, Java nicht so sehr liebend, da er mit Objekten seine
> liebe M�he hat ;-)

Und ich dachte, Qt sei ein C++ - Framework (also objektorientiert).

Darf man inzwischen denn selbstgeschriebene Qt-Anwendungen unter eigenen 
Lizenzen vertreiben oder muss man immer noch die Trolltech-Lizenz 
�bernehmen?

-stef

Am 22.04.12 02:36, schrieb Markus Grob:

> Nene, hochgerechnet.

Ach so. Naja, Disketten waren IMHO immer ne PITA, egal auf welchem System.

> Das waren 360kB f�r beide Seiten. Eine Seite hatte also um die 180kB.
> Evtl. auch nur 170.

Laut Wiki 165. Naja, laut englischem 170. Whatever ;)

Am 22.04.12 07:35, schrieb Stefan Werner:

> Eclipse (www.eclipse.org)

Hab da die Tage kurz reingeschaut aber wusste schon nicht welche Version 
ich runterladen soll. Aber ich meinte mehr ne 'Enduser' APP und nicht 
die Entwicklungsumgebung ;)

Patrick Kormann <sirdir@hotmail.com> wrote:
> Am 22.04.12 02:36, schrieb Markus Grob:
[...]
> > Das waren 360kB f?r beide Seiten. Eine Seite hatte also um die 180kB.
> > Evtl. auch nur 170.

> Laut Wiki 165. Naja, laut englischem 170. Whatever ;)

Englische kB sind eben etwas kleiner, wie yards vs Meter und so ;-)

- Felix

-- 
              Felix Rauch, http://www.trash.net/~xilef/
This article contains my personal view only! Use of my addresses for marketing
    purposes is hereby strictly prohibited according to applicable laws.

Stefan Werner <009wcqf02@sneakemail.com> wrote:
> Am 20.04.12 13:24, schrieb Felix Rauch:
> > Stefan Werner<009wcqf02@sneakemail.com>  wrote:
> > [...]
> >> Trotzdem: Man wird immer abh?ngiger von Spezialisten und man wird selber
> >> immer mehr zum Spezialisten.
> >
> > Heute reicht's nicht unbedingt mehr einen Spezialisten zu haben, der
> > muss auch noch die richtige Software haben um das Auto zu debuggen :-/

> Meine Werkstatt hat da einen ganz pragmatischen Ansatz: Wenn eine 
> Warnmeldung kommt, das Auto aber problemlos l?uft, dann st?pseln sie 
> ihren Computer ein, setzen die Warnmeldung zur?ck und sagen, es sei 
> jetzt repariert :-)

Meine eine Reparaturwerkstatt hat auch schon gesagt, dass sie das
Problem nicht weiter debuggen koennen, weil Holden die dazu noetige
Software noch nicht zur Verfuegung stellt. Anscheinend machen sie
das erst nach einigen Jahren. Allerdings war das auch eine lokale
Werkstatt, die nicht auf Holden spezialisiert war.

- Felix

-- 
              Felix Rauch, http://www.trash.net/~xilef/
This article contains my personal view only! Use of my addresses for marketing
    purposes is hereby strictly prohibited according to applicable laws.

Patrick Kormann <sirdir@hotmail.com> wrote:
> Am 20.04.12 13:23, schrieb Felix Rauch:

> > Naja, sobald ich Assembler beherrschate, hatte ich die Maschine jeweils
> > lieber selber uebernommen. Das war noch toll damals, die ganze Hardware
> > hatte man selber direkt zur Verfuegung :-)

> Ja aber der Atari... b?h.. :)
> Aber ernsthaft, das k?nnte man ja heute genau so machen. Nur irgendwie 
> lohnt es sich einfach nicht mehr. Heute weiss der Compiler wohl einfach 
> besser um die Eigenheiten der Hardware als der Programmierer.

Nicht nur das, auch die Hardware ist schwieriger anzusprechen, denke
ich mal. Damals konnte man noch einfach das, was man gerne angzeigt
haben moechte in den Bildschirmspeicher schreiben und das war's
dann schon.

> Und 
> sp?testens mehrere Cores gleichm?ssig zu befeuern d?rfte manuell echt 
> kompliziert werden.

Ich denke man gibt jedem core einen Pointer auf den Code, den er
ausfuehren soll und dann machen die Cores das eben. Natuerlich muss
man mit beiden Cores etwas geistreiches und gegebenenfalls aufeinander
abgestimmtes machen. Hyperthreading sinnvoll auszunuetzen duerfte
dann schon etwas komplizierter werden.

- Felix

-- 
              Felix Rauch, http://www.trash.net/~xilef/
This article contains my personal view only! Use of my addresses for marketing
    purposes is hereby strictly prohibited according to applicable laws.

Stefan Werner <009wcqf02@sneakemail.com> wrote:
> Am 20.04.12 15:32, schrieb Mario Rothacher:
> > Patrick Kormann wrote:
> >> Am 20.04.12 13:23, schrieb Felix Rauch:
> >>
> >>> Naja, sobald ich Assembler beherrschate, hatte ich die Maschine jeweils
> >>> lieber selber uebernommen. Das war noch toll damals, die ganze Hardware
> >>> hatte man selber direkt zur Verfuegung :-)
> >>
> >> Ja aber der Atari... b?h.. :)
> >> Aber ernsthaft, das k?nnte man ja heute genau so machen. Nur irgendwie
> >> lohnt es sich einfach nicht mehr. Heute weiss der Compiler wohl einfach
> >> besser um die Eigenheiten der Hardware als der Programmierer. Und
> >> sp?testens mehrere Cores gleichm?ssig zu befeuern d?rfte manuell echt
> >> kompliziert werden.
> >
> > Normalerweise l?uft ein Programm in n-threads. Jeder einzelner Thread
> > wird wohl kaum auf mehrere Cores verteilt. Jedenfalls wenn ich ein
> Aeh, Threads sind aber ein OS-Konzept. Also wenn Du die Maschine ganz 
> ?bernimmst, also das OS aussen vor l?sst (d.h. eigentlich: Dein eigenes 
> Programm als OS bootest), dann hast Du kein Thread-Management. Ich weiss 
> nichtmal mehr, was dann auf einem aktuellen Intel- oder AMD-Prozessor 
> passiert. Vermutlich l?uft das Programm dann nur auf einem Core und die 
> anderen h?ngen faul in der Gegend rum.

Grundsaetzlich hat doch jeder Core einen unabhaengigen PC (program
counter). Wenn der auf etwas sinnvolles zeigt, dann fuehrt der core
das dort stehende Programm aus. Was beim booten passiert, bin ich
allerdings nicht ganz sicher. Ob nur ein core per default anfaengt
etwas auszufuehren, oder alle gleichzeitig bei Adresse 0 starten
und dann aufgrund ihrer core-Nummer irgendwann stoppen, weiss ich
nicht mehr (ich hatte mir den entsprechenden boot-code im Linux kernel
mal angeschaut, ist aber schon lange her).

- Felix

-- 
              Felix Rauch, http://www.trash.net/~xilef/
This article contains my personal view only! Use of my addresses for marketing
    purposes is hereby strictly prohibited according to applicable laws.

Am 22.04.12 13:18, schrieb Patrick Kormann:
> Am 22.04.12 07:35, schrieb Stefan Werner:
>
>> Eclipse (www.eclipse.org)
>
> Hab da die Tage kurz reingeschaut aber wusste schon nicht welche Version
> ich runterladen soll. Aber ich meinte mehr ne 'Enduser' APP und nicht
> die Entwicklungsumgebung ;)
>
>

Eclipse ist nicht nur eine Entwicklungsumgebung, sondern auch eine 
Plattform. RCP - Rich Client Platform.

Hier sind einige Beispiele f�r darauf basierende Apps:

http://www.eclipse.org/community/rcpos.php  (Frei/OpenSource)
http://www.eclipse.org/community/rcpcp.php  (Kommerziell)

Prominent ist z.B. Lotus Symphony (Ich wette Du h�ttest das nicht als 
Java-Anwendung bezeichnet)

Relativ bekannt ist auch Azureus.

Aus der Schweiz das bsi-crm
http://www.bsiag.com/de/produkte/bsi-crm.html

Ich weiss ja nicht was f�r eine Art von Enduser-Apps Du gerne h�ttest. 
Actionspiele in Java wird es eher nicht geben, aber sonst vermutlich aus 
fast jedem Bereich was. Von nat�rlich sehr unterschiedlicher Qualit�t, klar.

-stef

Am 23.04.12 07:09, schrieb Stefan Werner:

> Ich weiss ja nicht was f�r eine Art von Enduser-Apps Du gerne h�ttest.
> Actionspiele in Java wird es eher nicht geben, aber sonst vermutlich aus
> fast jedem Bereich was. Von nat�rlich sehr unterschiedlicher Qualit�t,
> klar.

Um Dir die n�chste Entt�uschung zu ersparen: Auf MacOS Lion ist die Java 
Runtime nicht mehr standardm�ssig dabei. Die Apps werden also vermutlich 
nicht laufen.

Man kann es aber leicht nachinstallieren:
http://support.apple.com/kb/DL1515?viewlocale=en_US&locale=en_US
Dann m�sste es gehen.

-stef

Am 23.04.12 05:14, schrieb Felix Rauch:
> Patrick Kormann<sirdir@hotmail.com>  wrote:
>> Am 22.04.12 02:36, schrieb Markus Grob:
> [...]
>>> Das waren 360kB f?r beide Seiten. Eine Seite hatte also um die 180kB.
>>> Evtl. auch nur 170.
>
>> Laut Wiki 165. Naja, laut englischem 170. Whatever ;)
>
> Englische kB sind eben etwas kleiner, wie yards vs Meter und so ;-)

Ja, es heisst aber auch nicht kilobyte, sondern poundbyte und 
quarterbyte, wobei 12 qb ein pb sind oder umgekehrt und 928 qb sind dann 
ein mb (megabyte) und eine billion mb sind ein tb. Und das wiegt 
getrocknet exakt 238 Unzen.

Dies nur zur Klarstellung.

-stef

Am 23.04.12 07:09, schrieb Stefan Werner:


> Prominent ist z.B. Lotus Symphony (Ich wette Du h�ttest das nicht als
> Java-Anwendung bezeichnet)

Ja, kenne ich zwar nicht, aber das k�nnte ich mir vorstellen, dass ich 
das nicht als Java App bezeichnen w�rde.

> Relativ bekannt ist auch Azureus.

Das kenne ich. Dem glaub ich die Java App allerdings wieder sofort.


> Ich weiss ja nicht was f�r eine Art von Enduser-Apps Du gerne h�ttest.
> Actionspiele in Java wird es eher nicht geben, aber sonst vermutlich aus
> fast jedem Bereich was. Von nat�rlich sehr unterschiedlicher Qualit�t,
> klar.

Ne, halt einfach ne normale Desktop App, die nicht von weitem nach Java 
stinkt.

Zu deinem anderen Posting: Nat�rlich hab ich die Java Runtime 
installiert (installieren m�ssen...). Ich w�rde ja nicht gegen Java 
meckern, wenn ich nicht allzu oft darunter leiden w�rde ;)

Am 23.04.12 05:24, schrieb Felix Rauch:

> Nicht nur das, auch die Hardware ist schwieriger anzusprechen, denke
> ich mal. Damals konnte man noch einfach das, was man gerne angzeigt
> haben moechte in den Bildschirmspeicher schreiben und das war's
> dann schon.

Naja, ohne OS kannst du das immer noch - nur nicht so einfach, wenn's 
dann 3D beschleunigt sein soll und so... :) .. Und vor allem muss man 
halt die Hardware kennen.

> Ich denke man gibt jedem core einen Pointer auf den Code, den er
> ausfuehren soll und dann machen die Cores das eben. Natuerlich muss
> man mit beiden Cores etwas geistreiches und gegebenenfalls aufeinander
> abgestimmtes machen. Hyperthreading sinnvoll auszunuetzen duerfte
> dann schon etwas komplizierter werden.

Das auch, aber auch 4 Cores jederzeit mit unabh�ngigem Code so zu 
befeuern, dass man auch was davon hat.. Das m�chte ich nicht managen...

Stefan Werner schrieb:
> Am 22.04.12 00:59, schrieb Markus Grob:

>> Ich stimme f�r Qt ;-)
>>
>> Gruss, Markus, Java nicht so sehr liebend, da er mit Objekten seine
>> liebe M�he hat ;-)
>
> Und ich dachte, Qt sei ein C++ - Framework (also objektorientiert).

Dies stimmt, doch eben c und nicht java ;-)


> Darf man inzwischen denn selbstgeschriebene Qt-Anwendungen unter eigenen
> Lizenzen vertreiben oder muss man immer noch die Trolltech-Lizenz
> �bernehmen?

Ich meine, es ist dual lizenziert. 
http://de.wikipedia.org/wiki/Qt_%28Bibliothek%29
GPL oder kommerziell.

Gruss, Markus

Am 23.04.12 16:32, schrieb Markus Grob:
> Stefan Werner schrieb:

>
> Ich meine, es ist dual lizenziert.
> http://de.wikipedia.org/wiki/Qt_%28Bibliothek%29
> GPL oder kommerziell.

Ok, Seit 4.5 scheint es LGPL zu sein, dann ist es jetzt einfacher. 
Vorher brauchte man praktisch einen Anwalt, um rauszufinden, ob man Qt 
f�r ein bestimmtes Projekt nun verwenden darf oder nicht, deswegen habe 
ich es seinerzeit nach einem Blick auf die Lizenzbedingungen nie mehr 
n�her angeschaut.

-stef

Patrick Kormann <sirdir@hotmail.com> wrote:
> Am 23.04.12 05:24, schrieb Felix Rauch:

> > Nicht nur das, auch die Hardware ist schwieriger anzusprechen, denke
> > ich mal. Damals konnte man noch einfach das, was man gerne angzeigt
> > haben moechte in den Bildschirmspeicher schreiben und das war's
> > dann schon.

> Naja, ohne OS kannst du das immer noch - nur nicht so einfach, wenn's 
> dann 3D beschleunigt sein soll und so... :) .. Und vor allem muss man 
> halt die Hardware kennen.

Haben denn moderne Grafikkarten ueberhaupt noch einen Bildschirmspeicher,
den man vom Hauptprozessor aus direkt schreiben und lesen kann? Muss
das nicht irgendwie in speziellen Kommandos ueber den (PCI?)-Bus
geschickt werden? Ich dachte, dass die heutigen Karten nicht mehr
direkt einen Speicherbereich aus dem Hauptspeicher auf dem Bildschirm
abbilden, aber ich bin da kein Experte...

> > Ich denke man gibt jedem core einen Pointer auf den Code, den er
> > ausfuehren soll und dann machen die Cores das eben. Natuerlich muss
> > man mit beiden Cores etwas geistreiches und gegebenenfalls aufeinander
> > abgestimmtes machen. Hyperthreading sinnvoll auszunuetzen duerfte
> > dann schon etwas komplizierter werden.

> Das auch, aber auch 4 Cores jederzeit mit unabh?ngigem Code so zu 
> befeuern, dass man auch was davon hat.. Das m?chte ich nicht managen...

Hm ja, das braucht ein Bisschen was... aber mit mutexes und so kommen sich
die Prozessoren dann schonmal nicht mehr in die Quere in kritischen
Bereichen und wie man die Arbeit sonst aufteilt, kommt halt auf die
Anwendung drauf an.

- Felix

-- 
              Felix Rauch, http://www.trash.net/~xilef/
This article contains my personal view only! Use of my addresses for marketing
    purposes is hereby strictly prohibited according to applicable laws.

Am 25.04.12 06:05, schrieb Felix Rauch:

> Haben denn moderne Grafikkarten ueberhaupt noch einen Bildschirmspeicher,
> den man vom Hauptprozessor aus direkt schreiben und lesen kann? Muss
> das nicht irgendwie in speziellen Kommandos ueber den (PCI?)-Bus
> geschickt werden? Ich dachte, dass die heutigen Karten nicht mehr
> direkt einen Speicherbereich aus dem Hauptspeicher auf dem Bildschirm
> abbilden, aber ich bin da kein Experte...

Hm, war es nicht so, dass in der Intel-Welt das Zeugs noch nie 'memory 
mapped' war? Auch schon zu XT Zeiten nicht? Mir war da was. Da gibt's 
doch irgendwelche speziellen I/O Kommandos.
Jedenfalls m�sste man heute noch genau so im Textmodus was auf die Karte 
kriegen wie damals. DOS weiss schliesslich nichts von PCI...

> Hm ja, das braucht ein Bisschen was... aber mit mutexes und so kommen sich
> die Prozessoren dann schonmal nicht mehr in die Quere in kritischen
> Bereichen und wie man die Arbeit sonst aufteilt, kommt halt auf die
> Anwendung drauf an.

Ja, multi-Core macht ja auch nicht f�r jede Anwendung Sinn.

Am 25.04.12 13:19, schrieb Patrick Kormann:
> Am 25.04.12 06:05, schrieb Felix Rauch:
>
>> Haben denn moderne Grafikkarten ueberhaupt noch einen Bildschirmspeicher,
>> den man vom Hauptprozessor aus direkt schreiben und lesen kann? Muss
>> das nicht irgendwie in speziellen Kommandos ueber den (PCI?)-Bus
>> geschickt werden? Ich dachte, dass die heutigen Karten nicht mehr
>> direkt einen Speicherbereich aus dem Hauptspeicher auf dem Bildschirm
>> abbilden, aber ich bin da kein Experte...
>
> Hm, war es nicht so, dass in der Intel-Welt das Zeugs noch nie 'memory
> mapped' war? Auch schon zu XT Zeiten nicht? Mir war da was. Da gibt's
> doch irgendwelche speziellen I/O Kommandos.
> Jedenfalls m�sste man heute noch genau so im Textmodus was auf die Karte
> kriegen wie damals. DOS weiss schliesslich nichts von PCI...

Also ich hab vor einigen Monaten mal spasseshalber meine treue DOS 3.3 
Disk ins Laufwerk eines aktuellen Windows-PC geschoben und neu 
gestartet. DOS bootete nicht. Ich weiss allerdings nicht woran es lag 
und hatte auch nicht wirklich Lust lang rumzuprobieren. Aber k�nnte es 
nicht sein, dass DOS einen aktuellen PC tats�chlich gar nicht mehr 
booten kann?

-stef