Grzegorz Malicki programista
sabunia portal
| O to widzę, że świat kolegi zamyka się nawet nie na procesorach zgodnych z
| intelem, a tylko na Windowsach. Otoż mylisz się. Nie zawssze bajty są
| zapisywane w odwrotnej kolejności. Na przykład na maszynach z procesorami
| MC680x0 albo PowerPC albo jeszcze wieloma innymi (na przykład rodzinka
| Alpha, o ile jest włączony BigEndian).
Hm. Tak troche sie pomylilem. Tzn, bledem bylo napisanie tego o windzie
Z drugiej strony troche sie zle zrozumielismy.
Ja zalozylem, ze srodowisko sie nie zmieni, tylko zmieni sie kompilator. A
zmiana kompilatora nie powinna pociagac za soba problemow w odczytywaniu
plikow, o ile beda one produkowaly ten sam badz rownoznaczny kod maszynowy.
Grzegorz Malicki pare postow niezej:
| 1. sizeof(int) czasem jest 2, a czasem 4 róznie to bywa :-)
| Wiec write(&r,sizeof(r)) moze zapisac dwa lub cztery bajty
Pilnowanie rozmiarow pol nalezu juz do programisty. Jak ktos nie wie co
zapisuje/odczytuje to juz jego problem.
Podsumowujac: Moj blad :/
pozdrawiam
Użytkownik "Grzegorz Jaskiewicz" <gryz@poczta.onet.pl napisał w
wiadomości
Wszystko pięknie, ale ... Pliki są kompilowane oddzielnie. Jeśli w pliku
a.cpp
masz metody klasy, a w b.cpp z niej korzystasz, to niby skąd kompilator
ma to wiedzieć ? Linker jest na to za głupi.
Akurat tak sie składa że linker w visualu dzieli sobie plik lib lub objota
na mniejsze i linkuje co trzeba. Wystarczy mu tylko właczyć taką opcje,
nie
bede mówiłgdzie. Poszukajcie - niech ALT-F7 ma was prowadzi.....
Właśnie w tym celu wymyślili liba, żeby można było z niego wydłubywać
to co trzeba :-)
A co do obj. Rzeczywiście jest taka opcja (ku mojemu zaskoczeniu),
ale działa tylko dla prostych sytuacji (programy w stylu nic nie rób).
Dla bardziej skomplikowanego programu zostawia w EXE kod,
który nigdy nie będzie wykorzystywany, co programista widzi
od razu - na oko, a linker nie, czyli jednak jest głupi ;-)
Grzegorz Malicki
g@mks.com.pl
I jeszcze jedno. Mi chodzi o to aby nauczyc sie jakiegos jezyka i moc
pozniej w nim pracowac. Nie chcialbym nauczyc sie np. VB aby za 7 kilka
lat
nie bylo firm ktore programuja w tym jezyku. Chcialbym poznac cos co ma
przyszlosc :) C# uwazam ze jest nowym jezykiem z duzymi mozliwosciami i
mysle ze on ma przyszlosc. Tym bardziej ze nie ma tylu programistow C# co
VB
lub C++. Z drugirj strony przez to jest ciezej nauczyc sie tego jezyka
gdyz
nie ma skad brac informacje.
Język to tylko narzędzie, sposób zapisu. Znajomość języka,
a umiejętność programowania, to dwie "różne" sprawy.
(od razu uprzedzam cudzysłowiem - nie popadajmy w skrajności).
Nawet jeśli doskonale poznasz jakiś język wcale to nie oznacza,
że będziesz tworzył dobry kod. Szacując tak pi*oko ;-)
stawiałbym, że znajomość konkretnego języka, to 30%
tego co trzeba wiedzieć, żeby tworzyć. Pozostałe 70%
wiedzy i umiejętności jest języko-niezależne.
Grzegorz Malicki
Użytkownik "Wojciech "Spook" Sura" <spoko@no-spam.poczta.onet.plnapisał
w wiadomości
Uzasadnienie: W całej Sieci nie ma zbyt wielu miejsc do dyskusji dla
programistów asemblera. Posty dotyczące tego języka zazwyczaj zaśmiecaja
grupy
zaśmiecaja -zaśmiecają
Grzegorz Malicki
Thu, 7 Feb 2002 10:15:13 +0100, Grzegorz Malicki <Grzeg@malicki.compisze:
Różnica jest jeśli tego "i" do czegoś się do czegoś używa, np.
if (++i 7)
wykonuje się szybciej, bo brak jednego MOVa, niż
odpowiadające mu:
if (i++ 6)
Wyobraź sobie, że w gcc-3.0.3 może być odwrotnie.
int test1 (int i)
{
if (++i 7) return 10;
return 20;
}
int test2 (int i)
{
if (i++ 6) return 10;
return 20;
}
Kompilacja z -O2 -fomit-frame-pointer:
test1:
movl 4(%esp), %eax
incl %eax
cmpl $8, %eax
setl %al
movzbl %al, %eax
decl %eax
andl $-10, %eax
addl $20, %eax
ret
test2:
cmpl $6, 4(%esp)
setle %al
movzbl %al, %eax
decl %eax
andl $-10, %eax
addl $20, %eax
ret
Prawdopodobne wytłumaczenie jest proste. W pierwszym przypadku
zwiększamy i oraz porównujemy jego nową wartość z czymś tam. Tego
akurat nie udało się wyoptymalizować. W drugim przypadku nowa
wartość i nie jest nigdzie wykorzystana - porównywana jest tylko
stara wartość. Więc zwiększenia w ogóle nie ma.
Wnioski:
1. Nie zgadywać, tylko sprawdzać, co jest szybsze. Przy czym różne
kompilatory mogą dać zupełnie różne efekty.
2. Nie przejmować się, co jest szybsze, dopóki nie stwierdzimy, że dany
fragment programu ma istotny wpływ na szybkość całości. Zazwyczaj
na 90% szybkości całości ma wpływ 10% kodu i optymalizowanie reszty
jest stratą czasu programisty.
Użytkownik "Marcin 'Qrczak' Kowalczyk" <qrc@knm.org.pl
Wyobraź sobie, że w gcc-3.0.3 może być odwrotnie.
int test1 (int i)
{
if (++i 7) return 10;
return 20;
}
int test2 (int i)
{
if (i++ 6) return 10;
return 20;
}
Kompilacja z -O2 -fomit-frame-pointer:
test1:
movl 4(%esp), %eax
incl %eax
cmpl $8, %eax
setl %al
movzbl %al, %eax
decl %eax
andl $-10, %eax
addl $20, %eax
ret
test2:
cmpl $6, 4(%esp)
setle %al
movzbl %al, %eax
decl %eax
andl $-10, %eax
addl $20, %eax
ret
Niestety taki zapis nie jest dla mnie zbyt jasny,
ale zgaduje o co chodzi, może oprócz tego setle.
Prawdopodobne wytłumaczenie jest proste. W pierwszym przypadku
zwiększamy i oraz porównujemy jego nową wartość z czymś tam. Tego
akurat nie udało się wyoptymalizować. W drugim przypadku nowa
wartość i nie jest nigdzie wykorzystana - porównywana jest tylko
stara wartość. Więc zwiększenia w ogóle nie ma.
Zwróć uwagę, że Twój kod jest hmmm ... bezsensowny :-)
Ogólnie jeśli ze zmienna jest do czegoś POTRZEBNA,
to nadal utrzymuje, że na OGÓŁ i to taki zdecydowany
ogół ++i jest szybsze lub wykonuje się tak samo jak i++.
1. Nie zgadywać, tylko sprawdzać, co jest szybsze. Przy czym różne
kompilatory mogą dać zupełnie różne efekty.
Owszem, ale jeśli komuś nie chce się tego sprawdzać,
to może przyjąć, że ++i jest "lepsze".
2. Nie przejmować się, co jest szybsze, dopóki nie stwierdzimy, że dany
fragment programu ma istotny wpływ na szybkość całości. Zazwyczaj
na 90% szybkości całości ma wpływ 10% kodu i optymalizowanie reszty
jest stratą czasu programisty.
Z tym się zgodze w 100%. Ważne by kod był napisany dobrze
i żeby działał. Dopieszczanie takich szczegółów można sobie
zostawić na deser :-) Co innego jeśli ktoś coś pisze tylko
i wyłącznie dla własnej przyjemności.
Pozdrawiam,
Grzegorz Malicki
Grzeg@malicki.com
| Aha... co do zalozen systemu - sa na stronie El0ya:
| http://free.polbox.pl/e/el0y
Małe nieporozumionko. To jest bardzo stara strona i nie-aktualizowana.
Proszę się tym za bardzo nie sugerować.
Zastanówcie się może, jak system będzie wyglądał od strony programisty
(piszącego programy, a nie system). Komunikacja między procesami,
zarządzanie pamięcią, dostęp do plików, interfejs do poszczególnych
urządzeń wejścia-wyjścia? Nie chodzi o szczegóły typu numeru funkcji,
tylko ogólne zasady.
Taaak. Bardzo dobrze mówisz.
Ja zacząłem pisać system na zasadzie XBary ( Xbarego przepraszam, ale myślę,
że źle robi ).
Pisze system i jak ma napisane 20% to się zastanawia co dalej. ( a z resztą
skąd on wie że ma 20%? )
Pisałem na tej samej zasadzie. Ale Grzegorz Malicki wybił mi to z głowy.
Poważnie się nad tym zastanawiałem co mówisz. Doszedłem do pewnych
konkretnych wniosków, ale mam do Ciebie jedną prośbę. Chodzi fama, że
piszesz we wszystkim :-o co kiedykolwiek powstało na jakikolwiek komputer
;-))
Więc oto ta prośba:
Przyłącz się do nas! Gorąco proszę.
Nie mówię "od jutra kodujemy nowy system" i szukamy koderów, tylko chcemy
najpierw porządnie przemyśleć wszystko ( dokładnie to co mówisz ), a potem
napisać to w czymkolwiek.A to już będzie kaszka z mlekiem ( jak mawiał
GMal ). Najchętniej w asmie + kawałeczki c.
Max szybkość + elastyczność. Ale kodowanie to tylko 10% roboty.
Taki Mózg jak Ty i np. A.'SoTe'B., Dariusz Zolna, czy Pluton mogliby nam
pomóc, nie w pisaniu samego systemu, tylko w opracowywaniu założeń. W końcu
Wy Genialni Programiści tworzycie programy i wiecie jak powinno wyglądać
pisanie dobrego programu pod dobry system... ;-))
Pluton coś widzę nie lubi takich pomysłów, a A'SoTe'B proszę gorąco o
zdanie.
Szukamy gorąco ludzi, nie do programowania samego kernela ( bo to już
pierdoła ), tylko do myślenia!!
Proszę Was o wsparcie.
Dzięki
e@kki.net.pl
Cytat
A sami byli dla siebie większym ciężarem niż ciemność. Mdr 17,20
A sami byli dla siebie większym ciężarem niż ciemność. Mdr 17,20_2