Názor k článku Stavíme ochranu paralelního portu od Ondrej 'SanTiago' Zajicek - Navíc si uvědom dobu vzniku: SPP parport byl...

Navíc si uvědom dobu vzniku: SPP parport byl navržen v době, kdy 8086 procesor měl cca 20k tranzistorů.

To ja si uvedomuju. V dobe 8086 to byl rozumny design. Ale v devadesatych letech uz to bylo beznadejne zastarale, natozpak dnes.

A i když bude udělán HW, stejně zpožďuje přenos dat,

Ano, ale jak to tam udelat lepe, kdyz tam je halfduplexni sbernice? Bud by bylo treba mit vyhrazene draty na bus arbitration ci intrerrupt, nebo pouzit nejakou obdobu CSMA (coz by samo asi prineslo vic problemu, nez kolik by to resilo). Idealni by bylo, kdyby USB byl fullduplexni a hub by fungoval stejne jako ethernet switch, ale pak by bylo treba mit 6 dratu misto 4.

Počítej se mnou: stránka A4 v grafickém čb módu a rozlišení 600 DPI má necelých 5 MB informace. K přenesení jednoho bytu SPP portem potřebuješ 10–15 instrukcí. Tedy na přenesení této stránky potřebuješ pouhých max 75M instrukcí. To je v době gigaherthových procesorů méně než 100 ms strojového času na přenos stránky.

Jenze tenhle vypocet je nesmyslny – zanedbava tri dulezite veci:

1. granularita – udelat 10k instrukci 100* za sekundu bude z mnoha duvodu pro system vyrazne mensi zatez nez udelat 10 instrukci 100k* za sekundu.
2. in/out instrukce netrvaji takt, ale trvaji tak dlouho, nez dany hardware acknowledguje danou operaci. Coz vcelku nezavisi na frekvenci procesoru – cim rychlejsi procesor, tim vic taktu takova instrukce bude trvat. A bude to odhadem minimalne radove tisice (a spis jeste vic) taktu na jeden out. V tomhle ma vyhodu MMIO, ale bezne radice paralelniho portu MMIO nepodporuji.
3. Nejspis bude treba mezi nekteryma IN/OUT instrukcema mit nejake explicitni cekani, to bude nejspis prilis kratke na to, aby behem toho melo smysl schedulovat nejaky proces. Takze se pri tom i spousta casu nevyuzitelne proflaka.