Beiträge von RexRetro

    Neben Knuth hier ein echtes Rex-Zitat: „Buggy compiler optimization is the biggest evil.“

    Zuetzt hatte ein Kollege mit Rekursion + Inlining bei clang/llvm extreme Probleme. Auf x64 lief es wie erwartet, auf GPU (NV Pascal über bc->ptx Backend) hat es Quatsch gemacht. Unser Compilerbauer vom Dienst meint einen Bug in den llvm low-level Optimizern des ptx Backend gefunden zu haben. Um den zu reporten müsste er aber einen minimalen Reproducer ohne realen Code von uns erstellen. Aber wie so oft: mit toy code funktioniert alles.

    Um selbst zu fixen fehlen Knowhow und Zeit. So bleibt nur Workaround mit forcenoinline etc. :-(

    Semikolon kann man in C genauso leicht vergessen, wie in Pascal. Aufgrund der nahezu kontextfreien Syntex ist Pascal aber meist in der Lage, genau an der Fehlerstelle den eigentlichen Fehler zu melden, statt wie C (und schlimmer noch C++) erst Quatsch zu interpretieren und dann viele Zeilen später eine irreführende Fehlermeldung zu bringen.

    Hmm? (Qt Creator mit clang-Codemodel, clang selbst würde beim Compilieren die gleiche Fehlermeldung ausspucken)

    Vielleicht ist clang etwas schlauer, vielleicht ist es Glück, weil gleich dahinter ein Schüsselwort kommt...

    Meine Erfahrung mit msvc und gcc ist aber eher, dass der Compiler sehr leicht verwirrte Fehlermeldungen liefern kann. Kommt natürlich auch darauf an, wie sehr der Code verwirrende Features nutzt. Aber gerade mit template metaprogramming habe ich leidergottes erleben dürfen, dass kleinste Syntaxfehler zu ellenlangen, völlig unleserlichen Fehlermeldungen führen.

    Im schlimmsten Fall ist das die Art von Code, die auch Intellisense Amok laufen lässt (ich glaube bei VS2012 gab es auch mal eine Phase, wo Intellisense dann Unmengen RAM fraß und bei 2GB abschmierte).

    Und klar: die Verfechter von "modern C++" werden nun einwenden, dass dies mit "Concepts" in C++20 Schnee von gestern sein wird, und wenn nicht dann in C++2x und man solle ja auch nicht ewig an einem veralteten msvc kleben, und MS hätte ja noch nie gute C++ Compiler geliefert, etc.pp.

    Doch die Welt dreht sich bekanntlich nicht nur um die neusten und tollsten C++ Standards und Compiler und es gibt noch einiges an Abhängigkeiten, die Upgrades ausbremsen. Und mal ehrlich: viel scientific code ist immer noch FORTRAN 77/90 und Banken haben noch COBOL auf Mainframes laufen. Das Zeug tut was es soll und wird noch lange bleiben. Und genauso wird es noch lange "orthodox C/C++" Code geben. Und ob der wirklich schlimmer oder doch besser ist als "modern C++" darüber können Theoretiker IMHO ewig streiten. Tatsache ist: das Zeug existiert und verschwindet nicht. Und die Probleme bleiben auch und werden nur von neuen Problemen ergänzt oder überlagert.

    Hi Snocksman,


    das erinnert mich daran, dass ich auch vor einer Weile meinen ACube Minimig wiederbeleben wollte, und es dann nach dem Urlaub ganz vergessen habe.

    Hatte in diesem Thread von AW182 den Tipp bekommen, dass es bei somuch.guru noch Cores für den original Minimig gibt.


    AFAIR gab es auch mal einen experimentellen AGA Core für den Minimig von einem Jakub. Glaube aber der wurde nie ge-open-sourced und das was man heute als MinimigAGA findet, sind halt die AGA-Amiga Cores für MiST/SiDi/TC64 und Mister. Es ist leider etwas verwirrend, dass die Amiga Cores für neuere Retro-FPGAs Systeme auch "Minimig" genannt werden ( wobei es historisch natürlich ok ist, weil sie eben daraus entstanden sind).

    Für mich war es als Kind schon Magie, dass da ein Bild auf dem Fernseher zu srhen war, das aber eben kein Fernsehen war, sondern ein Fenster in eine imaginäre Welt. Und diese Welt kann man beeinflussen, man kann mit ihr interagieren und im Idealfall selbst erschaffen. Das hat mich eigentlich immer noch mehr gereizt, als nur damit zu „spielen“. Für mich war Computer-Grafik von Anfang an eine starke Triebfeder.

    Und so sehr geflasht,wie die ersten Begegnungen mit Atari VCS, C64 und dann Amiga, haben mich dann nur noch die ersten bezahlbaren VR-Brillen vor 4-5 Jahren.

    Internet und WWW fand ich z.B. 1994 ganz nett und potenziell nützlich, aber richtig umgehauen hat es mich nicht. Die schnell WeiterEntwicklung lief ja über Jahre und erst ab 2000 war es unverzichtbares Massenmedium mit iel Inhalt und Nutzen. Aber die erste smtp mail war halt auch nicht spannender, als die erste Datex-J Mail (bei mir erst ca.1992/93).

    Strukturie. Proggen hätte man auch mit Basic erlernen können und wenn schon nicht Basic, warum nicht gleich in die Vollen gehen und auf C gehen.


    Unvergesslich: Das Semikolon am Ende der Zeile vergessen:tischkante:

    Semikolon kann man in C genauso leicht vergessen, wie in Pascal. Aufgrund der nahezu kontextfreien Syntex ist Pascal aber meist in der Lage, genau an der Fehlerstelle den eigentlichen Fehler zu melden, statt wie C (und schlimmer noch C++) erst Quatsch zu interpretieren und dann viele Zeilen später eine irreführende Fehlermeldung zu bringen.

    Preprocessor Macros sind auch ein Antifeature. Goto ebenso.


    Und die meisten BASICs waren damals viel zu primitiv, um strukturiert zu programmieren.

    In Grunde sind C und Pascal austauschbar - beide von Algol 60 abgeleitet und mit vergleichbaren Features. Pascal hat halt die sauberere Syntax (ist ja eine Lehrsprache von einem Compilerbauer) und C einige hardware-nahe Features ( es sollte ja ein OS damit geschrieben werden ).


    Wer mal logische Programmierung in Prolog oder was rein funktionales machen durfte, wird schon bestätigen, dass die Unterschiede zwischen C und Pascal nicht so groß sind, und es auch deutlich abstrakter geht.

    Bei uns in RLP gab es in der 10.Klasse ITG := 'Informations-technische Grundbildung'. War zwar nur - AFAIR - nur ein Halbjahr ungefähr eine Wochenstunde, aber schonmal recht brauchbar, für Leute die sonst so gar nichts mit Computern am Hut hatten.

    Stoff war:

    • Umgang mit MS-DOS (Verzeichnisse anlegen, löschen, kopieren, etc)
    • Textverarbeitung, Tabellenkalkulation und kleine Datenbanken mit Framemaker IV
    • Programmieren: Grundlagen (EVA, Algorithmus) und etwas Praxis mit Turbo-Pascal 4
    • Datensicherheit und Datenschutz (Schwerpunkt damals noch mehr auf letzerem)
    • EDV in der Praxis (Besuch im Rechenzentrum der Stadtsparkasse)

    Gemacht hat das vorwiegend der Mathelehrer (den ich später im Stamm-Kurs Physik hatte). Der hat selbst viel programmiert und allen Interessierten auch im Matheunterricht kleine Programmieraufgaben gegeben.

    Ich glaube es kam gut an, denn sehr viele haben dann in der 11.Klasse auch Informatik gewählt. Es gab zwar nur einen Grundkurs - und den konnte man auch fakultativ belegen - aber es war eine bunte Truppe - auch mit Leuten, die zuhause keinen Homecomputer hatten oder vorher nie was programmiert haben. Also nicht nur Freaks.


    Da ging es dann mit Pascal mehr in die Tiefe und auch etwas Assembler am Schluss. Und natürlich die üblichen algorithmischen Grundlagen und Datenstrukturen.

    Die Number Nine 512x32 kam 85 auf den Markt und konnte True Color.

    Interessant. Nie davon gehört. Aber mit Grafikkarten unter DOS war ja eh immer das Henne-Ei-Problem:

    - war sie nicht weit verbreitet, gab es auch keine Software, die sie unterstützt hätte

    - gab es keine breite Softwareunterstützung, hat sie niemand gekauft

    - hat niemand sie gekauft, war sie nicht weit verbreitet


    Und hatte man eine Software, die n Grafikkarten unterstützte, und es kam eine tolle neue - inkompatible - raus, dann konnte man die nicht nutzen, weil die Software ja die Treiber mitbringen musste.

    Die Grafikkarte hat natürlich auch Patches für eine handvoll verbreiteter Software mitgebracht, aber halt nicht für die, die man brauchte.


    DOS war einfach für Grafik lange Zeit völlig unbrauchbar, weil es keinerlei Grafik-Treiber-Konzept gab. Das hat sich erst mit Windows 3.x geändert, als dann langsam SuperVGA und 2D Beschleuniger auch auf dem PC bezahlbar und verbreitet waren.


    PS: und jetzt erzähle mir bitte keiner, das VGA/VESA-BIOS wäre ja ein "Treiber" gewesen. Das taugte nur, um Modes zu switchen - mehr nicht. Nicht umsonst gab es damals sehr dicke Bücher, wie man alle möglichen PC-Grafikkarten programmieren muss, damit man ein paar 2D Grafikprimitive auf den Bildschirm bekommt (und das noch akzeptable schnell, trotz der idiotischen x86 RealMode Architektur).

    Ich dachte auch schon RealSoft ist tot. Aber dann haben sie vor 2-3 Jahren nochmal ein Update nachgeschoben. Irgendwo kann man auch eine lustige Story der beiden Programmierer (wie bei Cinema 4D zwei Brüder), wie sie anfangs versucht haben, den Blitter als eine Art 2.5D Raytracing Accelerator zu nutzen. Ziemlich seltsame Idee, die wohl auch nur bei M68000@7MHz irgendwas gebracht hat.

    Ja, an DKBTrace von einer Fish Disk habe ich mich auch ca. 1989 versucht und schnell festgestellt, dass Renderer mit Texteditor - statt grafischem 3D Modeler - für mich nicht infrage kommen.

    Ich meine mich zu erinnern, dass es für POV-Ray auch grafische Modeler gab, in denen man Szenen bauen konnte, die dann in Textdateien gespeichert wurden. Ich weiß aber nicht mehr, ob die für Amiga, DOS oder Windows 3.x waren.

    Ja, habe '97 oder '98 - als ich auf den PC umgestiegen bin - auch nochmal etwas mit POV oder MegaPOV rumgespielt und dem Modeler "Moray".

    Aber ich glaube POV kam erst in den 90ern und für DKBTrace gab es 1989 sicher kein grafisches Frontend.

    Das mag sein. Evtl war dein Kauf kurz vor, oder während, dem A500+ mit Kick2.0 ??

    Das würde RexRetro´s Aussage stützen.

    Mir dämmert da gerade was, was ich in "Commodore - The final years" gelesen habe: C= Deutschland war gar nicht happy mit den US Vorgaben zu A500+, Kickstart 2.0 und dann A600 und hat versucht, den A500 KS 1.3 noch zu verkaufen, als C= US den A500+ (und dann den A600) durchdrücken wollte.


    Da man sehr viele Kompatibilitätsprobleme (gerade bei älternen Spielen) mit KS2.0 hatte, hat man wohl sogar A500+ absichtlich "gedowngraded", um weiterhin die beliebte Spielekiste A500 mit KS1.3 verkaufen zu können. Das BASIC war da sicher nicht der Fokus und evtl. wollte man wirklich Lizenzgebühren an MS vermeiden (im Gegensatz zum 8-Bit MS-BASIC hatte man dafür ja nie eine one-time fee bezahlt). Und Druckkosten für das Basic-Handbuch hat man auch gespart.


    Das könnte eine Erklärung sein, warum 500er mit WB/KS 1.3, aber ohne Amiga Basic in Umlauf kamen. Habe davon aber damals gar nichts mitbekommen. Kein empörter Aufschrei im Amiga Magazin, etc...

    ich habe jetzt nicht genau recherchiert, aber schau doch mal in die alten "Ray Tracing News", hier eine Ausgabe von '88 mit einer Liste kommerzieller Raytracer:

    http://graphics.stanford.edu/p…s/html/rtnews3b.html#art5

    Sehr guter Hinweis. Die "Ray Tracing News" von Eric Haines hatte ich ganz vergessen. In dieser Liste von '88 sind aber auch viele "Profi" Lösungen für Rechner, die damals niemand zuhause hatte:

    Ardent Titan, AT&T Pixel Machine, Workstations von HP, Apollo und Wavefront Software lief wohl auf SGIs.


    Für IBM DOS-PC sehe ich da:

    • Integra Inc. "Turbo Beam Tracing"
    • Ray Tracing Corp "TRACER PC" (wo die "TRACER" Version ohne "PC" auch für Cray, VAX und Unix Workstation angeboten wird).
    • United Computer Systems Inc., "Ray Tracer" (auch für Mac)

    Während Lightwave, Cinema 4D und sogar Realsoft 3D (sic!) bis heute verkauft werden, sind diese Programme aber weitgehend unbekannt geblieben. Nur von "Integra Inc." habe ich mal was mitgekommen. Deren Software wird AFAIK in der japanischen Autoindustrie für Lichtsimulation verwendet und wurde zumindest in den 2000er Jahren in Moskau vom Keldysh Institut weiterentwickelt.