Lt_Bri @2026-03-08 11:46:46

Któraś z rzędu na naszym rynku wydawniczym w ostatnich - powiedzmy - trzech dekadach, liczę że nie równie „sucha” jak poprzednie.
Od razu zaznaczam, nie oczekuję czegoś w klimatach Bidzińskiego czy innego J. D. Clark-a, ale poziom przynajmniej Horovitza i Hilla mile widziany ;)

Amigowiec @2026-03-08 12:35:15

Za dużo o x86 i protoplastach, a za mało o późniejszych MC68xxx. Autor widać nie miał Amigi czy ST, a z 8 bitów przeskoczył od razu na grzyba.

CISC @2026-03-08 15:13:13

a co tu dużo pisać o MC68xxx. początki były bardzo dobre, a później już coraz gorzej.

8-bitz @2026-03-08 18:11:41

Macie link do zoom ? Ten z qrcide cos mi nie bangla

Adam @2026-03-08 18:16:14

Link do zoom: https://us02web.zoom.us/j/83607078469?pw...

Zilog @2026-03-08 20:09:06

Za mało o Z80 a to najważniejszy z 8bitowych procków

6502 @2026-03-08 21:40:21

@Zilog: o nie, to ja jestem najważniejszy. :p

Kaz @2026-03-09 13:10:34

Nie wiem, czy najważniejszy jest 6502, ale autor przedstawił własny koncept wskaźnika efektywności architektury procesora i wskzuje on, że najbardziej efektywny jest 6502.

Amigowiec @2026-03-09 13:52:56

6502 inspirował ARM-y w BBC Micro, a te współczesne typu Cortex A72 w RPi to ich dalsze rozwinięcie. Czyli taki pistorm to poniekąd serce małego Atari/C-64 imitujące ultrawydajne MC68040.

Wiraż historii z którego wychodzi że 6502 faktycznie najważniejszy (jak dla mnie) i to nawet nie pół żartem pół serio.

6502 @2026-03-09 17:06:21

@Kaz: z ogromnym szacunkiem do Autora, wskaźniki, które przedstawił są delikatnie mówiąc ... z dupy.
Nie zmienia to jednak faktu, że i tak jestem najważniejszy. :)

Dociekliwy @2026-03-09 22:37:38

My, tutaj tak pierdu, pierdu, a tymczasem książki od dżordża o programowaniu Atari, Spectrum i innych, dalej nie ma.

Dupa @2026-03-09 23:40:44

@6502 To dobrze, że z dupy. Dupa pełni ważną funkcję! Powiedziałbym nawet, że jestem ważniejsza od 6502.

blasph @2026-03-10 00:09:08

zawsze she yakish palant znajdzie :)

blasph @2026-03-10 00:11:49

pała..hehe

Cyprian @2026-03-12 22:32:58

Dla tego kodu C:
[code]
volatile unsigned short *zrodlo = (unsigned short*) 0xff8240;
volatile unsigned short *cel = (unsigned short*) 0xff8250;

cel = zrodlo;
[/code]

GCC wypluło mi takiego potworka dla ARM:
[code]
movw r3, #33344
movt r3, 255
str r3, [r7, #12]
movw r3, #33360
movt r3, 255
str r3, [r7, #8]
ldr r3, [r7, #12]
str r3, [r7, #8]
[/code]


Dla Motoroli:
[code]
move.l $ff8240, $ff8250
[/code]


wiedziałem że architektura LOAD/STORE w ARM i PowerPC jest słaba, ale że aż tak?

ARM @2026-03-12 22:39:18

Może to nie architektura, a GCC jest tak słaby?

Cyprian @2026-03-13 15:09:42

ograniczenia wynikają z architektury LOAD/STORE.
Wymusza ona stosowanie wielu instrukcji dla nawet prostych operacji na pamięci.