Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.alt.folklore.computer > #49926 > unrolled thread
| Started by | Christian Weisgerber <naddy@mips.inka.de> |
|---|---|
| First post | 2025-05-11 21:36 +0000 |
| Last post | 2025-05-14 11:05 +0200 |
| Articles | 20 on this page of 118 — 16 participants |
Back to article view | Back to de.alt.folklore.computer
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Der erste Computer Christian Weisgerber <naddy@mips.inka.de> - 2025-05-11 21:36 +0000
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-12 09:48 +0200
Re: Der erste Computer Ignatios Souvatzis <u502sou@bnhb484.de> - 2025-05-12 08:34 +0000
Re: Der erste Computer Christian Corti <use@reply.to> - 2025-05-12 12:20 +0200
Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-05-12 13:08 +0200
Re: Der erste Computer Arno Welzel <usenet@arnowelzel.de> - 2025-05-17 09:05 +0200
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-17 10:16 +0200
Re: Der erste Computer Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2025-05-17 10:24 +0200
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-17 10:29 +0200
Re: Der erste Computer Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2025-05-17 10:31 +0200
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-17 13:32 +0200
Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-05-17 20:20 +0200
Re: Der erste Computer Andreas Bockelmann <xotzil@gmx.de> - 2025-05-18 09:42 +0200
Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-18 20:25 +0000
Re: Der erste Computer Andreas Bockelmann <xotzil@gmx.de> - 2025-05-19 08:22 +0200
Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-05-18 22:54 +0200
Re: Der erste Computer Arno Welzel <usenet@arnowelzel.de> - 2025-05-19 08:47 +0200
Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-19 18:14 +0200
Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-19 20:16 +0000
Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-19 22:50 +0200
Re: Der erste Computer Arno Welzel <usenet@arnowelzel.de> - 2025-05-24 12:57 +0200
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-24 16:26 +0200
Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-24 17:44 +0200
Re: Der erste Computer Arno Welzel <usenet@arnowelzel.de> - 2025-05-25 11:13 +0200
Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-24 17:14 +0200
Re: Der erste Computer Arno Welzel <usenet@arnowelzel.de> - 2025-05-25 11:15 +0200
Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-25 11:58 +0200
Re: Der erste Computer Arno Welzel <usenet@arnowelzel.de> - 2025-06-01 10:49 +0200
Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-05-25 01:09 +0200
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-20 12:11 +0200
Re: Der erste Computer Arno Welzel <usenet@arnowelzel.de> - 2025-05-24 12:55 +0200
Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-24 20:21 +0000
Re: Der erste Computer Arno Welzel <usenet@arnowelzel.de> - 2025-05-25 11:18 +0200
Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-25 14:23 +0000
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-25 16:49 +0200
Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-25 15:07 +0000
Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-25 21:20 +0200
Re: Der erste Computer Arno Welzel <usenet@arnowelzel.de> - 2025-06-01 10:54 +0200
Re: Der erste Computer Thomas Koenig <tkoenig@netcologne.de> - 2025-06-01 09:03 +0000
Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-01 14:03 +0200
Re: Der erste Computer Thomas Koenig <tkoenig@netcologne.de> - 2025-06-01 14:06 +0000
Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-01 16:34 +0200
Re: Der erste Computer Thomas Koenig <tkoenig@netcologne.de> - 2025-06-01 14:57 +0000
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-06-01 19:44 +0200
Re: Der erste Computer Arno Welzel <usenet@arnowelzel.de> - 2025-06-02 19:40 +0200
Re: Der erste Computer Thomas Koenig <tkoenig@netcologne.de> - 2025-06-02 18:01 +0000
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-06-01 17:03 +0200
Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-06-01 19:17 +0200
Re: Der erste Computer Thomas Koenig <tkoenig@netcologne.de> - 2025-05-29 14:14 +0000
Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-29 16:58 +0200
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-30 04:50 +0200
Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-05-25 15:40 +0200
Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-25 14:34 +0000
Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-05-25 22:07 +0200
Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-25 21:17 +0000
Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-25 21:40 +0000
Re: Der erste Computer Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-26 09:35 +0200
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-26 12:02 +0200
Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-05-26 13:31 +0200
Re: Der erste Computer Arno Welzel <usenet@arnowelzel.de> - 2025-06-01 10:58 +0200
Re: Der erste Computer Thomas Hochstein <thh@thh.name> - 2025-06-01 11:53 +0200
Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-06-01 15:06 +0200
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-06-01 17:13 +0200
Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-06-01 22:32 +0200
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-06-02 19:24 +0200
Re: Der erste Computer Arno Welzel <usenet@arnowelzel.de> - 2025-06-02 19:44 +0200
Re: Der erste Computer Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-26 00:00 +0200
Re: Der erste Computer tom nossen <news@nossen.org> - 2025-05-26 14:58 +0200
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-26 08:32 +0200
Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-05-26 13:32 +0200
Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-27 20:20 +0000
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-28 07:01 +0200
Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-28 19:45 +0000
Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-28 19:49 +0000
Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-08-11 21:22 +0000
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-08-12 09:57 +0200
Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-05-26 08:42 +0200
Re: Der erste Computer Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-25 23:52 +0200
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-26 08:38 +0200
Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-26 14:56 +0200
Re: Der erste Computer "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2025-05-26 13:28 +0000
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-26 16:03 +0200
Re: Der erste Computer "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2025-05-26 14:21 +0000
Re: Der erste Computer Thomas Koenig <tkoenig@netcologne.de> - 2025-05-29 19:27 +0000
Re: Der erste Computer Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-26 19:11 +0200
Re: Der erste Computer Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-26 19:05 +0200
Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-26 19:40 +0200
Re: Der erste Computer Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-26 20:18 +0200
Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-06-04 19:38 +0200
Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-05-27 14:09 +0200
Re: Der erste Computer Christian Corti <use@reply.to> - 2025-05-27 15:52 +0200
Re: Der erste Computer Thomas Koenig <tkoenig@netcologne.de> - 2025-05-29 18:55 +0000
Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-27 20:36 +0200
Re: Der erste Computer Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-27 20:49 +0200
Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-27 21:27 +0200
Re: Der erste Computer Thomas Koenig <tkoenig@netcologne.de> - 2025-05-29 19:34 +0000
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-26 08:29 +0200
Re: Der erste Computer Arno Welzel <usenet@arnowelzel.de> - 2025-05-24 12:55 +0200
Re: Der erste Computer Marc Haber <mh+usenetspam1118@zugschl.us> - 2025-05-24 13:11 +0200
Re: Der erste Computer Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2025-05-24 19:29 +0200
Re: Der erste Computer Arno Welzel <usenet@arnowelzel.de> - 2025-05-25 11:20 +0200
Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-05-25 22:09 +0200
Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-24 17:10 +0200
Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-24 18:23 +0200
Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-24 20:15 +0000
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-25 13:00 +0200
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-26 08:41 +0200
Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-05-25 22:30 +0200
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-26 08:50 +0200
Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-05-26 13:42 +0200
Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-26 15:01 +0200
Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-05-27 20:08 +0200
Re: Der erste Computer "Peter J. Holzer" <hjp-usenet4@hjp.at> - 2025-05-27 20:55 +0200
Re: Der erste Computer Kay Martinen <usenet@martinen.de> - 2025-05-28 02:21 +0200
Re: Der erste Computer Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-05-26 16:15 +0200
Re: Der erste Computer Christian Corti <use@reply.to> - 2025-05-12 12:31 +0200
Re: Der erste Computer Sebastian Barthel <naitsabes@freenet.de> - 2025-05-14 08:37 +0000
Re: Der erste Computer Christian Corti <use@reply.to> - 2025-05-14 11:05 +0200
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> |
|---|---|
| Date | 2025-05-26 13:28 +0000 |
| Message-ID | <m9j8k9Fs1s3U1@mid.individual.net> |
| In reply to | #50285 |
Peter J. Holzer <hjp-usenet4@hjp.at> wrote: >On 2025-05-25 23:52, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote: >> On 5/25/25 22:07, Kay Martinen wrote: >>> Ein CPU Register ohne Zugriff auf RAM könnte bestenfalls Konstante Werte >>> erhalten die im Programm selbst stehen oder eben Berechnungen die damit >>> oder aus I/O Registern kämen. >> >> So etwas gabs bei manchen frühen RISC CPUs. Ein Register welches fest >> auf 0 verdrahtet war. Gibts AFAIK nicht mehr in der Form. >Ist immer noch so. Bei den RISC-CPUs, die es seit damals gibt, ohnehin >(man will ja ABI-kompatibel bleiben), aber auch bei neueren. RISC-V >(2014) hat ebenfalls ein Zero-Register. Das ist einfach sehr praktisch. >>> Kurz: Ohne RAM taugt keine CPU zu irgend etwas sinnvollerem als >>> "Taschenrechner". >> >> Hm... Es gibt eine DCF-77 Uhr auf Z80-Basis, die ACS-77. Die hat zwar >> RAM, aber nur ein einziges 2114, also 1k x 4 womit man den Stack nicht >> benutzen kann und auch sonst ziemlich eingeschränkt ist. Als Uhr >> funktioniert sie aber trotzdem. >Ein einziger 2214 ist zwar nicht viel RAM, aber auch RAM. (wobei man >wohl etwas tricksen muss, um einen 8-Bit-Prozessor mit einem nur 4 Bit >breitem RAM zufriedenzustellen). Die Z80 CPU hat für einfache Ablaufsteuerungen genügend Register. Den 2114 wird man wohl zur Speicherung der Uhrzeit benutzt haben. Da reichen 4 Bit bei ungepacktem BDC Format. Die BCD Rotationsbefehle des Z80 arbeiten auch nur AFAIR auf dem niederwertigsten Nibble. Ich habe mir gerade den Schaltplan angeschaut. Mit einem zus. 2114 wäre die Schaltung IMO mit weniger ICs realisierbar, da man dann Stack für Unterprogramme und Interrupts hätte. -- Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2025-05-26 16:03 +0200 |
| Message-ID | <m9jaleFslp2U1@mid.individual.net> |
| In reply to | #50285 |
Am 26.05.25 um 14:56 schrieb Peter J. Holzer:
> Ein einziger 2214 ist zwar nicht viel RAM, aber auch RAM. (wobei man
> wohl etwas tricksen muss, um einen 8-Bit-Prozessor mit einem nur 4 Bit
> breitem RAM zufriedenzustellen).
Mit etwas Elektronik und Pufferung kann man 8 Bit Zugriffe
in 2 4 Bit zugriffe zerlegen.
Ein Adressbit wird dabei anderweitig verwendet.
( Adressbit sind beim verkabeln von RAM untereinander austauschbar,
ebenso Datenbits, wobei input und output sich entsprechen müssen)
Beim 8088 wurden ja auch 16 Bit Speicherzugriffe eines 8086
in 2 8 Bit Zugriffe zerlegt.
Bei ein Bit breiten RAM ( I2C ) werden Schieberegister benötigt.
--
<http://www.hermann-riemann.de>
[toc] | [prev] | [next] | [standalone]
| From | "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> |
|---|---|
| Date | 2025-05-26 14:21 +0000 |
| Message-ID | <m9jbmhFsopbU1@mid.individual.net> |
| In reply to | #50292 |
Hermann Riemann <nospam.ng@hermann-riemann.de> wrote: >Am 26.05.25 um 14:56 schrieb Peter J. Holzer: >> Ein einziger 2214 ist zwar nicht viel RAM, aber auch RAM. (wobei man >> wohl etwas tricksen muss, um einen 8-Bit-Prozessor mit einem nur 4 Bit >> breitem RAM zufriedenzustellen). >Mit etwas Elektronik und Pufferung kann man 8 Bit Zugriffe >in 2 4 Bit zugriffe zerlegen. Wobei die benötigte Ablaufsteuerung deutlich umfangreicher sein dürfte als ein zusätzliches 2114 RAM. >Ein Adressbit wird dabei anderweitig verwendet. >( Adressbit sind beim verkabeln von RAM untereinander austauschbar, > ebenso Datenbits, wobei input und output sich entsprechen müssen) >Beim 8088 wurden ja auch 16 Bit Speicherzugriffe eines 8086 >in 2 8 Bit Zugriffe zerlegt. Das kann die CPU aber von sich aus schon und generiert die passenden Steuersignale. -- Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-05-29 19:27 +0000 |
| Message-ID | <101acfa$kij$3@dont-email.me> |
| In reply to | #50296 |
Peter Heitzer <peter.heitzer@rz.uni-regensburg.de> schrieb: > Hermann Riemann <nospam.ng@hermann-riemann.de> wrote: >>Am 26.05.25 um 14:56 schrieb Peter J. Holzer: > >>> Ein einziger 2214 ist zwar nicht viel RAM, aber auch RAM. (wobei man >>> wohl etwas tricksen muss, um einen 8-Bit-Prozessor mit einem nur 4 Bit >>> breitem RAM zufriedenzustellen). > >>Mit etwas Elektronik und Pufferung kann man 8 Bit Zugriffe >>in 2 4 Bit zugriffe zerlegen. > > Wobei die benötigte Ablaufsteuerung deutlich umfangreicher sein > dürfte als ein zusätzliches 2114 RAM. Witzigerweise hat der Z80 eine 4-bit-ALU. Hatte ich erst vor recht kurzer Zeit gelernt: https://www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-how-it.html
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2025-05-26 19:11 +0200 |
| Message-ID | <1012565$682$3@news.bawue.net> |
| In reply to | #50292 |
On 5/26/25 16:03, Hermann Riemann wrote: > Am 26.05.25 um 14:56 schrieb Peter J. Holzer: > >> Ein einziger 2214 ist zwar nicht viel RAM, aber auch RAM. (wobei man >> wohl etwas tricksen muss, um einen 8-Bit-Prozessor mit einem nur 4 Bit >> breitem RAM zufriedenzustellen). > > Mit etwas Elektronik und Pufferung kann man 8 Bit Zugriffe > in 2 4 Bit zugriffe zerlegen. Wurde bei der ACS-77 aber nicht gemacht. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2025-05-26 19:05 +0200 |
| Message-ID | <10124s5$682$1@news.bawue.net> |
| In reply to | #50285 |
On 5/26/25 14:56, Peter J. Holzer wrote: > On 2025-05-25 23:52, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote: >> On 5/25/25 22:07, Kay Martinen wrote: >>> Ein CPU Register ohne Zugriff auf RAM könnte bestenfalls Konstante Werte >>> erhalten die im Programm selbst stehen oder eben Berechnungen die damit >>> oder aus I/O Registern kämen. >> >> So etwas gabs bei manchen frühen RISC CPUs. Ein Register welches fest >> auf 0 verdrahtet war. Gibts AFAIK nicht mehr in der Form. > > Ist immer noch so. Bei den RISC-CPUs, die es seit damals gibt, ohnehin > (man will ja ABI-kompatibel bleiben), aber auch bei neueren. RISC-V > (2014) hat ebenfalls ein Zero-Register. Das ist einfach sehr praktisch. Von der Implementierung auch simpel. Aber bringt das soviel? Man muss schliesslich in der Lage sein andere Werte in ein Register laden zu können. Dann geht das auch mit der Null. >>> Kurz: Ohne RAM taugt keine CPU zu irgend etwas sinnvollerem als >>> "Taschenrechner". >> >> Hm... Es gibt eine DCF-77 Uhr auf Z80-Basis, die ACS-77. Die hat zwar >> RAM, aber nur ein einziges 2114, also 1k x 4 womit man den Stack nicht >> benutzen kann und auch sonst ziemlich eingeschränkt ist. Als Uhr >> funktioniert sie aber trotzdem. > > Ein einziger 2214 ist zwar nicht viel RAM, aber auch RAM. (wobei man > wohl etwas tricksen muss, um einen 8-Bit-Prozessor mit einem nur 4 Bit > breitem RAM zufriedenzustellen). Da wurde allerdings nicht getrickst, das 2114 hängt an 4 Datenleitungen des Z80, da wird kein Versuch mit Multiplexing gemacht. Du hast eine 8 Bit CPU und 4 Bit breites RAM. Viel Spass. :) Gerrit
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2025-05-26 19:40 +0200 |
| Message-ID | <slrn10399sn.itcq.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #50297 |
On 2025-05-26 19:05, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
> On 5/26/25 14:56, Peter J. Holzer wrote:
>> On 2025-05-25 23:52, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
>>> On 5/25/25 22:07, Kay Martinen wrote:
>>>> Ein CPU Register ohne Zugriff auf RAM könnte bestenfalls Konstante Werte
>>>> erhalten die im Programm selbst stehen oder eben Berechnungen die damit
>>>> oder aus I/O Registern kämen.
>>>
>>> So etwas gabs bei manchen frühen RISC CPUs. Ein Register welches fest
>>> auf 0 verdrahtet war. Gibts AFAIK nicht mehr in der Form.
>>
>> Ist immer noch so. Bei den RISC-CPUs, die es seit damals gibt, ohnehin
>> (man will ja ABI-kompatibel bleiben), aber auch bei neueren. RISC-V
>> (2014) hat ebenfalls ein Zero-Register. Das ist einfach sehr praktisch.
>
> Von der Implementierung auch simpel. Aber bringt das soviel?
Offenbar genug, dass auch völlig neue Designs wie RISC-V nicht davon
abweichen.
> Man muss schliesslich in der Lage sein andere Werte in ein Register
> laden zu können. Dann geht das auch mit der Null.
Klar. Aber 0 braucht man eben oft. Natürlich könnte der Compiler die
entsprechenden Load-Befehle generieren. Aber vermutlich stellt sich dann
heraus, dass man ohnehin fast immer ein Register mit dem Wert 0 braucht
und daher jede Funktion mit »LD r0, #0« beginnt. Da kann man das auch
gleich hartverdrahten. Man verliert ein bisschen Flexibilität, aber ob
man 31 oder 32 "echte" Register hat, macht wohl keinen Unterschied.
>>>> Kurz: Ohne RAM taugt keine CPU zu irgend etwas sinnvollerem als
>>>> "Taschenrechner".
>>>
>>> Hm... Es gibt eine DCF-77 Uhr auf Z80-Basis, die ACS-77. Die hat zwar
>>> RAM, aber nur ein einziges 2114, also 1k x 4 womit man den Stack nicht
>>> benutzen kann und auch sonst ziemlich eingeschränkt ist. Als Uhr
>>> funktioniert sie aber trotzdem.
>>
>> Ein einziger 2214 ist zwar nicht viel RAM, aber auch RAM. (wobei man
>> wohl etwas tricksen muss, um einen 8-Bit-Prozessor mit einem nur 4 Bit
>> breitem RAM zufriedenzustellen).
>
> Da wurde allerdings nicht getrickst, das 2114 hängt an 4 Datenleitungen
> des Z80,
Und die anderen 4 sind vermutlich fix auf 0.
> da wird kein Versuch mit Multiplexing gemacht. Du hast eine 8
> Bit CPU und 4 Bit breites RAM. Viel Spass. :)
Geht, solange man nur Werte von 0 bis 15 speichern muss. Aber wie
geschrieben: Das ist RAM.
hjp
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2025-05-26 20:18 +0200 |
| Message-ID | <101294n$8mv$1@news.bawue.net> |
| In reply to | #50302 |
On 5/26/25 19:40, Peter J. Holzer wrote: > On 2025-05-26 19:05, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote: >> On 5/26/25 14:56, Peter J. Holzer wrote: >>> On 2025-05-25 23:52, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote: >>>> On 5/25/25 22:07, Kay Martinen wrote: >>>>> Ein CPU Register ohne Zugriff auf RAM könnte bestenfalls Konstante Werte >>>>> erhalten die im Programm selbst stehen oder eben Berechnungen die damit >>>>> oder aus I/O Registern kämen. >>>> >>>> So etwas gabs bei manchen frühen RISC CPUs. Ein Register welches fest >>>> auf 0 verdrahtet war. Gibts AFAIK nicht mehr in der Form. >>> >>> Ist immer noch so. Bei den RISC-CPUs, die es seit damals gibt, ohnehin >>> (man will ja ABI-kompatibel bleiben), aber auch bei neueren. RISC-V >>> (2014) hat ebenfalls ein Zero-Register. Das ist einfach sehr praktisch. >> >> Von der Implementierung auch simpel. Aber bringt das soviel? > > Offenbar genug, dass auch völlig neue Designs wie RISC-V nicht davon > abweichen. > >> Man muss schliesslich in der Lage sein andere Werte in ein Register >> laden zu können. Dann geht das auch mit der Null. > > Klar. Aber 0 braucht man eben oft. Natürlich könnte der Compiler die > entsprechenden Load-Befehle generieren. Aber vermutlich stellt sich dann > heraus, dass man ohnehin fast immer ein Register mit dem Wert 0 braucht > und daher jede Funktion mit »LD r0, #0« beginnt. Da kann man das auch > gleich hartverdrahten. Man verliert ein bisschen Flexibilität, aber ob > man 31 oder 32 "echte" Register hat, macht wohl keinen Unterschied. > >>>>> Kurz: Ohne RAM taugt keine CPU zu irgend etwas sinnvollerem als >>>>> "Taschenrechner". >>>> >>>> Hm... Es gibt eine DCF-77 Uhr auf Z80-Basis, die ACS-77. Die hat zwar >>>> RAM, aber nur ein einziges 2114, also 1k x 4 womit man den Stack nicht >>>> benutzen kann und auch sonst ziemlich eingeschränkt ist. Als Uhr >>>> funktioniert sie aber trotzdem. >>> >>> Ein einziger 2214 ist zwar nicht viel RAM, aber auch RAM. (wobei man >>> wohl etwas tricksen muss, um einen 8-Bit-Prozessor mit einem nur 4 Bit >>> breitem RAM zufriedenzustellen). >> >> Da wurde allerdings nicht getrickst, das 2114 hängt an 4 Datenleitungen >> des Z80, > > Und die anderen 4 sind vermutlich fix auf 0. Nein, schliesslich braucht man alle 8 Leitungen für das EPROM mit dem Steuerprogramm. Der Z80 liest also was auch immer auf den unbeschalteten Leitungen zu finden ist wenn er vom RAM liest: https://acs-77.yatho.de/Dokumente/Digitalteil.html Gerrit
[toc] | [prev] | [next] | [standalone]
| From | Kay Martinen <usenet@martinen.de> |
|---|---|
| Date | 2025-06-04 19:38 +0200 |
| Message-ID | <i2d6hl-9q4.ln1@news.martinen.de> |
| In reply to | #50302 |
Am 04.06.25 um 15:56 schrieb Stefan Ram: > "Peter J. Holzer" <hjp-usenet4@hjp.at> schrieb oder zitierte: >> heraus, dass man ohnehin fast immer ein Register mit dem Wert 0 braucht > > Hatte den Chatbot heute mal nach Ada Lovelaces Programmen gefragt, > ohne weiteren vorherigen Kontext. Er meinte: > > |Die Notation war eingeschränkt: Es waren nur Zwei-Glieder- > |Operationen erlaubt, komplexere Berechnungen mußten durch > |mehrere Schritte umgesetzt werden. Um beispielsweise eine > |Variable auf 2 zu setzen, hätte sie diese erst auf 0 gesetzt > |und dann in einem weiteren Schritt 2 addiert. Und in wie fern rechtfertigt dein "BestBuddy"-Bot damit ein Null-Register? > . Demnach wurde RISC schon recht früh erfunden! > :) Es heißt ja auch "No RISC, No Fun" falls man den Spaß am Gerät damit meint. Und Seit den Homecomputer-tagen ist ja die Herausforderung aus den Limitierten Ressourcen mehr heraus zu holen. Früher hatte man Klötzchengrafik, heute hat man eher Grafische Klötzchen. ;) F: Welche "Recheneinheit" hat die kleinste Befehlsmenge? A: Trump's Gehirn, das kennt nur NOP (in unendlicher Zahl) Man nennt ihn übrigens jetzt auch TACO-Man (Trump Always Chickens Out) habe ich gelesen... https://www.tagesschau.de/ausland/amerika/taco-man-trump-100.html Bye/ /Kay -- Posted via Leafnode
[toc] | [prev] | [next] | [standalone]
| From | Kay Martinen <usenet@martinen.de> |
|---|---|
| Date | 2025-05-27 14:09 +0200 |
| Message-ID | <comggl-gbt.ln1@news.martinen.de> |
| In reply to | #50285 |
Am 26.05.25 um 14:56 schrieb Peter J. Holzer: > On 2025-05-25 23:52, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote: >> On 5/25/25 22:07, Kay Martinen wrote: >>> Ein CPU Register ohne Zugriff auf RAM könnte bestenfalls Konstante Werte >>> erhalten die im Programm selbst stehen oder eben Berechnungen die damit >>> oder aus I/O Registern kämen. >> >> So etwas gabs bei manchen frühen RISC CPUs. Ein Register welches fest >> auf 0 verdrahtet war. Gibts AFAIK nicht mehr in der Form. > > Ist immer noch so. Bei den RISC-CPUs, die es seit damals gibt, ohnehin > (man will ja ABI-kompatibel bleiben), aber auch bei neueren. RISC-V > (2014) hat ebenfalls ein Zero-Register. Das ist einfach sehr praktisch. Wozu genau und was soll es? Extra Befehle um aus dem Zero-Register in ein anderes zu laden oder damit zu vergleichen würden von 'R' in RISC weg führen. Und vermutlich könnte man das mit den bekannten Befehlen auch (Laden von dort, speichern in XYZ). Ein laden von "Null" in ein Register kann man doch auch mit einer direkt angegebenen Konstante im Code machen. Dann steht das da dort wenigstens direkt drin was es macht. Also ich sehe nicht was an einem "Register" das nur Nullen lieferte praktisch sein sollte. Bye/ /Kay -- Posted via Leafnode
[toc] | [prev] | [next] | [standalone]
| From | Christian Corti <use@reply.to> |
|---|---|
| Date | 2025-05-27 15:52 +0200 |
| Message-ID | <mmsggl-me2.ln1@news.informatik.uni-stuttgart.de> |
| In reply to | #50311 |
Kay Martinen <usenet@martinen.de> wrote: > Ein laden von "Null" in ein Register kann man doch auch mit einer direkt > angegebenen Konstante im Code machen. Dann steht das da dort wenigstens > direkt drin was es macht. > Also ich sehe nicht was an einem "Register" das nur Nullen lieferte > praktisch sein sollte. Ganz einfach: man kann dadurch Befehle in der CPU sparen. Beispiel: es gibt nur Arithmetikbefehle und keine extra Transportbefehle. Also statt "MOV R2, R1" hieße es dann "ADD R2, R0, R1". Des weiteren sind Konstanten in Opcodes auch immer etwas problematisch (Stichwort Symmetrie des Befehlssatzes). Daher gibt es zwar schon Konstantenladebefehle, aber Arithmetik geht z.B. nur über (mehrere) Register. Vereinfacht die CPU nochmals wesentlich. Christian
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-05-29 18:55 +0000 |
| Message-ID | <101aajg$kij$1@dont-email.me> |
| In reply to | #50312 |
Christian Corti <use@reply.to> schrieb: > Kay Martinen <usenet@martinen.de> wrote: >> Ein laden von "Null" in ein Register kann man doch auch mit einer direkt >> angegebenen Konstante im Code machen. Dann steht das da dort wenigstens >> direkt drin was es macht. >> Also ich sehe nicht was an einem "Register" das nur Nullen lieferte >> praktisch sein sollte. > > Ganz einfach: man kann dadurch Befehle in der CPU sparen. > Beispiel: es gibt nur Arithmetikbefehle und keine extra > Transportbefehle. Also statt "MOV R2, R1" hieße es dann "ADD R2, R0, R1". OR braucht normalerweise weniger Energie :-) Und "OR R2,R1,R1" geht als alias für "MOV R2, R1" genauso. Und laden von 0 in einem Register wäre dann "XOR R2,R2,R2". > Des weiteren sind Konstanten in Opcodes auch immer etwas problematisch > (Stichwort Symmetrie des Befehlssatzes). Daher gibt es zwar schon > Konstantenladebefehle, aber Arithmetik geht z.B. nur über (mehrere) > Register. Vereinfacht die CPU nochmals wesentlich. Kann man so machen, aber m.E. ist das Verschwendung eines Registers (und die sind fast immer knapp, spill/restore kostet..) IBM hat bei der /360 vorgemacht, wie sowas aussehen kann: Ein base register 0 oder ein index register 0 verwendet bei der Berechnung einer Speicheradresse den Wert 0, ansonsten ist 0 ein vollwertiges Register. POWER verwendet das auch. Und das kostet nicht wirklich viele Logikgatter; das ist ja dann auf die AGEN (address generation) beschränkt.
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2025-05-27 20:36 +0200 |
| Message-ID | <slrn103c1hg.1nmm4.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #50311 |
On 2025-05-27 14:09, Kay Martinen <usenet@martinen.de> wrote:
> Am 26.05.25 um 14:56 schrieb Peter J. Holzer:
>> On 2025-05-25 23:52, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
>>> On 5/25/25 22:07, Kay Martinen wrote:
>>>> Ein CPU Register ohne Zugriff auf RAM könnte bestenfalls Konstante Werte
>>>> erhalten die im Programm selbst stehen oder eben Berechnungen die damit
>>>> oder aus I/O Registern kämen.
>>>
>>> So etwas gabs bei manchen frühen RISC CPUs. Ein Register welches fest
>>> auf 0 verdrahtet war. Gibts AFAIK nicht mehr in der Form.
>>
>> Ist immer noch so. Bei den RISC-CPUs, die es seit damals gibt, ohnehin
>> (man will ja ABI-kompatibel bleiben), aber auch bei neueren. RISC-V
>> (2014) hat ebenfalls ein Zero-Register. Das ist einfach sehr praktisch.
>
> Wozu genau und was soll es?
Der Wert 0 kommt in Programmen sehr oft vor. Da werden dauernd Variablen
mit 0 initialisiert, mit 0 verglichen, etc.
Natürlich kann man ein Register mit einer einzelnen Instruktion auf 0
setzen (ob das jetzt ein Load Immediate ist oder eine arithmetische
Operation wie Sub oder XOr). Aber mit einem Register, das immer den Wert
0 hat, spart man sich das. Bringt das in der Praxis was? Kann ich nicht
sagen, aber das Buch von Hennessy und Patterson trägt nicht umsonst den
Untertitel "A Quantitative Approach". Die haben exzessiv Programmcode
analysiert, um herauszufinden, was gebraucht wird und was weggelassen
werden kann. Wenn die der Meinung waren, dass es sinnvoll ist, ein
Register (von 32) zu "opfern" und fix auf den Wert 0 zu setzen, dann
hatten sie Statistiken, um das zu belegen. Jetzt kann man natürlich
sagen, das war vor 40 Jahren, heute ist alles ganz anders. Kann sein,
aber RISC-V ist erst 10 Jahre alt und macht das gleiche. Und ich glaube,
die machen das nicht aus reiner Nostalgie.
> Extra Befehle um aus dem Zero-Register in ein anderes zu laden oder
> damit zu vergleichen würden von 'R' in RISC weg führen.
Es sind keine extra Befehle. Es sind die ganz normalen Befehle, die ganz
genau das gleiche machen wie für die anderen 31 Register. Nur dass halt
das Zero-Register immer den Wert 0 enthält.
hjp
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2025-05-27 20:49 +0200 |
| Message-ID | <1014vak$qlh$1@news.bawue.net> |
| In reply to | #50318 |
On 5/27/25 20:36, Peter J. Holzer wrote: > On 2025-05-27 14:09, Kay Martinen <usenet@martinen.de> wrote: >> Am 26.05.25 um 14:56 schrieb Peter J. Holzer: >>> On 2025-05-25 23:52, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote: >>>> On 5/25/25 22:07, Kay Martinen wrote: >>>>> Ein CPU Register ohne Zugriff auf RAM könnte bestenfalls Konstante Werte >>>>> erhalten die im Programm selbst stehen oder eben Berechnungen die damit >>>>> oder aus I/O Registern kämen. >>>> >>>> So etwas gabs bei manchen frühen RISC CPUs. Ein Register welches fest >>>> auf 0 verdrahtet war. Gibts AFAIK nicht mehr in der Form. >>> >>> Ist immer noch so. Bei den RISC-CPUs, die es seit damals gibt, ohnehin >>> (man will ja ABI-kompatibel bleiben), aber auch bei neueren. RISC-V >>> (2014) hat ebenfalls ein Zero-Register. Das ist einfach sehr praktisch. >> >> Wozu genau und was soll es? > > Der Wert 0 kommt in Programmen sehr oft vor. Da werden dauernd Variablen > mit 0 initialisiert, mit 0 verglichen, etc. > > Natürlich kann man ein Register mit einer einzelnen Instruktion auf 0 > setzen (ob das jetzt ein Load Immediate ist oder eine arithmetische > Operation wie Sub oder XOr). Ob nun ein XOR R1,R1 mehr Aufwand macht als ein MOV R0,R1 müsste man checken. Sollte vom Zyklenaufwand her dasselbe sein. Beim 6502 brauchen LDA #$xx und EOR #$xx beide 2 Zyklen. Ebenso ein AND #$00 > Kann sein, > aber RISC-V ist erst 10 Jahre alt und macht das gleiche. Und ich glaube, > die machen das nicht aus reiner Nostalgie. 'Das haben wir (bei RISC) schon immer so gemacht!' kann auch hier passieren. Gerrit
[toc] | [prev] | [next] | [standalone]
| From | "Peter J. Holzer" <hjp-usenet4@hjp.at> |
|---|---|
| Date | 2025-05-27 21:27 +0200 |
| Message-ID | <slrn103c4ga.1q9m4.hjp-usenet4@trintignant.hjp.at> |
| In reply to | #50319 |
On 2025-05-27 20:49, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
> On 5/27/25 20:36, Peter J. Holzer wrote:
>> On 2025-05-27 14:09, Kay Martinen <usenet@martinen.de> wrote:
>>> Am 26.05.25 um 14:56 schrieb Peter J. Holzer:
>>>> On 2025-05-25 23:52, Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
>>>>> So etwas gabs bei manchen frühen RISC CPUs. Ein Register welches fest
>>>>> auf 0 verdrahtet war. Gibts AFAIK nicht mehr in der Form.
>>>>
>>>> Ist immer noch so. Bei den RISC-CPUs, die es seit damals gibt, ohnehin
>>>> (man will ja ABI-kompatibel bleiben), aber auch bei neueren. RISC-V
>>>> (2014) hat ebenfalls ein Zero-Register. Das ist einfach sehr praktisch.
>>>
>>> Wozu genau und was soll es?
>>
>> Der Wert 0 kommt in Programmen sehr oft vor. Da werden dauernd Variablen
>> mit 0 initialisiert, mit 0 verglichen, etc.
>>
>> Natürlich kann man ein Register mit einer einzelnen Instruktion auf 0
>> setzen (ob das jetzt ein Load Immediate ist oder eine arithmetische
>> Operation wie Sub oder XOr).
>
> Ob nun ein XOR R1,R1 mehr Aufwand macht als ein MOV R0,R1 müsste man
> checken.
Nein, das ist exakt gleich (bei einer klassischen nicht-superskalaren
RISC-Architektur, wie sie in den 80er-Jahren eben entworfen wurden).
Aber
bgt $5, $0, label
ist weniger Aufwand als
xor $17, $17, $17
bgt $5, $17, label
(eine Instruktion vs. zwei)
hjp
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-05-29 19:34 +0000 |
| Message-ID | <101acss$kij$4@dont-email.me> |
| In reply to | #50318 |
Peter J. Holzer <hjp-usenet4@hjp.at> schrieb: > Natürlich kann man ein Register mit einer einzelnen Instruktion auf 0 > setzen (ob das jetzt ein Load Immediate ist oder eine arithmetische > Operation wie Sub oder XOr). Aber mit einem Register, das immer den Wert > 0 hat, spart man sich das. Bringt das in der Praxis was? Kann ich nicht > sagen, aber das Buch von Hennessy und Patterson trägt nicht umsonst den > Untertitel "A Quantitative Approach". Die haben exzessiv Programmcode > analysiert, um herauszufinden, was gebraucht wird und was weggelassen > werden kann. Wenn die der Meinung waren, dass es sinnvoll ist, ein > Register (von 32) zu "opfern" und fix auf den Wert 0 zu setzen, dann > hatten sie Statistiken, um das zu belegen. Jetzt kann man natürlich > sagen, das war vor 40 Jahren, heute ist alles ganz anders. Kann sein, > aber RISC-V ist erst 10 Jahre alt und macht das gleiche. Und ich glaube, > die machen das nicht aus reiner Nostalgie. RISC-V hat eine Menge schlechter Entscheidungen getroffen, das ist eine davon. Aber eine 0 als Konstante geht ja auch in dem Befehlsformat, in dem ein ein Register und eine n-Bit-Konstante verwurstet werden. Bei RISC-V sind das 12 bit, bei POWER oder MIPS z.B. 16.
[toc] | [prev] | [next] | [standalone]
| From | Hermann Riemann <nospam.ng@hermann-riemann.de> |
|---|---|
| Date | 2025-05-26 08:29 +0200 |
| Message-ID | <m9ig1vFoj4mU1@mid.individual.net> |
| In reply to | #50249 |
Am 25.05.25 um 22:07 schrieb Kay Martinen: > Am 25.05.25 um 16:34 schrieb Sebastian Barthel: >> An einem Sun, 25 May 2025 15:40:40 +0200 schrieb der Meister Kay >> Martinen: >> >>> Am 24.05.25 um 22:21 schrieb Sebastian Barthel: > >>>> Aber trotzdem sieht man doch daran auch, daß es da sogar auf der >>>> untersten Ebene eine tatsächliche Trennung gibt, was nun ein Datum und >>>> was ein Befehl ist. >>> >>> Nöh, Auf der Untersten Ebene liegt m.E. der Speicher, das RAM. Da gibt >>> es bei den meisten Systemen keine Faktische Trennung zwischen Daten und >>> Programmcode wenn man den als Linearen Bereich durch ginge. > >> Ich z.B. würde RAM nicht als unterste Ebene ansehen. Unterste Ebene wären >> evtl sowas wie die CPU Register bzw. der "Core" der CPU. >> RAM ist halt nur sowas wie externer Speicher - halt bißchen schneller. > > Ein CPU Register ohne Zugriff auf RAM könnte bestenfalls Konstante Werte > erhalten die im Programm selbst stehen oder eben Berechnungen die damit > oder aus I/O Registern kämen. Welches RAM? Den cache? Bei 16 MB cache könnte ich mir einen 286 ohne externes RAM vorstellen auf dem DOS läuft. Und dann gibt oder gab es noch MMUs die Speicherbereiche auf HD haben. > Eine 6502 würde so z.b. überhaupt nicht arbeiten können weil sie zugriff > auf den unteren RAM-bereich braucht für Zeropage und Stack und auf die > obersten Adressen für den Restvektor - der dann zum Startpunkt des > Programms führt. Warum nicht gleich den 9900 von Texas Instrument? > Kurz: Ohne RAM taugt keine CPU zu irgend etwas sinnvollerem als > "Taschenrechner". Die meisten computer ( Mikrokontroller ) haben kein externes RAM. > Wenn du nur die Bitmuster als nullen und einsen sehen kannst brauchst du > aber erfahrung und ein Gutes Auge um den Unterschied zu erkennen. Hex Darstellung oder einzel LEDs > Und statistik mit entsprechenden Programmen (wie z.b. ein Disassembler) > hatte ich dabei definitiv nicht mit einbezogen. Weil man dafür wieder > ein "Programm" bräuchte. ;) Ich kann mir vorstellen ein 6116 ( 2 kB RAM ) mit eine hardware Adapter auch ohne "Programm" lesen zu können. > Selbst modifizierender Code ist nichts neues. Aber Code der sich selbst > als Daten nimmt dürfte in der Tat nur in seltensten Fällen irgend einen > Sinn machen. Wenn das Ergebnis undefiniert ist könnte man den Code noch > als Random-Input her nehmen. Ich habe selber sowohl beruflich als auch privat code Bereiche in andere Speicherbereiche verschoben und deren reale ( nicht relative ) Adressen automatisch angepasst. >>> Würde man abseits der CPU und ohne ihre Kenntnisse darüber einen >>> beliebigen Bereich lesen könnte man m.E. nicht wissen ob das Code oder >>> Daten sind. >> >> Wissen vielleicht nicht, aber gut genug abschätzen, wird wohl gehen. >> Auftretenswahscheinlichkeiten von häufigen Befehlen zählen oder sowas, >> bringt da bestimmt was. > > Wenn man quasi nur einen Binären Dump des Speicherinhaltes sehen kann > dann mag man noch unterscheiden können zwischen inhalten die z.b. für > einen Zeichengenerator sind, vielleicht auch noch was Daten sein könnten > und was möglicherweise Code sein wird. Wenn man hexcode und ASCII etc kennt, kann man schon schätzen. bytes >0x080 ist kein ASCII Text. und wenn in hex viele Nullen oder 0xFF drin sind, sieht das nach Binärdaten aus. > Aber ohne Disassembler, Hexviewer > o.ä. kann einen das auch in die Irre führen. Und, man muß natürlich > wissen welche CPU das lesen soll. Sonst liefert ein Disassembler auch > nur müll. Es gibt da unterschiedliche. Selbst bei code kann es Problem geben, wenn die Anfangsadresse nicht stimmt, Oder bei einem alten Debugger von Siemens bei Dezimalbefehle Daten mit (4 Bit) Nibbles Werte >9 haben.
[toc] | [prev] | [next] | [standalone]
| From | Arno Welzel <usenet@arnowelzel.de> |
|---|---|
| Date | 2025-05-24 12:55 +0200 |
| Message-ID | <m9dms4Fud0sU2@mid.individual.net> |
| In reply to | #50038 |
Peter J. Holzer, 2025-05-19 18:14: > On 2025-05-19 08:47, Arno Welzel <usenet@arnowelzel.de> wrote: >> Kay Martinen, 2025-05-18 22:54: >>> Am 18.05.25 um 09:42 schrieb Andreas Bockelmann: >>>> Hermann Riemann schrieb: >>>>> Am 17.05.25 um 09:05 schrieb Arno Welzel: >>>> >>>>>> Ein Abakus war programmierbar? >>>>> >>>>> Daten sind Programme. >>> >>> Echt? In welcher CPU, APU, GPU o.a. sind Programme keine Programme mehr >>> sondern Daten die Programme? Ah, ich weiß. Im Crowdstrike-universum das >>> uns einen Weitreichenden Schlangenöl-basierten IT-Ausfall bescherte. ;) >> >> Getrennte Speicher für Programmcode und Daten sind schon lange nicht >> mehr üblich. Das gleiche RAM, was für Daten verwendet wird, wird ebenso >> für den Programmcode genutzt. So gesehen stimmt die Aussage "Daten sind >> Programme" durchaus. > > Nein. > > Programme sind Daten. Aber Daten nicht (notwendigerweise) Programme. Es hat ja auch niemand behauptet, dass Daten *immer* auch Programme sind. Aber Programmbefehle sind halt Daten und nichts anderes. -- Arno Welzel https://arnowelzel.de
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+usenetspam1118@zugschl.us> |
|---|---|
| Date | 2025-05-24 13:11 +0200 |
| Message-ID | <100s9hp$nbcs$1@news1.tnib.de> |
| In reply to | #50176 |
Arno Welzel <usenet@arnowelzel.de> wrote: >Es hat ja auch niemand behauptet, dass Daten *immer* auch Programme >sind. Aber Programmbefehle sind halt Daten und nichts anderes. Nicht alles ist ein Von-Neumann-Rechner. -- ---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
[toc] | [prev] | [next] | [standalone]
| From | Gerrit Heitsch <gerrit@laosinh.s.bawue.de> |
|---|---|
| Date | 2025-05-24 19:29 +0200 |
| Message-ID | <100stg1$469$3@news.bawue.net> |
| In reply to | #50180 |
On 5/24/25 13:11, Marc Haber wrote: > Arno Welzel <usenet@arnowelzel.de> wrote: >> Es hat ja auch niemand behauptet, dass Daten *immer* auch Programme >> sind. Aber Programmbefehle sind halt Daten und nichts anderes. > > Nicht alles ist ein Von-Neumann-Rechner. Die, die es nicht sein, sind nur noch Nischensysteme. Und auch bei denen sind Programme erst einmal Daten wenn sie vom Massenspeicher geladen werden. Gerrit
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | de.alt.folklore.computer
csiph-web