Mateusz Viste <m...@n...pamietam> wrote:

> Wydajność to jeden z powodów. Subsystem FILE różnie jest implementowany w
> różnych kompilatorach, i odczyty nie zawsze są buforowane, a DOSMid czyta
> dużo rzeczy bajt po bajcie. Bez read-ahead takie czytanie z dyskietki
> może trwać wieczność.

No tak, widzę że masz cache. Tylko 32 bajty, ale pewnie starcza.

Btw, w wielu miejscach widzę tuż przed końcem funkcji komentarz:

/* */

W zbyt wielu, żeby to był przypadek :) Czemu tak?

Przeglądam dalej. Dorzuć break w fio_seek w case FIO_SEEK_END (linia 57).
Widzę też nadmiarowy break (bo po return) w MUS.C w linii 162 :)

> Drugi powód to rozmiar kodu. Mój fio.o jest mniejszy od tego co zaciąga
> np. OpenWatcom przy użyciu FILE. Oczywiście wcale nie dlatego, że mój kod
> jakoś lepszy - tylko robi po prostu tylko to, czego potrzebuje DOSMid i
> nic poza tym.

Jasne, to wiadomo.

> Faktycznie - masz dobre oko. W sumie te wszystkie include guardy w tym
> projekcie to trochę sztuka dla sztuki.

Tak... jeśli include'y się nie dublują, to tak. Zresztą gdyby, to by od
razu wyszło przy kompilacji.

Chyba, że chciałbyś kiedyś zrobić unity build :) Sam nie jestem jego
fanem, ale kiedyś zrobiłem kilka testów i kod na AVR po zrobieniu unity
wychodził odrobinę mniejszy (kwestia pojedynczych bajtów).

>> Rzucił mi się jeszcze w oczy brak nawiasów w MPU_DATA i MPU_STAT w
>> mpu.c ale widzę, jak są używane, więc można się kłócić :)
>
> Ano, kłócić można się zawsze, o wszystko. Niewątpliwie wszystkie twoje
> uwagi są słuszne w jakimkolwiek kilku-osobowym projekcie. DOSMid
> natomiast to jedno-osobowa zabawka - no i autor wie co robi. :)

Wiem, dlatego mówię, że to na siłę ;)

> W międzyczasie zawsze możesz potestować na DOSBoxie - ma on bardzo udane
> wsparcie dla GUSa, odgrywanie MIDI brzmi zaskakująco dobrze.

Zerknę :)

A nie wiesz może, jak to wygląda w drugą stronę? Zastanawiam się, na ile
łatwo da się przesłać do DOSBoxa zdarzenia midi z zewnętrznego kontrolera
i użyć DOS-owego sequencera.

> Domniemywam, że za dnia robisz (lub sprawdzasz) kod w jakimś korpo, i
> stąd pewnie lekkie zboczenie :)

Za dnia tak, ale to nie wygląda tak kolorowo. Kod, z którym teraz przyszło
mi pracować, jest pisany przez bardzo tanich Hindusów i ma jakość
adekwatną do ceny. Tam już się nawet niczego nie czepiam, bo po pierwsze
byłoby tego za dużo, a po drugie wszyscy i tak jakość mają bardzo głęboko.
Ma jakoś działać i tyle.

Pracuje ze mną jeszcze jedna osoba z grupy (nie wiem, czy chce się
ujawnić), ale ma już dosyć i się zwalnia -- i patrząc na to wszystko
nie dziwię się. Ja się chyba za bardzo zasiedziałem. Albo cały czas
mam nadzieję, że to wszystko jest tylko tymczasowe.

Mam kilka swoich projektów w pracy, ale one są już zrobione, gotowe,
przetestowane, działają, niewiele jest już tam do roboty. No i one były
w większości pisane jednoosobowo. Dlatego rzucili nas do sprzątania tego
hinduskiego syfu.

Hobbystycznie też piszę, ale od dawna nie publikuję. Na chmurce są jakieś
(bardzo) stare rzeczy, którymi niekoniecznie chciałbym się chwalić ;)
Przyjdzie moment, gdy założę kanał na yt z różnymi moimi DIY-rzeczami, bo
trochę się tego nagromadziło, i wtedy poudostępniam kody, schematy itd.

> - kod hobbystyczny często odbiega od "standardów" korpo.

W moim korpo odbiega, ale bardzo na plus.

> Swoją drogą, jeśli naprawdę chcesz się przerazić, to
> zajrzyj tutaj (byle nie za długo, bo to wielce niezdrowe):
> https://sourceforge.net/p/etherdfs/code/HEAD/tree/et
herdfs/trunk/
> etherdfs.c

Nie jest źle. Kod jest okomentowany, można się w nim odnaleźć. A że więcej
assemblera niż C... może użycie C jako zestawu makr dla assemblera to w
niektórych zastosowaniach nie taki zły pomysł :)

To, co mnie przeraża, to np.:

https://github.com/Distrotech/procmail/blob/master/s
rc/goodies.c
https://www.compression.ru/ds/ppmdj1.rar (w sumie wszystkie pliki)

Czyli kod, w którym bardzo trudno jest się odnaleźć i zrozumieć jego
działanie.

Trzy firmy temu (MkS / ArcaBit) mieliśmy też emulator x86 z mks_vira,
napisany najpierw w assemblerze, a później przepisany do C++, ale w
assemblerowym stylu (np. cztery zmienne globalne: ax, bx, cx, dx).
Kod miał ok. 600 kB. Odnalezienie się w nim graniczyło z cudem.

--
https://www.youtube.com/watch?v=9lSzL1DqQn0