Diskussion:Maschinensprache/Archiv/1

message: Wie schon früher festgestellt wurde, hatte der erste Teil eine starke Überscheidung mit Befehlssatz, das ist damit korrigiert, ich werde versuchen, die entsprechenden Teile in den Artikel Befehlssatz einzuarbeiten.
Was bleibt ist die schon früher und auch hier ganz oben festgestellte thematische Überscheidung mit Assembersprache, die in der zweiten Sektion noch vorhanden ist und sich noch korrigieren lassen sollte.--84.148.56.122 14:51, 12. Feb 2006 (CET)
thread_title:  Erste Sektion überarbeitet 

message: Ein Programm muss einem Befehlssatz vorliegen, der vom Prozessor unterstützt wird, damit es von ihm direkt komplett ausgeführt werden kann.
Diesen Satz verstehe ich nicht, hab' ihn deshalb entfernt--Staro1 04:15, 28. Mär 2006 (CEST)
thread_title:  ? 

message: "Wird von der Programmierung in Maschinensprache gesprochen, wird heute üblicherweise die Maschinenprogrammierung in Assemblersprache unter Verwendung eines Assemblers gemeint, der das als Textdatei vorliegende Assemblerprogramm in binäre Maschinenbefehle übersetzt."
Bitte mit Quellen belegen, das halte ich doch fuer sehr fraglich. Sagt man nicht eher, dass man in "Assembler" programmiert, wenn man in der Assemblersprache programmiert?84.59.222.42 18:20, 8. Apr. 2008 (CEST)
thread_title:  Ach ja? 

message: Mir fehlt der Bezug zu Lochkarte. Waren nicht Lochkarten die erste Möglichkeit Programme zu speichern, bzw. von Hand zu erstellen? Da wurde doch auch Maschinensprache als Binärkode in die Karten gelocht. --Suricata 21:44, 2. Okt. 2009 (CEST)
replies: text: Das ist nicht eine Frage der Sprache, sondern der Darstellung.  Ich denke nicht, dass wir hier über Lochkarten reden müssen.  Wir haben damals übrigens keinen Binärcode in die Karten gelocht, sondern auch eine textliche Darstellung von Maschinensprache, siehe Assembler (Informatik).  Ganz zu Anfang hat man Maschinencode tatsächlich wirklich binär über Steuertafeln mit Schaltern direkt in die Maschine geladen; im Artikel PDP-1 siehst du  eine entsprechende Abbildung. --Herbert Klaeren 10:06, 3. Okt. 2009 (CEST)
replies: text:   Wie locht man eine textliche Darstellung in die Karten? Wurde da ld a,0 etc als ASCII in die Karten gelocht und nicht der zugehörige Maschinencode? --Suricata 14:06, 3. Okt. 2009 (CEST)
replies: text:  Genau! Allerdings lochte man Karten nicht in ASCII, sondern eher in EBCDIC (sprich: "ebbsidick").  Dabei entstehen in jeder Lochkartenspalte höchstens zwei Lochungen, für anderes waren die Kartenlocher auch gar nicht vorgerüstet.  Auf Wunsch hat einem der Assembler dann den erzeugten Objektcode wirklich binär in Karten gelocht; diese Karten hatten dann in der Regel mehr als zwei Lochungen pro Spalte.  Wenn man solche Binärkarten dann in einem Lochkartenlocher duplizieren wollte, konnte es zu Verklemmungen im Stanzmechanismus kommen, schlimmstenfalls wurde das Gerät beschädigt.  Um Verwechslungen auszuschliessen, haben die meisten Rechenzentren Binärkarten verwendet, die sich durch die Färbung von den handgelochten EBCDIC-Karten unterschieden.  Gruss --Herbert Klaeren 19:00, 3. Okt. 2009 (CEST)
replies: text:  Danke! --Suricata 20:32, 3. Okt. 2009 (CEST)
thread_title:  Lochkarten 

message: Es ist nicht richtig, dass in Maschinensprache und/oder Assembler nur absolute Sprungadressen verwendet werden können. Der Z80-Prozessor beispielsweise bietet auch relative Sprünge an, also z.B. 20 Bytes nach vorne.
Ich nehme an, der Autor meinte, dass in Assembler symbolische Sprungadressen über Labels angegeben werden können. Falls keiner widerspricht werde ich das demnächst ändern.
--85.70.197.210 22:18, 10. Jun. 2010 (CEST)
replies: text: ja natürlich, das muss es sein, was der Autor gemeint hat. Praktisch jeder Prozessor hat Instruktionen für relative Sprünge. Ändere es ruhig. --Herbert Klaeren 22:56, 10. Jun. 2010 (CEST)
thread_title:  Sprungadressen 

message: Auch das ist in weiten Teilen falsch. Informieren Sie sich bevor Sie Artikel publizieren! (nicht signierter Beitrag von 195.170.70.68 (Diskussion | Beiträge) 21:29, 13. Dez. 2002 (CET)
replies: text: Stellen Sie bitte eine Kopie der Ihrer Ansicht nach falschen Teile des Artikels hierhin und geben an, was daran falsch ist! Sonst outen Sie sich nur als unproduktiver Nörgler. (nicht signierter Beitrag von 195.186.164.249 (Diskussion | Beiträge) 16:30, 14. Dez. 2002 (CET)
thread_title:  Vieles falsch 

message: Dieser Artikel ist ziemlich ähnlich zu Assemblersprache. Sie sollten aufeinadner abgestimmt werden. (nicht signierter Beitrag von 129.132.73.142 (Diskussion | Beiträge) 15:57, 18. Jan. 2003 (CET)
thread_title:  Assemblersprache 

message: Wie hier schon angedeutet, sind bestimmte Teile dieses Artikels falsch. Dieser Kommentar beschreibt und begründet eine erste Korrektur. Aus dem 1. Absatz:
:Von Maschinensprache spricht man eher dann, wenn man ein konkretes, in Maschinensprache vorliegendes Programm analysiert oder wenn man den Befehlssatz (etwa vergleichend) auf seine sprachlichen Eigenschaften hin analysiert.
Der erste Teil ist richtig, jedoch der zweite falsch. Er fällt sich schon selbst über die Füsse, indem er den Begriff Befehlssatz im Kontext verwendet. Schelmisch könnte darauf sagen: "Gerade wenn man den Befehlssatz (etwa vergleichend) auf seine sprachlichen Eigenschaften hin analysiert, verwendet man Befehlssatz" :) Im Kontext der sprachlichen Eigenschaften wird der Begriff Maschinencode eher benutzt um z.B. über die Lesbarkeit zu sprechen: "Kannst du diesen Maschinencode lesen?" Dies ist jedoch schon im ersten Teil, bei der Analyse eines vorliegenden Programms gemeint. Ich habe, da es hier auch um Maschinencode, geht, den ersten Teil so fortgesetzt:
:Von Maschinensprache spricht man eher dann, wenn man ein konkretes, in Maschinensprache vorliegendes Programm analysiert, also sich auf die Anwendung des Befehlssatzes konzentriert.
2.Absatz:
:Da sich der Befehlssatz von Rechner mit unterschiedlichen Prozessoren im allgemeinen unterscheidet, sind in Maschinensprache geschriebene Programme nur sehr schwer übertragbar. Jede Prozessorarchitektur hat eine eigene, unterschiedliche Maschinensprache. Die direkte Programmierung in einer Maschinensprache wird heute kaum noch verwendet. Einige Programmiersysteme für höhere Programmiersprachen gestatten es, Maschinenbefehle in den Quelltext zu integrieren. Die Anwendung beschränkt sich dann auf solche Fälle, in denen es aus Effektivitätsgründen unumgänglich ist, maschinennah zu programmieren, wie etwa bei Hardware-Treibern.
Der erste Satz ist nur schwer verständlich und so wie er dort steht Nonsens. Der erste Teil verallgemeinert auch zu stark, Beispiel, auf diese Logik angewant: "Da sich der Befehlssatz von Rechnern mit unterschiedlichen Prozessoren (Beispiele: Pentium, Pemtium M, Mobile Pentium, Celeron, Athlon, Athlon64, Xeon, Opteron, ..) unterscheidet, sind in Maschinensprache geschriebene Programme (z.B. Viren, Würmer) jeweils nur sehr schwer übertragbar und können deswegen nur sehr schwer von einem System aufs andere Übertragen werden."
Viren und Würmer (n ur als Beispiel) verbreiten sich gerade deswegen so gut, weil diese Prozessoren, die alle eine gemeinen Befehlssatz unterstützen, in weiten Teilen zueinander kompatibel sind und sich deswegen greade auch in Maschinensprache geschriebene Programme zwischen ihnen übertragen lassen.
Der Unsinn geht im 2. Satz weiter.  Man könnte genauso sagen: "Jede Menschenrasse hat eine anderen, unterschiedlichen Slang". Hier wird der Begriff Maschinensprache auf einer Ebene benutzt, wo eigentlich Befehlsatz verwendet werden müsste, und es wird der Begriff Prozessorarchtektur auf dieser Ebene verwendet, er passt jedoch eher auf die Ebene von RISC und CISC, was viel besser weiter unten behandelt wird. Eher würde in diesem Kontext der Begriff Rechnerarchitektur passen, hier müsste jedoch etwas mehr erklärt werden, da viele Rechnerarchitekturen die Befehlssätze älterer Prozessoren/Architekturen aus Kompatiblität unterstützen.
Der nächste Satz verallgemeinert ebenfalls zu sehr, der dritte spricht von der Integration vn Maschinenbefehlen, wo es beser Assemblerbefehle heissen sollte und man sollte hier spezifischer von den Compilern und nicht von "Programmiersystemen" sprechen. Zum letzten Satz: Gerade bei Hardare-Treibern ist es nicht zwingend notwendig, direkt Assemberinstruktionen direkt in den Quelltest zu integireren. Ein Beispiel dafür sind die Open Source-Treiber im Linux-Kern, die, wenn sie korrekt implementiert sind, auf allen Architekturen verwendet werden können, auf der die entsprechende Hardware zur Verfügung steht. Ein konkretes Beispiel dafür sind die Treiber für PCI-Karten (z.B. Netzwerkkarten) die auf PowerPCs und auf Intel-PCs eingesetzt werden können. Ich habe diesen Absatz daher wie folgt überarbeitet:
:Da der Befehlssatz dem für Programme verfügbaren Funktionsumfang eines Prozessors bestimmt, unterscheideen sich die Befehlssätze von von unterschiedlichen Prozessoren sehr oft.                                                                                 Damit in Maschinensprache vorliegende Programme auf neueren Prozessoren weiterververwendet werden können, unterstützen die meisten Prozessoren jedoch den Befehlssatz von einer Rechnerarchitekturen.                                                                                                                                   Jede Rechnerarchitektur hat eine eigene, unterschiedliche Maschinensprache, wobei viele Rechnerarchitekturen Kompatibilität zu anderen Rechnerarchitekturen beinhalten.                                                                                           Einige Compiler höherer Programmiersprachen gestatten die Integration von Assemblerbefehlen in das in Hochsprache geschriebene Programm um. Dies bringt mit sich dass:
:* Bestimmte, von Compilern meist nicht verwendete Befehle verwendet werden können, z.B. Behehle der Instruktionserweiterungen MMX, SEE, SSE2, 3DNow!
:* Die so implementiere Funktion nur auf System ausgeführt werden kann, die verwendeten Instruktionen unterstützen (nicht signierter Beitrag von 84.148.56.122 (Diskussion | Beiträge) 14:24, 12. Feb. 2006 (CET)
thread_title:  Erste Korrekturen 

message: :Ich habe diese Sektion hierher verschoben:
Unterschiede zu den Hochsprachen
* Maschinensprachen bieten nur sehr einfache Befehle.
* Ein Programm kann nur auf genau dem Prozessor ablaufen, für dessen Maschinensprache es programmiert wurde. Diese Einschränkung ist weniger schwerwiegend als es zunächst scheint. 24-Bit-Code, der 1964 für ein IBM S/360 geschrieben wurde, läuft noch heute auf zSeries-Rechnern mit 64-Bit Architektur. 16-Bit-Code, der für den mittlerweile 25 Jahre alten 8086-Prozessor programmiert wurde oder 32-Bit-Code, der für 80386 programmiert wurde, ist auf heutigen Pentium-Rechnern lauffähig. Da die Intel-Mikroprozessor-Architektur einen sehr großen Marktanteil hat (auch andere Firmen wie AMD benutzen sie), und die IBM-Architektur den Mainframebereich dominiert, sind Maschinenspracheprogramme, die für diese Prozessoren geschrieben worden sind, sehr langlebig.
** Anmerkung: die Möglichkeit des Ausführens von Maschinensprache auf einer späteren CPU-Generation wird als Abwärtskompatibilität bezeichnet. Hierfür ist nicht der Verbreitungsgrad einer Architektur, sondern der Entwurf nachfolgender CPU-Generationen ausschlaggebend. Erreicht wird diese Abwärtskompatibilität, indem man entweder
::den Vorläufer-Prozessor in der neuen Prozessorarchitektur integriert und mit einem Befehl umschaltbar macht, oder
::einen Emulator als Microcode in den neuen Prozessor einbaut.
* Für die Ausführung von Maschinencode auf systemfremden (also ungeeigneten) Prozessoren existieren Emulatoren. Die Ausführung erfolgt interpretativ oder partiell kompilierend, mit grob 10facher Zeitdehnung.
Begründung des Verschiebens: Ein Hinweis auf den Gegensatz zwischen Maschinensprache und Hochsprachen befindet sich schon in der ersten Sektion. Auf den in Maschinensprachen zur Verfügung stehenden Befehlssatz wird in Befehlssatz bereits eingegangen. Der Rest ist praktisch ein Diskussionsthread auf der auf einen sehr kontroversen Satz hin folgt. Insofern passt die Besser auf eine Diskussionseite als in eine Enzykopädie. (nicht signierter Beitrag von 84.148.56.122 (Diskussion | Beiträge) 16:15, 12. Feb. 2006 (CET)
thread_title:  Sektion hierher verschoben 

message: Gerade der Absatz über den Befehlssatz setzt sehr viel Wissen voraus und ist für einen Laien extrem schwer lesbar. Fachbegriffe (z.B. Register, Flag) sind oft nicht verlinkt. Ein bisschen mehr Erklärung wäre schön.
--88.65.88.143 23:01, 1. Aug. 2011 (CEST)
replies: text: Habe versucht, hauptsächlich den ersten Absatz in diesem Abschnitt etwas verständlicher zu formulieren. Die jetzt veränderte Kapitelfolge könnte das Verständnis ebenfalls fördern. --VÖRBY 12:54, 3. Aug. 2011 (CEST)
thread_title:  Setzt sehr viel Wissen voraus 

message: seit den 1970er Jahren völlig außer Gebrauch gekommen? Das ist so nicht richtig. Zwar wurde davon, soweit stimmt meine Schätzung überein, seit den 70er-Jahren immer mehr Abstand genommen. Aber das „völlig außer Gebrauch“ ist definitiv falsch. Noch Mitte bis Ende der 80er-Jahre hatte ich mit Rechnern zu tun, die diskret aufgebaut waren und (evtl. sogar deshalb) u.a. mittels Punktmatrix-LED interne Register im laufenden Betrieb darstellen („wer ein schnelles Auge hat …“) konnten und mittels mehrer Tastenfelder bis ins letzte Detail beeinflußt werden konnten. Zwar war dies nicht die übliche Arbeitsweise. Aber zumindest für die Inbetriebnahme solcher Systeme (auch nach einem SW-Upgrade) war dieser Zugang damals, wenn auch kurz, noch zwingend nötig. Dies änderte sich erst, als auch der zentrale Rechnerkern immer mehr aus hochintegrierten Schaltungen, v.a. Mikroprozessoren, aufgebaut wurde – wahrscheinlich wurden einem solchen dabei (vorerst) die Aufgaben des alten Bedienpanels als eine Abart einer Terminal-Emulation übertragen.
Mir fehlt allerdings eine breitere Kenntnis dieser Thematik, so daß ich aus „seit den 1970er Jahren“ bestenfalls und möglicherweie ebenso fehlerhaft ein „bis Anfang der 1990er Jahre“ machen könnte. --87.163.79.172 (nicht mit einer Zeitangabe versehener Beitrag von 78.49.13.193 (Diskussion | Beiträge) 03:18, 24. Dez. 2007 (CET)
replies: text: Ich bin mir nicht sicher, wie Deine Anmerkung gemeint ist: So wie sie sich liest oder als zynische Bemerkung. Man sollte aber zwei Dinge unterscheiden: a) Die Maschinensprache als Code, der von den Prozessoren ausgeführt wird; so interpretiert ist MS nach wie vor aktuell. b) Das Programmieren in Maschinensprache dürfte tatsächlich 'in unserer modernen Zeitepoche' nahezu ausgestorben sein. Grüße von --VÖRBY 12:47, 11. Jan. 2012 (CET)
thread_title:  Direkte Eingabe der Binärcodes über eine Reihe von Schaltern … 

message: Die obige Diskussion über Weblinks (X86) führte bei mir zur Frage, welche Maschinensprachen es überhaupt gibt. Stichworte hierzu: (ggf. hier ergänzen). 
:*Welche gibt es? Sprachfamilien, Varianten/Dialekte; Entwicklungslinien (Vorgänger/Nachfolger, Schema ähnlich , ursprünglich bei Programmiersprache);  Zusammenhang zu Rechnerarchitekturen; ...
:*weitere Eigenschaften wie Adressierungsbreite; im Einsatz seit; noch im Einsatz? 'Hersteller' ...  
Hierzu würde ich mir Aussagen im Artikel wünschen, ähnlich wie das auch bei Sprache und gesprochene Sprache der Fall ist. Bin selbst hierzu leider kein Spezialist. Gibt es Freiwillige?--
VÖRBY (Diskussion) 08:39, 14. Jun. 2012 (CEST)
thread_title:  Sprachvarianten 

message: Auf dateilosen Systemen, wie beispielsweise [...] befindet sich das Maschinenprogramm oft unveränderbar im ROM
:Eigentlich hat das mit "dateilos" und "System" nicht unbedingt zu tun, und "unveränderbar" ist (Flash) auch nicht ganz treffend. Vorschlag, wenn man die µController nicht unbedingt erwähnen will: 
:„Teile des Maschinenprogramms (z.B. ein Bootloader) befinden sich oft permanent im ROM“
Ist nur ein Vorschlag --RobTorgel (Diskussion) 11:09, 24. Jan. 2013 (CET)
replies: text: Dieser Abschnitt wurde i.Z. mit dem Auflösen des Siehe-auch-Abschnitts geschaffen. Mein Vorschlag: "Bei vielen 'eingebetteten (embedded) Systemen' oder Mikrocontrollern befindet sich das Maschinenprogramm oder Teile davon, z. B. ein Bootloader meist permanent im ROM." --VÖRBY (Diskussion) 11:29, 24. Jan. 2013 (CET)
replies: text:  Änders doch einfach. Ich würde nur den Schwerpunkt jedoch nicht zu sehr auf PCs legen. 90% der Prozessoren (in denen Maschinenprogramme vorkommen) sind eingebettete Controller, allein 50 Stück im Auto, dann in Kaffeemaschinen, Fernsteuerungen, Handies, Rolladensteuerungen etc. Da wird das Programm in der Produktion eingebrannt und bleibt dann bis zum Elektroschrott unverändert. --Siehe-auch-Löscher (Diskussion) 11:34, 24. Jan. 2013 (CET)
replies: text: Gut, Ich hab Vörby Vorschlag aufgegriffen und geändert. @Siehe-auch-Löscher: Man sieht's dem Lemma nicht an, aber da steckt Pfeffer drin *g*. Ohne Disk ändere ich da nur Typos, ich will ja noch länger leben --RobTorgel (Diskussion) 11:54, 24. Jan. 2013 (CET)

text: "bleibt bis zum Elektroschrott unverändert" stimmt nicht so allgemein, bei vielen Geräten wie z.B. den meisten Handys, aber auch vielen Digitalkameras, Festplattenrekordern, blu-ray-Player, Fernsehern und vielen anderen Geräten ist ein Firmware-Update möglich, auch wenn natürlich nicht jeder Benutzer diese Möglichkeit nutzt. --MrBurns (Diskussion) 16:18, 24. Jan. 2013 (CET)
replies: text:  Das ist richtig. Meine Aussage war auch nicht allgemein, sondern bezog sich auf 90% Prozessoren. Der Prozentsatz ist geraten. Du kannst ja mal durchzählen wieviele Prozessoren Du in Deinem Hauhalt, Auto, Computer oder Skijacke findest, und bei wieviel Du die Firmware updaten kannst. So genau weiß ich auch nicht wo echte Maschinenprogramme ablaufen, also  Geldkarte, RFID, Autoschlüssel, Computermaus, Fahrradkilometerzähler. --Siehe-auch-Löscher (Diskussion) 17:07, 24. Jan. 2013 (CET)
replies: text: µC sind heutzutage in jeder Büroklammer. Aber: Die Hardware muss auch für In-Circuit-Programming ausgelegt sein --RobTorgel (Diskussion) 17:13, 24. Jan. 2013 (CET)
replies: text: (BK) Sehr einfache elektronische Geräte wie z.B. Autoschlüssel, Fernbedienuzngen, etc. sind oft "hard-wired", d.h. sie enthalten kein Programm im eigentlichen Sinn, sondern alle Funktionen sind allein durch den Aufbau der Hardware bestimmt. Daher statt nach dem Prinzip Eingabe-Algorithmus-Ausgabe ist jeder Eingabe schon durch die Hardware eine Ausgabe zugeordnet, Software und Firmware sind daher überflüssig und können auch nicht eingesetzt werden, da diese Geräte keinen Programmspeicher (bzw. in ganz einfachen Fällen so wie z.B. bei einer Fernbedienung, die hard-wired ist, garkeinen Speicher). "In-Ciruit-Programmierung" würde ich nicht als Programmierung im eigentlichen Sinne sehen, da eben die Funktion schon durch die Hardware vorgegeben ist und es daher kein Programm im eigentlichen Sinne gibt, sondern eben eine fixe Anordnung von elektronischen Elementen, auch wenn einige Arbeitsschritte in der Entwicklung dem Aufgabengebiet eines Programmierers entsprechen. --MrBurns (Diskussion) 17:24, 24. Jan. 2013 (CET)

text: Der Meinung bin ich auch, da man Elektronik, die hard-wired ist üblicherweise nicht als Prozessor bezeichnet. Die weit verbreitete Annahme, in jedem modernen elektronischen Gerät ist ein Prozessor, dürfte falsch sein. --MrBurns (Diskussion) 17:46, 24. Jan. 2013 (CET)
replies: text: Dann sind wir ja Eins. Btw: Das Laden eines Programms in einen Controller nennt man (leider) auch "programmieren", ist halt so, das sollte uns aber hier egal sein.  --RobTorgel (Diskussion) 19:17, 24. Jan. 2013 (CET)
replies: text: Ich hab mich mit hard-wired vorher eigentlich auf Controller bezogen, die eben garkein Programm im herkömmlichen Sinn gespeichert haben und auf die daher auch nichts geladen wird, sondern wo die Funktion vollständig durch die elektronischen Elemente ("Bauelemente") wie z.B. Transistoren bestimmt ist, auf die wird dann nichts geladen, sondern sie sind direkt anch der Fertigung einsetzbar. --MrBurns (Diskussion) 19:30, 24. Jan. 2013 (CET)
replies: text: Alles klar, hab ich auch so verstanden. --RobTorgel (Diskussion) 19:42, 24. Jan. 2013 (CET)
thread_title:  Abschnitt Maschinenprogramm 

message: ... im Bereich von Million, Milliarden, Trillionen bis 10 hoch 9999 
Es gibt in Skandinavien eine Eisenbahnstrecke mit geschätzt 2.000.000 Metern von Stockholm nach Narvik (Schweden/Norwegen). Auf dieser Strecke soll ein Eisenbahnzug (Passagiere und Ladung) jeden Meter mit 200 Kilometer pro Stunde zwischen Stockholm und Narvik Fahren. Bei diesem Zug wird also eine Informatik-Software benötigt, die bei jeden Meter Eisenbahngleis , die Daten hat, wo sich der Zug befindet und wie schnell der Zug fährt und um wieviele Kilometer pro Stunde (1000 Meter) der Zug gebremst wird. Das sind zirka 4 mal 2 Millionen mathematische Berechnungswerte in der Zugsoftware. Auf dieser 2.000.000 Meter Strecke eine Richtung fahren derzeit September 2017 bis zu 250 Loks pro Tag in eine Richtung. Theoretisch fahren alle 250 Loks (Autopilot) in einer Reihe auf 2 Millionen Metern. In Stockholm und in Narvik gibt es Halteplätze (250). Mit welcher Berechnungssoftware wird dieses Informatikproblem berechnet und auf Bildschirmen dargestellt (Wolfram Alpha, Bing, Google, Yandex, Baidu)? 195.35.101.1 16:46, 12. Sep. 2017 (CEST)
replies: text: Jedenfalls ist die Diskussionsseite von einem Artikel die falsche Stelle, um solche Fragen zu stellen. --MrBurns (Diskussion) 18:19, 12. Sep. 2017 (CEST)

text: Derartige permanent wiederkehrende Berechnungen und Überwachungen gibt es im Technischen Bereich zuhauf, etwa im Flugverkehr. Oder stelle Dir nur vor, was ein selbstfahrendes Auto (in Sekundenbruchteilen und praktisch 'gleichzeitig') berechnen muss. Das ist jedenfalls keine Frage zur Maschinensprache. Tipp: Versuche, das bei der skandinavischen Eisenbahn in Erfahrung zu bringen oder stelle die Frage ggf. in Wikipedia:Auskunft. Hier ERLEDIGT.--VÖRBY (Diskussion) 18:46, 12. Sep. 2017 (CEST)
thread_title:  Mathematische Berechnungen