|
| Посл.отвђт | Сообщенiе |
|
|
Дата: Май 12, 2004 11:35:25 > У меня psdk-oct-2002 - 16-ть cab'ов - 412,352,392 байт Мда, это много :-( > См. аттач. Будут вопросы - задавай. Спасибо. Как достану необходимые инклуды попробую ;-) |
|
|
Дата: Май 12, 2004 16:07:00 · Поправил: S_T_A_S_ Asterix Я делал так: - приконектился к инету - открываю README.htm в папке с toolkit (IE, под юзером с правами админа !!) - иду в этой странице по той ссылке - где-то в этом месте MS мне подгружают пару троянов =) - далее на новой странице иду: Downloads->Install - там будет список частей всего SDK - можно выбрать что хочешь. Для большенства случаев достаточно Core SDK->Build environment - это инклуды, либы, и кое-какие екзешники. Весит оно 31 мег, но что-то там еще будет установленно помимо этого. |
|
|
Дата: Май 12, 2004 17:15:20 S_T_A_S_ А инсталляха какая-нить сохранится или оно ставится исключительно online? |
|
|
Дата: Май 12, 2004 19:13:21 Ставится онлине. Но сливаемые cab файлы, наверное, можно и найти. Я чего-то я не задавался таким вопросом - все равно потом для архивных целей пожал LZMA - в 2 раза меньше чем CAB. Debugging Tools - сливается msi 8 метров - его потом самому надо запускать. Может даже его можно и на сайте положить? |
|
|
Дата: Май 12, 2004 19:15:21 Может даже его можно и на сайте положить? А зачем? Линк в тулзах есть. А так - это просто лишний траффик и лишняя работа для меня по поддержанию. Не вижу смысла. |
|
|
Дата: Май 12, 2004 21:49:44 Ну.. не знаю зачем. Мне он не нужен, т.к. уже и так скачал. И не думаю, что у него много поклонников :) |
|
|
Дата: Май 13, 2004 16:07:09 |
|
|
Дата: Май 13, 2004 19:01:48 · Поправил: S_T_A_S_ Читал я.. интересно на первый взгляд.. Но потом.. Поехали: Самое смешное, что не оптимизируется присваивание вида x := 0. Вместо XOR компилятор использует медленную и длинную инструкцию MOV С чего это MOV будет медленнее? Может на 286 каком-нибудь? То, что длиннее - он прав. Быстрые умножения
x *= 8;
shl eax, 3 ; Сдвинуть на 3 разряда влево — так делают LCC32, D, MinGW,
; MSVC++ (оптимизация по размеру), FreePascal и BCC
lea ecx, DWORD PTR [eax*8] ; MSVC++ (оптимизация по скорости)
add eax, eax ; eax = x * 2 — Intel C++ Compiler
add eax, eax ; eax = x * 4
add eax, eax ; eax = x * 8Последние два варианта на современных процессорах работают быстрее, так как инструкции LEA и ADD могут выполняться параллельно с другими инструкциями на разных конвейерах процессора.
С чем паралельно будут выполняться три ADD? Сами с собой? А как же зависимость по результату? И почему SHL не может выполняться параллельно? Использование регистров ; MinGW mov eax, DWORD PTR [ebp-08] ; eax = x add eax, 05 ; eax = eax + 5 mov DWORD PTR [ebp-04], eax ; y = eax lea ecx, DWORD PTR [eax+eax] ; ecx = eax * 2 mov DWORD PTR [ebp-08], ecx ; x = ecx ; D mov ebx, DWORD PTR [esp+10] ; ebx = x add ebx, 5 ; ebx = ebx + 5 mov DWORD PTR [esp+14], ebx ; y = ebx add ebx, ebx ; ebx = ebx * 2 mov DWORD PTR [esp+10], ebx ; x = ebxКомпилятор D обошелся всего одним регистром, но почему-то EBX, а не EAX, инструкции с которым короче на байт. При чем здесь EAX / EBX? Короче будет только: add eax, 05 Длина остальных инструкций увеличилась из-за использования ESP вместо EBP. А вся подпрограмма целиком все одно короче будет, т.к. нет лишних операций с EBP (MOV, PUSH & POP) В процессорах Pentium Pro и выше имеются 3 декодера D0, D1 и D2, которые разделяют машинные инструкции на элементарные микрооперации Правильно: в семействе процессоров Pentium Pro. выше уже идет другая архитектура - NetBurst. Но там не: "Аналогичный механизм в Pentium IV отличается от более ранних процессоров тем, что декодированные микрооперации кэшируются, и при повторном выполнении (например, в циклах) декодирование не требуется." А: "The front end of the Intel NetBurst micro-architecture has a single decoder that can decode instructions at the maximum rate of one instruction per clock. Some complex instructions must enlist the help of the microcode ROM. The decoder operation is connected to the execution trace cache discussed in the next section." ;MinGW cmp DWORD PTR [ebp-36], 272 je L7 ; если равно 272, переходим к соотв. ветви cmp DWORD PTR [ebp-36], 272 ja L51 ; если больше 272, проверяем 273 и 1132 cmp DWORD PTR [ebp-36], 78 je L15 ; если равно 78, переходим к соотв. ветви jmp L2 ; ни одно из условий не сработало - выходим L51: cmp DWORD PTR [ebp-36], 273 je L19 ; если равно 273, переходим к соотв. ветви cmp DWORD PTR [ebp-36], 1132 je short L3 ; если равно 1132, переходим к соотв. ветви jmp L2 ; выходим L3:Единственная ошибка компилятора здесь в том, что третья строка совершенно бесполезна, и ее следует исключить (инструкция je не меняет флаги, установленные cmp). Совсем не пойму про что пишут 8-() Какая строка, какие флаги.. |
|
|
Дата: Май 13, 2004 19:07:26 Совсем не пойму про что пишут 8-() Это он к тому, что можно было бы и так: cmp DWORD PTR [ebp-36], 272 je L7 ; если равно 272, переходим к соотв. ветви ja L51 ; если больше 272, проверяем 273 и 1132 |
|
|
Дата: Май 13, 2004 19:18:00 Понял. Эту строку я посчитал четвертой с разгону :( Вообще, мне показалось странным -- кто-то может сомневаться, что команды переходов могут на флаги менять. |
|
|
Дата: Май 13, 2004 19:24:08 Хи-хи. А вообще, мне очень приятно было твои комментарии к его статье почитать! |
|
|
Дата: Май 13, 2004 19:25:14 Да, и еще. Если честно, то это представление switch - убогое. Правда он упоминает о правильном представлении свитча - с прыжком на основе индекса... |
|
|
Дата: Май 13, 2004 19:33:08 Ну, про таблицу - понятно.. Я просто то, что в глаза бросилось прокомментировал. Выводы-то там даются, но вот насколько они верны исходя из этого ^^ |
|
|
Дата: Май 13, 2004 20:20:21 А чего там в выводах то сомневаться, ведь никто и не сомневался что в итоге лучший будет MSVC++ :-) сорри за каламбур. |
|
|
Дата: Май 14, 2004 11:17:27 volodya Извиняюсь за свои слова - наговорил много лишнего и вобще был сильно неправ. Это все нервное.. :( |