Impressum Datenschutz
News   Magazin   Börse   Links   ArcArchie   Homepages
 News  Home 

Erste Version eines SMP Kernel

 <   >

Jeffrey Lee hat eine sehr frühe Version eines SMP Kernels für den Raspberry Pi 2 und 3 veröffentlicht. Ein symmetrisches Multiprozessorsystem (SMP) ist die Unterstützung vom mehreren Prozessoren beziehungsweise Prozessorkernen. Es gibt von Jeffrey kein Beispielprogramm, aber Anthony Vaughan Bartram hat da ein kleines C Programm zwei Posts weiter veröffentlicht. Weiter oben auf der Seite oder überhaupt der gesamte Thread :-) gibt es mehr zu SMP für RISC OS. Damit ist die Unterstützung der zwei oder mehr Kerne moderner ARM Prozessoren zwar noch sehr weit entfernt, aber ich denke das ist für RISC OS ein wichtiger Schritt. Wie es aussieht und auch zu erwarten war wird SMP unter RISC OS wohl nur mit Programmen funktionieren, die dafür geschrieben wurden. Ob Programme, die nur mit einen Prozessor alias Kern umgehen können, auf die Kerne verteilt werden können wird die Zukunft zeigen.
cms, 17. 01. 2017, 11:17 Uhr <   >
Ja seeehr geil! Schon wieder etwas von meiner Liste abgearbeitet wo ich sowieso nie zu gekommen wäre :-\. Super geeignet für sämtliche arten von Transcoding die nicht schon in Hardware gehen oder Apfelmännchen/Fraktale :-)
Uwe, 17. 01. 2017, 16:38 Link
Mein Gedächtnis sagt, das Apfelmännchen auf den StrongARM und dem Programm vom Michael nicht so sehr lange gedauert haben. Das sollte mit einen Raspberry Pi 2 oder 3 recht schnell gehen, wenn das Programm noch dreht. Bei der Transkodierung würde ich sagen das NEON auch etwas für Schwung sorgen sollte.

Hast Du eine Ahnung wie die SMP Unterstützung aufgebaut ist?
cms, 17. 01. 2017, 17:03 Link
Noch nicht. Hatte es aber so verstanden dass man dem Prozessorkern jeweils etwas Speicher mitgibt und ihn dann mit Programm versieht.
Uwe, 17. 01. 2017, 22:38 Link
Es bräuchte meiner Ansicht nach mehr Leute, die etwas für RISC OS programmieren würden für. Und hierfür auch mehr verständliche Dokumentation. In Web-Foren z. B. wurde bereits vor etlichen Jahren immer wieder von Neulingen gefragt, wie man den RP unter RISC OS programmiert. Die Antworten waren unter anderem, dass RISC OS für Neulinge sehr schwierig ist und man besser mit Linux beginnt. Aber die eigentliche Frage wurde nie beantwortet. Da sträuben sich doch einem die Haare.

Wie ich jetzt selbst gesehen habe, ist das Programmieren von Oberflächen und Multitasking unter RISC OS gar nicht so schwierig, wenn man erst einmal die erste Hürde genommen hat. Hier bei mir sind inzwischen acht verschiedene Programme entstanden, die irgendwas (halbwegs) Sinnvolles machen. Ein Programm z. B. zählt die Ansprünge durch die WIMP pro Sekunde und gibt die in einem Fenster aus. Ist zwar nur zur Demonstration, aber allein mit diesem kleinen Programm kann man recht schnell sehen, dass der RP2 z. B. fast 4x schneller ist als ein StrongARM-Risc PC. (Polls pro Sekunde RP2: bis zu 30.000, Risc PC: bis zu 7.000). Und einen kleinen Seitenscroller, bei dem der Text unter Ausnutzung eines Textsymbols von rechts nach links durchläuft, habe ich inzwischen auch geschrieben (ist natürlich recht marode und ineffektiv, aber funktioniert). Und dann war da noch das kleine Webradio. Alles in C und OSlib. So etwas z. B. hätte ich mir bei uns auf der Fachhochschule gewünscht. Statt dessen hatten wir nur die Konsolen-Ausgabe und auch nur Funktionen der Standard-C-Library genutzt. Mehr als ein Herunterbeten der Befehle und Datentypen sowie -strukturen war das dann leider auch nicht. Der einzige weitere Schwerpunkt waren dann noch Algorithmen, die man sich hatte überlegen dürfen - und das auch noch in der Prüfung! Mit sowas lockt man nicht nur nicht einmal einen Hund hinter dem Ofen hervor. Nein, auf Grund der Schwierigkeiten der Prüfungen auf Grund der (teils schweren) Algorithmen stößt man den Studierenden mit sowas auch noch vor den Kopf. Und die eigentlichen interessanten Dinge hat man gar nicht 'mal gehört.

So. Genug geschimpft. Die entsprechenden Programme habe ich zusammen mit einer neuen Folge der Artikel-Serie OS-Lib & C in der Zwischenzeit auch an CMS weitergereicht. Sollte also irgend wan einmal auf ArcSite.de zu finden sein.

Was mich inzwischen auch stark interessiert, das sind z. B. die Module unter RISC OS. Denn was wir noch immer dringend bräuchten, das wäre ein heute brauchbares SSL-/TLS-Modul unter RISC OS. Den C-Quellcode des (inzwischen ur)alten Moduls von rComp habe ich ja da. Er schien mir aber auch für die damalige Zeit eher eine Notlösung gewesen zu sein. Denn er kommt mir absolut chaotisch vor. Ich persönlich steige da nicht durch.

Die Frage, die sich mir noch immer stellt, ist, wie man aus einer C-Library wie GnuTLS ein Systemmodul für RISC OS macht. So wie ich das verstehe, stellen die Systemmodule unter RISC OS die ganzen SWIs und Befehle zur Verfügung. Was wir jetzt brauchen, das sind SWIs, die genauso wie eine C-Library bestimmte Funktionen zur Verfügung stellen. Es geht darum, Schnittstellen anzubieten, auf die ein jedes Programm zugreifen kann, damit nicht ein jedes Programm wieder alles selbst mitbringen muss. Zum Beispiel ist es so, dass NetSurf seine eigenen Routinen für SSL / TLS mitbringt. Und auch meine beiden Programme !POP3S und !SMTPS arbeiten so. Besser wäre aber, diese Programme würden über eine exakt festgelegte Schnittstelle alle auf ein gemeinsam SSL / TLS-Modul zurückgreifen. Das würde einmal Speicher sparen, und ein andermal das System zukunftsfähiger zu machen. Denn dann müsste man nur noch das Modul austauschen, um quasi wieder up-to-date mit neuen Verschlüsselungsverfahren zu sein. Die Programme, welche sowas dann nutzen, müssten gar nicht mehr angefasst werden.

Auf anderen Systemen verwendet man hier Laufzeitbibliotheken, wenn ich das richtig verstanden habe.

Eine Frage habe ich noch: Für RISC OS wurden in der Zwischenzeit ja immer wieder einige Webbrowser wie !FireFox oder !Otter portiert. Bei mir arbeiten die selbst auf dem RPI2 sehr langsam; d. h. es dauert lange, bis da eine Webseite kommt. Seit gestern aber habe ich einen ASUS EEE PC hier stehen. Der arbeitet über die gleiche Internet-Verbindung sehr schnell; die Seiten werden also sehr flott angezeigt. Ist jetzt der ASUS PC wirklich soviel schneller als der RPI2, oder sind die Programme einfach dementsprechend schlecht an unser System angepasst worden? Ich meine, worin liegt der Geschwindigkeits-Unterschied begründet? Die selben Webseiten bauen sich auf dem ASUS EEE PC mit Sicherheit gleich ein Mehrfaches schneller auf, wahrscheinlich Faktor 5 bis 10.

Und gleich noch eine weitere Frage: Ich hätte zu Demonstrationszwecken für Vorlesungen etc. jetzt unter RISC OS in OSlib & C gerne ein Multitasking-Programm programmiert, das irgendwelche Hardware steuert, die man an einen RPI anschließen kann. Nun bin ich hardwaremäßig nicht besonders begabt und habe da auch keine rechte Vorstellung, was man da alles anstellen könnte. Es sollte jedoch etwas Einfaches sein. Mit einem Mausklick irgendwelche Lichter / Lampen steuern vielleicht? Irgendwelche Analog-/Digitalwandler auslesen / beschreiben? Und vor allem: Was könnte man da anschließen? Ich habe momentan keine Ahnung.
Isip, 18. 01. 2017, 03:14 Link
Sollte heißen RP = Raspberry PI (eigentlich RPI). Und zur Hardware-Frage: Gibt es irgendwelche Zusatzplatinen, die man einfach kaufen und direkt an den RPI ansteuern kann, um damit z. B. Lämpchen oder sowas zu steuern? Interessant wäre für die E-Leute zum Beispiel auch das Messen von Spannungen über Analog-Digital-Wandler. Dann könnte man unter RISC OS u. B. 'mal ein Fenster mit einer Spannungsausgabe programmieren und das dann auch gleich wieder im Labor bei den Praktiken nutzen. Ich würde das dann auch für ArcSite zur Verfügung stellen. Es geht in erster Linie darum, dass die Leute nachvollziehen können, wie man sowas unter RISC OS macht.
Isip, 18. 01. 2017, 03:24 Link
Schnell mal kurz vor der Arbeit ;-)

Browser: Ich denke es liegt an der Einbindung der portierten Browser in RISC OS. Es sind und bleiben "Fremdkörper".
Ich habe mir den Otterbrowser für das Linux der Pandora als PND (knapp 56MB) runtergeladen und auf der Classic probiert. Die läuft bei mir mit 600MHz und hat nur 256MB Hauptspeicher, ist also die "schwächste" der drei Varianten.
Der Otter startet in ca. 15s und ist recht flott unterwegs. Kein Vergleich zu der doch recht trägen RISC OS Variante, die auf der Classic unter RISC OS (800MHz) eher nicht zu empfehlen ist. Auf der GHz Pandore (1000MHz, 512MB) geht es so einigermaßen aber doch noch sehr viel gemächlicher als die Linuxvariante auf der Classic.

RPi + Lämpchen: Über das GPIO-Module und die librogpio sollte da was möglich sein. Ich wollte damit immer mal "spielen" aber nie die Zeit "gefunden".
Raik, 18. 01. 2017, 05:23 Link
Zum Fenstern fällt mir nur Qt und vielleicht noch Gnome ein die es plattformübergreifend gibt. Keine Ahnung was man gewöhnlich unter Windows oder macOS nutzt. Welche soll da der Prof dann auswählen? Klar es wird eine für Windows sein, weil das ja ... Und ohne die Standardlibs wird man auch nicht weit kommen und dann schon mal eine Basis.
cms, 18. 01. 2017, 10:34 Link
Ich habe damals für den RPC ein Modul geschrieben das Schrittmotoren ansteuert um meine Fräse zu steuern. Damit wurden dann also mit hoher Frequenz die Drehfelder für die 3 Schrittmotoren erzeugt, sodaß man mit dem Fräskopf eine gerade Linie im Raum abfahren konnte.
Das ganze war damals in Assembler und für 26Bit Systeme funktioniert mit meinem PiscPC aber heute noch. Die Verwaltung welcher Fräspfad wann abgekaspert werden soll erfolgte dann aus einem BASIC-Programm.
Ausserdem kann ich einen normalen Staubsauger (~1000W/230V) zur Späneabsaugung mit einem elektronischen Lastrelais ansteuern. Das kann man auch direkt am Raspberry betreiben - als Last entspricht dies einer Leuchtdiode. Beispiele zum Anschluss von Leuchtdioden sind im PI-Mag zu finden (lässt sich umsonst von der RaspberryPi - Seite herunterladen). des weiteren kann man mit handelsüblichen N-FET sehr schön Modellbaumotoren ansteuern die dann auch reichlich Leistung ziehen dürfen.

Tank hat ein Modul geschrieben, welches die GPIO Leitungen des Erweiterungssteckers unter Riscos ansteuert, es sollte im Quellcode findbar sein, Tank hat die Quellcodes anfangs auf jeden Fall verteilt. Erweiterungen die dann eine Pulsweitenmodulation oder Servo-Ansteuerung erlauben sollten damit möglich sein.

An weitergehender Hardware gibt es zum Beispiel das 'GertBoard' welches ein Arduino (mit AVR Prozessor) an den Raspberry anbindet. Dieser kann dann reichlich AD- Wandlerkanäle und IO Leitungen anbieten - wird meines Wissens auf dem Erweiterungsstecker aber seriell angesprochen und erfordert dann eine Programmierung des AVR Chips (wieder in C oder Assembler).

Das Ganze ist ein seehr weites Feld, wenn jemand da Spaß dran hat sind bei verwendung von Tanks Module eigentlich kaum Stolpersteine vorhanden.

Gruß,

Uwe
Uwe, 18. 01. 2017, 11:35 Link
(click) for infos - Basic examples included
downloadseite für GPIO.RM http://www.tankstage.co.uk/Software/
naitsabes, 18. 01. 2017, 12:43 Link
CMS: Meine Fractal Progrämmchen gibt's noch unter dem Link. Momentan unterstützt Jeffrey's SMP Code leider noch kein NEON oder FPU, würde das aber gerne umschreiben wenn ich es hinkriege und sobald Jeffrey das unterstützt. Bis dahin könnte ich aber auch die Fixed-Point-Variante umkodieren. Seine DOC's sind im ersten Wurf ganz gut zu lesen, aber leider habe ich keine Ahnung von WIMP/Task-Programmierung.

Wie wäre es wenn du dir die DOC's mal ziehst und reinschaust und dein eigenes Mini-Bespiel aus deiner alten Task-Programmier-Anleitung umbastelst auf die neuen SWI's ? => http://www.arcsite.de/magazin/praxis/multitasking/

Wäre super wenn quasi SMP-Einsteiger so ein kleines Basic Progi hätten zum sich einlernen :-)
Kuemmel aka Michael, 18. 01. 2017, 21:08 Link
Isip! Ich denke die Webbrowser auf den bekannten Sytemen sind für diese hoch optimiert worden. Also die Webbrowser werden zwar Multiplattform entwickelt, aber jeweils von einem eigenen Platform-Team zusätzlich optimiert. Auch die Smartphone-Webbrowser sind sicherlich nicht einfach nur die Desktop-Versionen. Da wird viel getrickst, um die fehlende Performance zu verschleiern. Z.B. wird beim Scrolling die Render-Auflösung drastisch reduziert. Es wird nicht immer Multithreading genutzt (Cache-Misses vermeiden). usw.

Und seien wir ehrlich: wenn schon die die Arbeitszeit für GUI-API-Anpassungen auf RISC OS nicht da ist, fehlt die Zeit für die Render-Optimierung. Weil Qt für RISC OS finde ich ehrlich gesagt ein Armutszeugnis. Welchen Grund soll es geben, noch RISC OS zu benutzen, wenn selbst die WIMP-API benutzt wird?

Zu den APIs als System-Module: finde ich gar nicht so interessant. Warum? Weil die Internet-Technik so schnelllebig ist, das sie als System-Module gar nicht so schnell nachgepflegt werden könnten. Gestern hat noch jeder SSL benutzt, heute ist es TLS. Morgen ist es etwas anderes.

Wenn jetzt Netsurf keine eigenen Libs mitbringen würde, müssten die jetzt so lange warten, bis in RISC OS passende APIs da sind. Und wenn in einer Systen-API eine Sicherheitlücke drin ist... Das würde den Fortschritt nur noch langsamer machen.

Wenn deine POP und SMTP Apps ihre eigenen Libs mitbringen, kannst du z.B. bessere oder effizientere Implementierungen ausliefern. Features auf die du wahrscheinlich lange unter RISC OS API warten müsstest.

Low-Level-APIs (z.B. TCP/IP) machen aber als System-Module aber auf jeden Fall Sinn.
Artchi, 19. 01. 2017, 13:27 Link
Noch was zur Webbrowser-Performance... ich habe gelesen, das RISC OS immer noch eine sehr beschränkte Anzahl an File-Handles und TCP/IP-Verbindungen offen halten kann? Stimmt das wirklich?
Das ist ja auch nichts, was die Performance verbessern kann. Denn wenn z.B. sehr viele Resourcen (Bilder usw.) in einer Internet-Seite sind, ist das serialisierte herunter laden nicht gerade optimal. Meistens ist nämlich eine einzelne Verbindung ineffizienter als mehrere Verbindungen (mehrere Bilder gleichzeitig runter laden).

SMP hilft einem nur weiter, wenn die I/O-Beschränkungen auch aufgehoben werden.
Artchi, 19. 01. 2017, 16:47 Link
Ich denke es liegt eher am Rechner bzw. an der Optimierung an sich.
Meine Kisten hängen alle am gleichen lahmen Netz aber Nutzbarkeit verbessert/verschlechtert sich entsprechend der "Rechnerpower". RPi/OMAP3 eher zähflüssig; OMAP4/MX6 schon etwas besser; OMAP5 sehr flott, wobei die schnellen Festplatten "beschleunigend" wirken.
Raik, 19. 01. 2017, 21:03 Link
Natürlich ist schnellere HW auch ein Beschleuniger, ist doch logisch. Und das die I/O beschränkt scheint, zeigt ja deine schnellere Platte, die nur die I/O-Beschränkungen wieder lindert.
Man wird aber nicht darum herum kommen auch mal an der SW zu arbeiten, also auch am RISC OS.
Ich habe schon sehr lange keine Webbrowser mehr ausprobiert. Aber ich kann mir vorstellen, das mit SW-Tricks noch was raus zu holen ist.

Ich habe unter Linux einen Text-Webbrowser (war nicht Lynx, ein anderer der bei Debian dabei ist) in der reinen Text-Konsole ausprobiert (also nicht im Fenster!). Man sollte meinen, das der ratten schnell sein sollte. Aber weit gefehlt: der ist sooo langsam, das glaubt man gar nicht. Ich weiß nicht was der Programmierer da gemacht hat.

Jedenfalls ist Minimalismus kein Kriterium für Performance.
Artchi, 20. 01. 2017, 10:01 Link
Mir ist schon vor Jahren folgendes aufgefallen. Wenn man in C in einer Schleife einzelne Zeichen aus einer Datei liest ist die Datei z. B. unter Linux schnell eingelesen. Wenn man das Programm unter RISC OS kompiliert dauert die Abarbeitung recht lange. Sieht fast so aus als wenn RISC OS tatsächlich bei jeden Schleifendurchgang die Datei bzw. den Sektor neu einliest. Das wäre saudämlich. Linux hat da Zwischenspeicher. Man kann unter RISC OS via SWI die Datei Blockweise in den Speicher schaufeln und dann geht es auch unter RISC OS flott. Das ist aber bei Portierungen recht umständlich. Das und andere Sachen machen dann portierte Programme für RISC OS nicht gerade schnell. Es gibt halt leider noch viele Baustellen die von den wenigen RISC OS Programmierer nicht alle bearbeitet werden können.
cms, 20. 01. 2017, 11:13 Link
Das ist sicher ein guter Punkt. Es sind halt immer noch Homecomputer - und das ist ja auch gut so, weil es gerade ihren Reiz ausmacht. (Und es hat auch Vorteile.) Vor diesem Hintergrund ist es nämlich auch fraglich, ob es wirklich Sinn macht da echtes SMP einzubauen, insbesondere weil sich evtl. eigentlich bessere Möglichkeiten ergeben könnten. Nichtsdestotrotz ist das natürlich schon eine interessante Sache, daß das jemand mal probiert und auch jemand, wo es hinterher wohl auch funktioniert (präemptives Multitasking gabs ja schonmal).

Der langsame Textbrowser war vermutlich "w3m". Der versucht v.a. Tabellen exakt darzustellen, was teuer ist, und benutzt auch noch das ncurses System zur Ausgabe, beschreibt also das Terminal quasi in Einzelzeichen und richtig ruckelig wirds dann beim Zurückscrollen. Aber zum Lesenkönnen von HTML unter Textoberflächen ist das Ding trotzdem super. (für Dokumentationen o.ä.)

Moderne Browser dagegen haben außerdem auch Hardwarebeschleuniger über die Grafikkarten, was prinzipiell im RPi auch gehen könnte, aber da liegt der Grafik-CoProzessor ja i.P. komplett brach. Das ist bißchen so, wie mit den FPUs, die unter RISC OS (fast) niemals nie benutzt worden sind, aber - Zirkelschluß zum Anfang der Diskussion - eine wirklich wichtige Komponente für schnelle Berechnungen sind, seit ungefähr 1982 oder so. Ich sag mal nur SUN Sparcstation, DEC Alphastation oder HP 9000 - OK, anderes Thema. ;)
naitsabes, 20. 01. 2017, 12:45 Link
EeePC vs. RPi 2: kommt drauf an, welches EeePC-Modell, aber CPU-technisch dürfte der mindestens Faktor 2 schneller sein (Atom N270 oder Atom 330) ohne Berücksichtigung von Multicore und Hyperthreading. RAM-Bandbreite dürfte sehr viel größer sein. Und Platten-I/O-technisch reden wir vermutlich von Faktor 10.

Dazu kommt, dass RISC OS softwaretechnisch beim Thema Dateisystem und Netzwerk-I/O dramatisch schlecht ist. Dazu die unoptimierten Browserportierungen mit der schwergewichtigen Qt-"Emulation". Eigentlich ist es ein Wunder, dass der Otter überhaupt läuft :-)

Wie langsam der RPi 2 ist, merkt man bei "normalen" RISC OS-Anwendungen ja nicht so sehr, aber wenn man mal den Unterschied zum Titanium oder IGEPv5 anschaut...
hubersn, 21. 01. 2017, 01:54 Link
Und wenn man dann noch eine SSD in den EeePC einbaut, kann man die IO Performance auch abholen. Im Gegensatz zum RPi, wo man das Interface mit einer langsamen Platte gut "sättigen" kann.
Kennt jemand dieses Video mit den 24 SSDs als RAID ? (click) Ist ein schöne Performance Demo.
naitsabes, 21. 01. 2017, 11:49 Link
Habe diesen Channel mal noch bißchen weiter"untersucht" und da fand sich auch ein schönes Video zum Thema SMP. Supermicro Board mit 4x CPU und Threads ... jede Menge ; bei laschen 512 GB RAM ; wer sowas nett findet, findet es bei (click) ... ok, ok, der Preis ist auch ein wenig "daneben", wenn man nicht Werbevideos baut oder nach Erdöl sucht
naitsabes, 25. 01. 2017, 14:22 Link
Was das langsame Dateieinlesen durch einzelne Zeichen angeht, liegt es daran, daß RISC OS der einzelne Character Fetch wg. der Rückwärtskompatibilität durch diverse Stellen gereicht wird, während die Blockoperationen das Problem nicht haben. Da LINUX das Problem nicht hat, wird da sehr üppig mit dem Holen von Einzelzeichen gearbeitet, weil es teilweise deutlich einfacher zu programmieren ist. Sowas erschert natürlich die Portierung. Macht man sich umgekehrt die Mühe sowas als Bockoperationen zu schreiben, wird es sowohl unter RISC OS, wie auch unter LINUX sher schnell laufen, aber es ist eben z.T. erheblich aufwendiger.
Thomas Milius, 27. 01. 2017, 20:06 Link
Was A/D-Wandler angeht, so lassen nach gründlicher Prüfung, ob der Source für ein bestimmtes Gerät offen gelegt ist, die USB-RedLab-Geräte von Meilhaus unter RISC OS sauber ansteuern.
Thomas Milius, 27. 01. 2017, 20:09 Link
Was SMP angeht, so wundert mich das immer wieder, daß da angebl. nichts ist. Irgendwie spukt mir immer noch so ein Anouncement von Castle vor vielen Jahren im Hinterkopf herum, daß man in Sachen Parallelität für einen Kunden was gemacht habe. Evt. war die Ankündigung ja auch was für den ersten April.

Es gab ja auch mal Simtecs Hydra. Und ein Mehrprozessor bzw. ein Mehrkernsystem sind so unterschiedlich nicht.

Ob Parallelität so immens viel bringt, weiß ich nicht, schließlich prügeln sich die Kerne oder auch Prozessoren um den gleichen gemeinsamen Speicher. Es gab schon immer die Idee, wenn Parallelität, dann die Taskwindows dafür einzusetzen und den OS Kern weiterhin single taskend zu lassen (d..h Task blockt, wenn Sperre vorliegt und es selbst eine braucht).

Das hat sich für mich immer einleuchtend angehört. Es werden eh immer nur einige Programme sein, die davon profitieren und wo es notwendig ist (tendenziell 3D Grafik).

Mindestens ebenso interessant fände ich ein gutes Konzept zur Unterstützung von Parallelberechnung auf diversen Rechnern über Netzwerk.
Thomas Milius, 27. 01. 2017, 20:26 Link
Ja RISC OS Anzahl geöffneter Dateien war mal beschränkt und liegt glaube ich immer noch bei 256.
Ich habe da allerdings in in den letzten 23 Jahren RISC OS nur Probleme gehabt, wenn ich mich irgendwo bei einer Programmierung grauenhaft vertan habe und eine Datei nach der anderen geöffnet habe.

TCP/IP war auch mal beschränkt (ist es bei den meisten UNIX Systemen ja auch, nur man konnte den Kernel halt mit anderen Parametern rebuilden, wie unter LINUX ist, weiß ich nicht). Wie hoch der aktuelle Wert ist, weiß ich nicht. Früher waren es, glaube ich, 64 oder 256. Heute sind es mindestens 256, wenn ich mich recht erinnere, und es ist wie bei UNIX wohl eher nur ein einziges define, was die Zahl bestimmt.
Da man sich ja prinzipiell seine
eigenen Module zusammen compilieren kann, sollte einer 1024 Verbindungsversion wenig entgegen stehen.

Wer denn unbedingt auf seinem RPI mal Google/YouTube Konkurrenz machen möchte und auf einer Maschine mal 1000 Filme gleichzeitig abspielen möchte, bitte schön, an TCP/IP wird es wohl nicht scheitern :-). Aber evt. ist da doch eher die Plattengeschwindigkeit ein Problem ;-)
Thomas Milius, 27. 01. 2017, 20:42 Link
Bin diese Woche mal auf die bescheuerte Idee gekommen und habe mein MP3-Abspielgerät in den USB-Hub geschoben, der an meinem RPI hängt.

Bei dem MP3-Abspielgerät handelt es sich eigentlich um ein digitales Diktiergerät von Olympus. Weil dieses aber so dermaßen schlecht zu bedienen ist (eigentlich unbrauchbar für die tägliche Arbeit), verwende ich nach wie vor lieber meinen analogen Panasonic Kassettenrekorder (der mit handelsüblichen Kassetten arbeitet und nicht einmal Stereo kann, aber den Quatsch brauche ich auch nicht).

Nun ist es so, dass ich vom RPI aus auf die Speicherkarten des digitalen Diktiergerätes zugreifen kann.

Nun habe ich auf dem RPI !DigitalCD gestartet und die einzelnen MP3-Dateien in die Dateischlange (file queue) geschoben. Ich kann nun die Musik über einen Verstärker abspielen, was für mich von Vorteil ist. Einmal ist der Pegel wesentlich höher als beim Diktiergerät. Beim direkten Anschließen des Diktiergerätes hört man fast nichts; man muss die Lautstärke fast voll aufdrehen. Das andere ist, dass das Diktiergerät selbst nur mit Batterien / Akkus arbeitet. Sind diese leer, müssen diese erst wieder ersetzt / aufgeladen werden. Wird das Gerät an einem USB-Port angeschlossen, arbeitet es nicht mehr.

Was mich jetzt wundert: die Musik wird selbst dann tadellos abgespielt, wenn irgendwelche Programme unter RISC OS das Multitasking sperren (d. h. Sanduhr). Wie funktioniert denn sowas? Denn !DigitalCD bekommt in diesem Falle doch gar keine Rechenleistung zugeteilt, wenn ich das richtig verstanden habe.
Isip, 28. 01. 2017, 02:06 Link
Unter Windows scheint es aber mit vielen über das Netzwerk geöffneten Verbindungen ebenfalls Probleme zu geben. Zumindest bei uns in der Firma war es jetzt bereits desöfteren so, dass der Dateiserver unglaublich langsam wurde, wenn jemanden von uns Solid Edge abstürzte. Dann musste der Dateiserver ein jedes Mal neu gestartet werden. Und der ITler hat sich gewundert, weil nach jedem Absturz wenigstens einige Hunderte von Dateien offen waren. Ist aber auch ein bescheuertes Programm.
Isip, 28. 01. 2017, 02:10 Link
Hallo Thomas,

das mit dem Dateisystem ist also so eine Baustelle die man angehen könnte um Dateizugriffe zu beschleunigen, Auch wenn es dann vielleicht wegen der Rückwärtskompatibilität dann neue SWIs her müssen oder bestehende erweitert werden müssen. Das sollte dann z. B. in den C Compiler leicht umsetzbar sein und Portierungen an dieser Stelle beschleunigen.

Das man mit SMP Anwendungen schön beschleunigen kann ist klar. Aber die Anwendungen müssen das dann aber auch unterstützen. Ich habe schon das eine oder andere Mal unter Linux gesehen das ein Kern auf fast 100% lief und die anderen Däumchen drehten. Das ist bei Windows usw. auch so. Aber das Betriebssystem kann die restlichen Anwendungen auf die "freien" Kerne verteilen.

Bei der Anzahl der offenen Dateien kann es unter Umständen Probleme bereiten von 265 zu 65536 zu gehen wenn die Anwendungsprogramme bei den Handles von einen Byte statt zwei ausgehen. Keine Ahnung inwiefern das wirklich Probleme bereitet.


Wegen Musik trotz Singletaskprogramm: Das wird vermutlich über Interrupts geregelt.
cms, 28. 01. 2017, 16:36 Link
Mal noch 'ne kurze Frage zu den offenen Dateien: Wenn ihr hier von offenen Dateien übers Netz redet, hat das indirekt was mit den Internet-Ports zu tun oder verwechsle ich hier was?
Isip, 29. 01. 2017, 05:54 Link
Bei Dateien meinte ich Dateien, also die Dinge die lokal auf der Festplatte/SSD/SD/RAM-Disc usw. liegen. Via Netzwerk/Internet würde ich das Verbindungen nennen. Beides ist aber mehr oder weniger begrenzt, egal welches Betriebssystem. Wenn das mit maximal 256 offenen Dateien stimmt, ist es recht wenig.
cms, 29. 01. 2017, 09:27 Link
Guck mal nach dem OSI Schichtenmodell (click), das macht moeglicherweise nicht gleich vieles klarer, eher im Gegenteil (leider), ist aber trotzdem nicht unwichtig. Ports selber kann man sich vielleicht eher als sowas wie einen offenen Kanal vorstellen, der genauso wie bei den Dateitypen im RISC OS eine Nummer hat, womit immer klar ist, wofuer er eigentlich benutzt werden soll.

Interessante Linuxbefehle diesbezueglich sind "lsof" oder "netstat -a". Und bei
www.freebsd.org/doc/de_DE.ISO8859-1/books/handbook/configtuning-kernel-limits.html
gibt es eine schoene Erklaerung, wie die Maximalzahl moeglicher Dateien bestimmt werden kann.
naitsabes, 29. 01. 2017, 19:03 Link
Und - hat mal jemand rausbekommen, wie die Dateibegrenzungen für offenen Dateien bei RISC OS sind und wo sie definiert sind ?
Vielleicht ist das ja sogar "open end", wenn da bei jedem Öffnen z.B. ein buffer% in einer neuen DA angelegt wird, was ich ja nicht glaube, weil man das im Taskmanager vielleicht doch irgenwie sehen würde.
naitsabes, 03. 02. 2017, 11:40 Link
Mit einen kleinen Programm (BASIC, C, Perl, Lua, ...) das in einer Schleife Dateien öffnet solltest Du dich der Grenze nähern können. Kleiner Zähler dazu und den Stand ausgeben. Dabei solltest Du aber unbedingt wichtige Arbeiten an den Du viele Stunden gesessen hast umgespeichert lassen. ;-)
cms, 03. 02. 2017, 12:23 Link
I%=0
REPEAT
DATEI$="RAM::RamDisc0.$.daten"+STR$(I%)
PRINT I%," ... ",DATEI$," ... ";
D=OPENOUT DATEI$ : PRINT D : PRINT#D,"testing"+DATEI$
I%+=1
UNTIL FALSE

Also - ich habe, wie empfohlen, alle wichtigen Dateien geöffnet und dann das da gestartet - dann ist der Rechner abgestürzt und jetzt ist alles weg ... Danke für den tollen Tip. :=O

Ne, nix passiert - alles schön. ;)
Aber das da läßt max. 255 offene Files zu. Danach ist Schluß. Nur gilt das dann auch systemweit als Einschränkung ?

Dort wird anscheinend einfach so eine Art Filepointer verteilt, der von 255 beginnend abwärts gezählt wird und bei Null ist halt "alle". Klappt tatsächlich auch, wenn man das Programm 2x parallel startet. Parallel und dazu auf unterschiedlichen Filesystemen (ADFS,SCSIFS) habe ich es noch nicht probiert. Irgendwie scheint mir das herzlich wenig zu sein, 255, zumindest im Vergleich zu den abertausenden möglichen offenen Dateien auf so einem unixoiden WasAuchImmer.
naitsabes, 03. 02. 2017, 13:56 Link
Ich komme selten auf mehr als 20 offene Dateien. Und noch niemals war die Dateigrenze mit 255 für mich ein wirkliches Problem. Also da gibt es andere Dinge die wichtiger wären - meiner Erfahrung und Einschätzung nach.
Markus Huber, 03. 02. 2017, 14:44 Link
Unix usw. wird auch gerne als Server benutzt und da können schnell viel Dateien geöffnet sein. Ende der 90er hatten wie das Problem mit dem Webserver. Jeder virtuelle Webserver hatte zwei Logfiles. Die CGI Programme haben auch ihr Werk getan und wenn dann zu viele CGI Programme gleichzeitig liefen gab es einen Fehler. Seit dem achte ich darauf so früh wie möglich Dateien zu schließen. Wir haben dann die Anzahl den Logfiles reduziert und der Kollege hat an den Linuxkernel gedreht damit der mit mehr als 255 offenen Dateien umgehen kann. Vermutlich hat er einfach an der richtigen Stelle die 255 durch eine 512 oder so ersetzt. Lang ist es her und der Kernel unterstützt schon lange mehr offene Dateien.

Ansonsten hat Markus recht, aber viel sind 255 nicht. Wenn das ein Problem wäre wüste jeder RISC OS Benutzer wo die Grenze ist. OK, jetzt wissen wir es auch so. War das RISC OS 5? Was ist am Ende passiert? Dateisystem und RISC OS kann schon böse Effekte haben. Zumindest habe ich da früher keine guten Erfahrungen gemacht.
cms, 03. 02. 2017, 15:25 Link
Also ein "wirkliches Problem" würde ich es auch nicht nennen - da stimme ich zu. Eher vielleicht eine "interessante Begrenzung" oder ein "potentielles", insbesondere in Hinsicht auf SMP mit ca. >= 128 ARM Cores. Ich wäre ja auch nie auf die Idee gekommen, sowas durchzuzählen, es hat ja eigentlich immer gut funktioniert mit dem Dreiklang Öffnen-Lesen/Schreiben-Schließen und Datenhandle habe ich bisher immer bekommen.

Es war RISC OS 5.22 auf einem RPCEmu. Am Ende passiert, daß der Taskmanager abschmiert inkl. Icon rechts unten. Damit geht dann auch kein F12 mehr und man kann außer mit RESET die Sache nicht mehr "retten". Benutzen geht aber schon noch, nur eben wird jede Fileoperation abgewiesen.
Interessanterweise kann man aber VORHER ein Taskwindow öffnen. Das bleibt am Ende erhalten, warum auch immer, und dort kann man *close eingeben - und wieder von vorne anfangen.

Bei parallelen Starts auf unterschiedlichen Filesystemen (RAM + HostFS) bleibt die Grenze auch bestehen.
naitsabes, 03. 02. 2017, 16:21 Link
Im "normalen" RISC OS-Betrieb tritt natürlich selten das Problem auf, dass einem die Filehandles ausgehen. Weil alle RISC OS-Programmierer sensibilisiert sind und keiner unnütz Dateien offen lässt. Trotzdem ist die Beschränkung ärgerlich: denn man muss dann vor allem bei portierter Software, die von Systemen stammt, wo das kein Problem ist, ggf. Anpassungen vornehmen. Und ein ständiges Öffnen und Schließen ist natürlich bei derzeit gängigen Dateisystemen unter RISC OS auch eine ziemliche Performancebremse, weil das Schließen zwingend den Flush nach sich zieht.

In Diskussionen um das Anheben des Limits wird immer die Problematik der Rückwärtskompatibilität genannt. BBC B und so...da war das Filehandle immer ein Byte, und so bleibt das nun für alle Zeit, weil ja irgendwo noch Software existieren könnte, die den Hinweis in den PRMs zu RISC OS 2 ignorieren, dass das Filehandle gefälligst als "opaque 32bit type" zu behandeln ist.

Wie auch immer: die viel größere Katastrophe ist, dass die RISC OS Filehandles "global" sind. Jedes Programm kann jederzeit Filehandles anderer Programme kapern und was reinschreiben oder auch einfach mal schließen. Und wenn ein Task absäuft, bleiben die daraus geöffneten Dateien offen.

Und trotz dieser Katastrophen stimme ich zu, dass RISC OS viel wichtigere Probleme hat.
hubersn, 03. 02. 2017, 16:45 Link
Ich habe ein CLI Kommando mit dem ich gezielt Dateien schließen kann. Entweder radikal weg, fürs Programm ist dann auch der Handle ungültig (event. kommt eine entsprechende Fehlermeldung), oder weich schließen: für das laufende Programm ist der Handle zwar noch gültig aber alles was das Programm damit macht geht ins Nirvana. Nur wenn das Programm den Handle dann doch selbst schließt, wird auch der Nirvana-Handle wieder frei fürs RISC OS (keine Fehlermeldung, alles sauber). Wunderbare Sache.
Markus Huber, 03. 02. 2017, 18:31 Link
Hallo Markus,

wie funktioniert das "soft"-Schließen technisch? Hört sich nach bösem Hack an.

Das "harte" Schließen kann halt üble Folgen haben. Denn das Handle ist ja ggf. nur für kurze Zeit ungültig, es kann jederzeit wieder von RISC OS vergeben werden. Und dann ist die Kacke richtig am Dampfen, wenn zwei Programme sich dasselbe Handle teilen und drauf rumschreiben.

An der Ecke merkt man leider deutlich, dass RISC OS im Herzen immer noch ein Singe-User-Single-Tasking-Betriebssystem ist.
hubersn, 04. 02. 2017, 01:11 Link
Die interne Funktion vom "soft"-Schließen kann ich Dir leider nicht erklären. Ich habe die Funktion damals bei Matthias in Auftrag gegeben.

*Help CloseFile
==> Help on keyword CloseFile
*CloseFile <filename> closes the specified file but let's the handle still be valid.
*CloseFile * removes all handles which have been affected by *CloseFile <filename>.
*CloseFile #<handle> closes the specified file.
*CloseFile #0 closes all files on the current filing system (same as *Close).
If used with no parameter *CloseFile lists all open files.
Syntax: *CloseFile [<action>]
*

Das "harte"-Schließen ist eigentlich nur in umgekehrter Verwendung als Du es beschreibst. Ein Programm das längst abgeraucht ist und als Task rausgekickt wurde, kann nie mehr irgendetwas selbst auf dem noch gültigen offenen Handle machen. Der Dateizugriff ist für andere damit - abhängig von der Art des Handles - unmöglich. Dann ist ein Neustart des abgestürzten Programms ebenfalls noch sinnlos, wenn die selbe Datei geöffnet werden soll. Hier ist "hartes"-Schließen angesagt und so herum eingesetzt wird es keine negativen Folgen haben.
Markus Huber, 04. 02. 2017, 16:28 Link
Da fällt mir doch noch die recht lustige Dateinamenbegrenzung von 256 Bytes bei Windows ein. 'Einschließlich' dem Dateipfad, wohlgemerkt.

Es gibt 3D-CAD-Systeme, die sind interessanterweise recht klug entworfen, und deshalb werden 255 offene Dateien ganz schnell überschritten. SolidEdge, CATIA usw. zum Bleistift, aber ich will hier keine Namen nennen. Das funktioniert bei Baugruppen nämlich so: Es gibt eine Baugruppendatei. Mit dieser Baugruppendatei sind aber hunderte bis aberhunderte oder gar tausende weitere Dateien (weitere Unterbaugruppen oder Einzelteile) verknüpft, die alle ins System geladen werden müssen. Da werden dann ganz schnell mal tausende von Dateien _gleichzeitig_ geöffnet.

Aber so einen Murks gibt es Gott sein Dank für RISC OS nicht.
Isip, 05. 02. 2017, 15:44 Link
Man muss da schon fairerweise sagen, dass nur die Windows API diese Beschränkung hat. Sprich im Windows.h Header ist ein Makro MAX_PATH 260 gesetzt.
Aber das NTFS Filesystem kann schon immer über 32.000 Zeichen lange Pfadangaben! NTFS ist technisch sehr weit vorne dabei. MAX_PATH ist nur auf Anwendungsseite aus Kompatibilitätsgründen drin. Auf Windows-Netzlaufwerke kann dagegen schon lange mit dem Prefix "\\?\" ein langer Pfad erzeugt werden.

Naja, seit Windows 10 Version 1607 ist MAX_PATH aufgehoben, und der Anwender kann in der Registry auf über 32.000 Zeichen umsteigen.
Artchi, 05. 02. 2017, 17:24 Link
Super! Danke für diesen echt interessanten Hinweis! Wo lernt man sowas eigentlich? Bei uns auf der Schule eher ned.
Isip, 05. 02. 2017, 17:47 Link
Was das kapern von Datei-Handles angeht, so gibt es wie immer im Leben Vor- und Nachteile. Ich habe Mitte der 90er Jahre mal !FileAcces verbrochen und dabei eine Menge über RISC OS gelernt. Das gute Stück sollte sicherstellen, daß verschiedene Nutzer RISC OS (nacheinander) nutzen können, ohne daß der eine unerlaubter Weise die Dateien das anderen einsehen oder manipulieren darf. Hat alles in allem auch geklappt, wenn auch mit argen Performanceverlusten. Das Projekt wurde eingestellt, als ich feststellte, daß man immer unter RISC OS in den Debugger Modus kommt und damit letztlich jede Sicherung aushebeln kann. Die Performanceverlsute waren darauf zurückzuführen, daß das Programm auch einen Schutz gegen FileHandleStealing eingebaut hat.
Nur da RISC OS eigentlich ein Ein-Nutzer-System ist, ist es ziemlich egal, ob ein Programm dem anderen was klaut, wenn es eh alles machen kann.

Nebenbei sehe ich das Handle Stealing mittlerweile als nettes Feature, um die Schreibbeschränkung auf ein Programm für eine Datei zu umgehen. Da könnte man richtig leistungsfähige Datenbanken mit aufbauen und das nur mit 255 offenen Dateien! Bei SMP muß man aber höllisch mit den internen Puffern und der Unteilbarkeit bestimmter Operationen aufpassen.

Nebenbei UNIX/LINUX ist gerade in diesem Punkt auch kein Musterschüler. Ich kenne fatale Beispiele aus der Praxis, wo ein Progamm dem anderen die Daten unterm Allerwertesten wegzog, weil man sich über die Synchronisation des Dateipointers keine Gedanken gemacht hatte (UNIX hat da aber seit Urzeiten eine alles andere als einfach zu handhabende Bibliothek für).
Thomas Milius, 05. 02. 2017, 20:55 Link
Isip! Ich programmiere auch mal Windows APIs direkt und nicht nur über Multiplatform-Wrapper (Boost, Qt usw.), und lerne so auch Windows-Features kennen. Wenn man z.B. nur die C-File-StdLib benutzt, wird diese wahrscheinlich MAX_PATH benutzen, um wenig Ärger mit altem C-Code zu produzieren. Es ist halt nur ein Wrapper und somit nur ein Kompromiss.

Schaut man aber in der MSDN (click auf meinen Namen) zur Windows-API-Funktion CreateFile() nach, wird man feststellen, das Windows NT doch mehr drauf hat:
"In the ANSI version of this function, the name is limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, call the Unicode version of the function and prepend "\\?\" to the path."
"Starting with Windows 10, version 1607, for the unicode version of this function (CreateFileW), you can opt-in to remove the MAX_PATH limitation without prepending "\\?\"."

Hier liegt genau das Problem bei Portierung von Multiplatform-Anwendung auch auf RISC OS. Es werden gerne Wrapper benutzt, um schnell zu Ergebnissen zu kommen. Um aber ein System auszureizen, muss man deren Features kennen und auch mal dessen offizielle öffentliche API direkt nutzen.
Artchi, 06. 02. 2017, 11:51 Link
OK, unter RISC OS weiß nicht, wie oft neue APIs dazu kommen, die auch mal ältere APIs verbessern. Aber nicht nur die APIs, auch Hardware müsste man beachten.

Die kleinen ARM-Boards sind nunmal nicht leistungsfähiger als ein Smartphone oder Tablet. Das ist ggü. einem Desktop-PC mit z.B. kleinen i3 ein Witz. Deshalb muss so ein Webbrowser unter RISC OS z.B. schauen, wie auf den Smartphones und Tablets die Webbrowser getrickst wird.
Artchi, 06. 02. 2017, 11:58 Link
"Die kleinen ARM-Boards sind nunmal nicht leistungsfähiger als ein Smartphone oder Tablet."

Das ist noch stark untertrieben. Die schnellsten RISC OS-tauglichen Boards - OMAP5 Cortex-A15 mit 1,5 GHz - sind sehr deutlich langsamer als das, was heute in Tablets oder Smartphones verbaut wird. Und dazu nur ein Core nutzbar statt zwei oder vier. Der Apple A10 läuft mit schlanken 2,4 GHz, zwei Cores und deutlich höheren DMIPS/MHz-Werten als ein Cortex-A15. Und die Snapdragons, Exynos und Tegras sind ähnlich weit voraus. Dazu noch größere Caches und schnelleres RAM, zumindest in den Tablets wo es nicht auf jedes mW ankommt.
hubersn, 06. 02. 2017, 22:38 Link
Hm. Bei uns auf der Schule hatten wir in C nur die StandardCLibrary mit der Ausgabe in ein Konsolenfenster behandelt. Und freilich nur Microsoft Visual Studio als Compiler verwendet. Wie man so vernünftig programmieren lernen soll, das verstehe ich eh nicht. Wenn ich hier sehe, was man alles so machen kann, wenn man die verfügbaren Betriebssystemroutinen nur auch einfach nutzt. Hier habe ich jetzt sogar ein Fenster mit einer Laufschrift programmieren können. Ist zwar noch primitiv, aber nicht viel Code und sehr einfach.

Schade, schade, schade. Um die Zeit. Komplizierte Algorithmen alleine, welche die Studenten bis zur Verzweiflung bringen, sind es halt auch nicht.
Isip, 07. 02. 2017, 06:41 Link
Ich denke da überforderst Du die Schulen und Universitäten. Die können nur Grundlagen vermitteln. Würden die auf jedes Detail der Betriebssysteme eingehen und auch die verschiedenen Bibliothek für die Fenster usw. (z. B. Qt und GTK+) ausführlich behandeln, dann würde ein Informatikstudium Jahrzehnte dauern und vermutlich nie enden, da sich ja auch ständig Dinge ändern und hinzukommen. Mit Grundlagen, die C-Standard-Bibliotheken sind da welche, kommt man schon etwas weiter. Den Rest muss man sich dann in der Praxis nach Bedarf aneignen. Es wird nicht viele Menschen geben die die RISC OS PRMs durchgelesen haben und bei Windows usw. würden noch ein paar Bücher mehr hinzukommen. Gibt es überhaupt so etwas wie die PRMs für Windows? Waren die PRMs eigentlich seinerzeit vollständig?
cms, 07. 02. 2017, 09:09 Link
@Isip! An der Berufsschule/FH/Uni werden Grundlagen vermittelt, da hat CMS schon Recht. Denn wenn du danach in die Berufswelt los gelassen wirst, ist das nötige Know How für ein Spezialgebiet unüberschaubar. Die einen Firmen machen Desktop-Software, die anderen Server-Software usw. Und das auch wiederrum in unterschiedlichen Sprachen (C, C++, Java, JavaScript usw.). Die Sprachen und APIs kann man sich selber je nach Arbeitsstellenanforderung selbst aneignen. Und bei der Entwicklung muss man eh immer in einer Referenz nachschlagen.
Spezielle APIs veralten sehr schnell. Was heute im Trend ist, ist morgen legacy. Allgemeine APIs und Konzepte kann man als Grundlage immer verwenden.

Wichtiger ist eher Software-Architektur zu lernen, z.B. S.O.L.I.D. Prinzipien, da man diese überall gebrauchen kann und sie wohl nie veralten.

@CMS! Es gab natürlich damals so was wie die PRMs für Windows. Ich hatte 1999 zur VisualC++ 6.0 Standard Edition (nur 129 DM), neben dem C++ Compiler, SDK und IDE, mehrere Poster (Architektur-Diagramme, MFC-Klassen-Diagramm usw.) und CD-ROMs erhalten, mit der vollständigen API-Referenz, Tutorials, Zeitungsartikel, Projektbeispiele usw. Heute ist natürlich alles online verfügar und noch umfangreicher.
Man muss MS eines lassen: die Dokumentation zu allen ihren Produkten war und ist sehr gut.

Die RISC OS PRMs hatten bzw. haben keine Tutorials. In den PRMs findet man Codebeispiel, die kann man an einer Hand abzählen. Fand ich damals wirklich schwierig, als Programmieranfänger was zu produzieren. Jemand mit mehr Erfahrung wird sich natürlich zurecht finden, aber damit gewinnt man keine Einsteiger.
Artchi, 07. 02. 2017, 11:16 Link
Deswegen sind es ja auch PRMs - "reference" und so ...

Vielleicht sollte man mal eine Bücherliste auf arcsite machen, die auch "beginners" berücksichtigt, d.h. welche mit denen sich am Anfang was anfangen läßt, die sonstwie lesenswert sind oder für RISC OS nützlich. Vielleicht mit Bewertungssystem. Und Isip kann dann ja mal durchgucken und sagen, was davon wirklich was taugt.

Ich empfehle gleich mal ein schönens Grafikbuch, was gefühlt unglaublich legacy ist, sich mit Plottern und sowas befaßt, aber eine sehr feine, lesbare und verständliche Einführung in die weiten Welten der 2D und auch 3D Grafik bietet, inkl. Formeln, die man gleichmal in eigenen Programmen probieren kann.

Computergrafik: Einführung, Algorithmen, Programmentwicklung
von Plate, Jürgen (Gebundene Ausgabe, 536 Seiten) Franzis Verlag GmbH, Februar 1998
(Inhalts PDF bei (click!) )

Und natürlich auf jeden Fall die !StrongHelp Dateien zu OS_SWIs, Basic und WIMP. Keine Ahnung, wo die momentan rumgeistern. Zum immer-dabei-haben ein Muß.
naitsabes, 07. 02. 2017, 12:35 Link
Die PRMs sind ja kostenlos online verfügbar. Das ist ja nicht das Problem.

http://www.riscos.com/support/developers/
https://www.riscosopen.org/wiki/documentation/show/Programmer's%20Reference%20Manuals

Das C-WIMP-Tutorial auf arcsite ist schon ein sehr guter Weg, um Einsteigern Steine aus dem Weg zu räumen.
Artchi, 07. 02. 2017, 13:48 Link
Bücher die sich um RISC OS Programmierung kümmern sind mir keinen guten bekannt. Was mir damals für den Wimp-Einstieg geholfen hat waren die GAG News 4-9, 11, 12, 16-19 und 21. Vielleicht sollte Herbert die wieder veröffentlichen. Die PRMs und auch das StrongHelp Manual sind wirklich nicht für den Einsteiger geeignet. Später aber unverzichtbar.
cms, 07. 02. 2017, 14:15 Link
hubersn! Das die RISC OS Boards sogar weit unter Smartphone-Leistung angesiedelt sind, ist ja noch erschreckender. Da wird es sehr schwer für RISC OS weiter den Anschluss zu behalten.
Artchi, 08. 02. 2017, 11:21 Link
Viele RISC OS Bücher behandeln die Themen in Assembler oder Basic. Damit kann man heute schwer Anfänger begeistern.
Die Bücher und Tutorials müssten schon in C oder C++ lehren, damit der Leser auch schneller zu Ergebnissen kommt.
Artchi, 08. 02. 2017, 11:25 Link
Also gute Reference Manuals - und die von RISCOS sind mit ABSTAND die Besten ;) - sind mir 1000 mal lieber als mittelprächtige Tutorials.

- ct.ger proofed Acorn Apologet
- beware, I'm ARMed
Gryf ap Llandrysgryf, 08. 02. 2017, 12:17 Link
Die RISC OS PRM sind wichtig und sehr gut. Aber es ist nichts für Programmier-Einsteiger. Es ist halt eine Referenz, in der man nachschlägt, wenn man schon RISC OS Programmiererfahrung hat. Zumindest sind Tutorials immer einfacher als eine Referenz.

Ich gebe einem Prorgammiereinsteiger auch nicht die ISO-C++-Referenz, und sage ihm: "So, jetzt lerne und programmiere damit C++!". Nein, erst wenn er mit einem Lehrbuch schon gewisse C++-Erfahrung drauf hat, kann er sinnvoll in die C++-Ref Details nachschlagen und gesuchte Funktionen, Klassen usw. ausfinding machen.

Warum soll es bei RISC OS immer auf die harte Tour sein?

Und nochmal: großes Lob an den Schreiber des C-WIMP-Tutorials auf Arcsite! Genau das ist nötig, um alte oder neue Hasen für RISC OS zu gewinnen.
Artchi, 08. 02. 2017, 14:22 Link
Nenene. Wir hatten drei Semester C. Und was davon wirklich (verständliche) Grundlagen waren, hat mich total enttäuscht. Ich war ja danach nicht einmal in der Lage, das Gelernte auf GCC und RISC OS anzuwenden. Und genau das war ja das Problem.

Eine Fachhochschule soll Grundlagen vermitteln. Die man dann beliebig anwenden, übertragen und erweitern kann. So wie ihr gesagt habt. Aber in meinem Fall war nicht einmal ein Verständnis für den Compiler gegeben. Oder wie man verschiedene (beliebige) Bibliotheken einbindet. Aber das ist alles Handwerkszeug, das man braucht.

Es sollte doch egal sein, welche Bibliotheken oder welche Compiler man verwendet. Aber bei uns beschränkte sich das halt auf die StandardCLibrary (mit der man nicht wirklich unbedingt tolle Sachen machen kann) und auf Microsoft Visual Studio.

C ist mehr als nur C. Da gehören auch solche Sachen wie von C in Assembler übersetzen oder das Makefile (von Unix) dazu. Für mich alles Grundlagen, die nicht einmal erwähnt worden sind.

Natürlich kann nicht jede Funktion im Detail erwähnt werden. Das macht auch keinen Sinn. Aber bei uns wurde z. B. nicht einmal erwähnt, welchen Gedanken oder welche Bedeutung die Datentypen haben. Oder was man beachten muss, um C-Programme zu schreiben, die (einfacher) portierbar sind. Oder dass in C grundsätzlich jeder Wert irgendwie durch möglichst aussagekräftige Konstanten ersetzt wird (bestimmte Speicheradressen von Mikrokontrollern z. B.). Sowas wären für mich Grundlagen gewesen, Mensch.
Isip, 08. 02. 2017, 19:20 Link
Und danke für das Lob. Der nächste Teil wird ein ziemlicher Schritt werden; da fangen die Programme denn auch zu arbeiten an und reagieren auf die Befehle des Anwenders (bzw. machen irgendwas). Und ich bin inzwischen ziemlich verblüfft, was man alles mit (sehr) wenig C-Code in der WIMP anstellen kann... ein Interface (Oberfläche) zu programmieren sollte eigentlich nicht das Problem sein. Beispiellistings entstehen so nach und nach hier zuhauf. Ist halt leider das Problem, dass auch ich eigentlich immer zu wenig Zeit für sowas habe.
Isip, 09. 02. 2017, 06:39 Link
ArcSite   News   Magazin   Börse   Links   ArcArchie   Homepages