Сишные циклы FOR в Паскаль не переводятся?

← →
Solution (2006-12-21 01:53) [120]

Удалено модератором

← →
Плохиш © (2006-12-21 02:13) [121]

> Solution (21.12.06 01:53) [120]

> Ты глухой что ли ? Тебе сказали в for перевести, а не в
> while.

Идиоты зажигают...

← →
Германн © (2006-12-21 02:31) [122]

2 Solution (21.12.06 01:53) [120]
Имхо, налицо нарушение правил данного форума, а именно п.5 из "Запрещается".
Да и п.1 в части "хамства", тоже.

← →
Solution (2006-12-21 03:25) [123]

Удалено модератором

← →
Думкин © (2006-12-21 05:41) [124]

> Solution (21.12.06 01:53) [120]

Оно понятно. Но где объяснение? Жевать - однозначно. :)

← →
See (2006-12-23 05:59) [125]

А вы, между прочим, тут зря на GameDev наезжаете! Некрасиво.

← →
Думкин © (2006-12-23 06:19) [126]

Да, наезда как такового не было. Но то, что они оказались способны судить о том, о чем имеют смутное представление и в том тоне, что виден по приведенной ветке - и дало мне повод сделать то самое заявление.
Искренне сожалею, если в тойц ветке увидел не самое адекватное подмножестов ГамеДева. Впрочем в игровых ресурсах это запостой. 90% обитающих там ламеры или около, что не мешает быть небольшому проценту действительно грамотных людей.

← →
Celades © (2006-12-23 09:27) [127]

> 90% обитающих там ламеры или около, что не мешает быть небольшому
> проценту действительно грамотных людей.

На этом форуме таже картина. Это проблема всех программистских ресурсов.

← →
Anatoly Podgoretsky © (2006-12-23 10:34) [128]

> Celades (23.12.2006 9:27:07) [127]

А соотношение 10:90 действует везде

← →
AM (2006-12-23 15:13) [129]

Думкин, вы так уверены, что те люди судят о том, о чем имеют смутное представление? И что они такого написали на 1ой странице, что заставило вас сделать такой вывод? Кстати, писать, что "оптимальности Паскалевского Фор в Си нет" - это полный бред. Единственная оптимальность тут - программист набирает меньше букв. Какую ещё вы оптимальность нашли? Вы хоть асм-то знаете, не говоря уже о более тонких вещах? Вот только не надо приводить тут в довод List.Count, ибо это не оптимизация, это условие работы цикла (кстати, на плюсах такое тоже можно реализовать, так что с вашим заявление вы поспешили. Как? А вот любой нормальный программист надо легко ответит, если не сможете сами, то я вам помогу). Да и вообще, про какую оптимальность идет речь, если Делфи не инлайнит?

Ну, или наверное "Разница в сущности - в Паскале цикл с именем FOR соответствует математике" - это просто верх крутости. Какой математике он соответствует? Что-то я не встречал этого соответствия ни в матанализе, ни в теории множеств, ни в теории автоматов...

Единственная причина, почему можно было написать ту гадость про геймдев, это то, что люди кинулись так рьяно обсуждать эту тему.

← →
Palladin © (2006-12-23 18:01) [130]

еще один чудик... откуда такие воинственные берутся, навереное с gamedev.ru...
сайт не плохой, и есть там нормальные люди, посты которых я читаю с удовольствием, а иногда затаив дыхание, но вот подобные АМ, не до конца понимающие когда именно и что именно оптимальней использовать... рассказывающие что все мы тут на лыжах по пляжу... в общем, позорят они этот сайт...

← →
ors_archangel © (2006-12-23 18:27) [131]

> Sha © (16.12.06 10:48) [9]

Да, у меня тоже были случаи, когда я доводил pascal-код до того, что он работал почти как асм, но вот другой пример - враппер для функции перечисления всех консольных переменных:
function ForEachCVarWrapper(name: string; cvar: PCVar; wrapdata: PForEachCVarWrapData): boolean; begin result := wrapdata.callback(name, wrapdata.param); { вот, что делает в таких случаях Deлфя: ) //// begin пушъ ebp // стек, а как же без него мув ebp,esp пушъ ecx пушъ ebx мув ebx,ecx мув [ebp-4],eax мув eax,[ebp-4] // абсолютно бессмыленно ! колл @LStrAddRef // увеличиваем ref-count строки (см.ниже) xор eax,eax пушъ ebp пушъ $0046dec4 // SEH, а вдруг что случится?! пушъ dword ptr fs:[eax] мув fs:[eax],esp //// result:=wrapdata.callback(name, wrapdata.param) мув edx,[ebx+4] // вот, собственно, сам код мув eax,[ebp-4] // я насчитал три строчки колл dword ptr [ebx] // а это, наконец-то, вызов wrapdata.callback мув ebx,eax xор eax,eax поп edx поп ecx // восстанавливаем стек поп ecx мув fs:[eax],edx // SEH пушъ $0046decb леа eax,[ebp-4] колл @LStrClr // уменьшаем ref-count (а зачем было увеличивать?) рет jмп @HandleFinally // SEH jмп -$10 // довльно интересно мув eax,ebx //// end поп ebx // восстанавливаем стек - не два раза, поп ecx // а для разных ветвей (ветвей!) поп ebp рет end;
Конечно, можно было уменьшить раздумья dcc, сделав
const name, но на тот момент уже был код, который юзал не-const name,
не хотелось всё переписывать, поэтому написал сам:
asm mov edx,[ecx].TForEachCVarWrapData.param jmp [ecx].TForEachCVarWrapData.callback end;
Есть разница?

← →
vidiv © (2006-12-23 18:40) [132]

> еще один чудик... откуда такие воинственные берутся, навереное
> с gamedev.ru...

Внимания женского недостаточно, видимо :D

← →
AM (2006-12-23 20:33) [133]

Palladin, мы знакомы? Вы видели хоть 1 строчку моего кода? Если нет, то претензии по "когда именно и что именно оптимальней использовать" предъявляйте к тому, что я написал, а не к чему-то эфемерному. А то складывается соответствующее впечатление о вашей квалификации.

Вылить кучу необоснованной грязи на вас я могу точно также, но мне хватает ума этого не делать.

← →
Palladin © (2006-12-23 20:54) [134]

> [133] AM

Ну представте 1 строчку вашего кода, раз вы так глупы, что бы считать, что по, лишь по одной строчке, я смогу судить об уровне в целом. Не впечатляет... Вокруг да около... Необоснованной грязи у себя я не увидел, это лишь была реакция на необоснованные и непонятные замечания с твоей стороны. Особенно по поводу Думкина.. что к чему...
Хочешь конкретики. Без проблем.

> Думкин, вы так уверены, что те люди судят о том, о чем имеют
> смутное представление? И что они такого написали на 1ой
> странице, что заставило вас сделать такой вывод? Кстати,
> писать, что "оптимальности Паскалевского Фор в Си нет" -
> это полный бред.

Во первых твоим же оружием по тебе же. А ты уверен что слишком уверенно судишь о Думкине не имея представления о нем? Ай ай ай.
Думкин отнюдь не пишет об превосходстве. Он пишет о различности реализации. Покажи мне где он пишет о превосходстве?

> Единственная оптимальность тут - программист набирает меньше
> букв. Какую ещё вы оптимальность нашли? Вы хоть асм-то знаете,
> не говоря уже о более тонких вещах? Вот только не надо приводить
> тут в довод List.Count, ибо это не оптимизация, это условие
> работы цикла (кстати, на плюсах такое тоже можно реализовать,
> так что с вашим заявление вы поспешили.

Ну да, меньше букв. Ага. Особенно смешны слова "это не оптимизация, это условие работы цикла". Нет, твоя голова в этой фразе точно не работала. Что УЖЕ позволяет соствить о тебе мнение. Кстати в плюсах оно по другому и не реализованно. Так что со своей фразой ты поспешил, что аж насмешил.

> Как? А вот любой нормальный программист надо легко ответит,
> если не сможете сами, то я вам помогу). Да и вообще, про
> какую оптимальность идет речь, если Делфи не инлайнит?

Певый вопрос по поводу "Как?". Как что? А на какой вопрос нормальный программист легко ответит? Помоги мне, я вот не нормальный программист, бо не могу понять, что же имелось в виде под вопросом "Как?" особенно к чему он относится. Ты считаешь что инлайн(ит, кстати почему ит? это какой то придуманные тобой постфикс для инлайн?) это показатель оптимальности? ничего себе, и это говорит парень который типа пришел с геймдев.ру, где любой нормальный человек понимает что инлайн функции это отнюдь далеко не оптимально в рендеринге? ужасть...

> Единственная причина, почему можно было написать ту гадость
> про геймдев, это то, что люди кинулись так рьяно обсуждать
> эту тему

Да нет. Он написал про основную массу. Раз ты запостил сюда свое негодование, вывод очевиден...

← →
ors_archangel © (2006-12-23 21:05) [135]

> почему ит

инлайнит - это глагол

> инлайн функции это отнюдь далеко не оптимально в рендеринге

Действительно, намного оптимальней в цикле тратить время на push/call/ret, чем не делать этого

← →
Palladin © (2006-12-23 21:17) [136]

> инлайнит - это глагол

а... однако девствительно... и почему основная масса называет инлайн функции, а не инлайнит функция... мы тут грамматикой хвастаемся или общепринятой терминологии придерживаемся?

> Действительно, намного оптимальней в цикле тратить время
> на push/call/ret, чем не делать этого

Где же это можно применить? Давай подумаем... Весь цикл рендеринга в inline никак не получится... хем... ну ладно... обработка вершин? ага.. было бы прикольно если бы обработка вершин склонялась к одной функции, однако она большая... эта функция... и то что тело цикла трансформации введут в инлайн, это оффегительная экономия на спичках... да и смысла нет... что оптимально в инлайн? А вот что...
for (i=0;i<5;i++) {
calc;
}
не более трех-четырех вызовов в теле...

← →
ors_archangel © (2006-12-23 21:30) [137]

> Palladin © (23.12.06 21:17) [136]
> инлайнит функция

странный ты какой-то, я же говорю, что инлайнит - это глагол: "Делфи инлайнит": что? - Делфи, что делает? - инталйнит. Полностью проспрягать что ли?

> Где же это можно применить?

Да, в случае обращения к аппаратно-ускоренным интерфейсам, инлайн или его отсутствие может не сильно влиять на скорость. Но если бы Делфи всё-таки поддерживал встраивание функций (говорю "встраивание", что бы ты не придрался к слову "инлайнинг"), то можно было бы более смело использовать, собсвенно, функции для выделения общих частей (малых по размеру) в коде, что в противном (существуещем на данный момент) случае создаёт упомянутый мной "мусор" в виде опкодов push/call/ret и, возможно, других. То, что Делфи не поддерживает этого, это только малая часть от её общей ограниченности по части оптимизации и, вообще, языка

← →
jack128 © (2006-12-24 00:15) [138]

ors_archangel © (23.12.06 21:30) [137]
если бы Делфи всё-таки поддерживал встраивание функций
она (Дельфи - женского рода ;-) ) и поддерживает...

← →
jack128 © (2006-12-24 00:17) [139]

jack128 © (24.12.06 0:15) [138]
она (Дельфи - женского рода ;-) ) и поддерживает...

хотя мне почему то кажется, что inline сделали, что гордо писать в пресс релизе "поддержка inline функций", чем из-за реальной потребности...

← →
ors_archangel © (2006-12-24 00:33) [140]

> jack128 © (24.12.06 00:17) [139]
> хотя мне почему то кажется, что inline сделали, что гордо
> писать в пресс релизе "поддержка inline функций"…

Не согласен, как я написал в [137], inline-функции позволяют делать больше обобщений. Например, я практически никогда не использую функции GetR/G/BValue, ведь намного быстрее работает and и shr, или хотя бы mod и div, а вот если бы GetRValue, например, был inlinом, то я б и предпочёл его использование, т.к. r = GetRValue(clr) понятней, чем r = clr and $ff или r = clr mod 256, да и ошибку так допустить сложнее

← →
Anatoly Podgoretsky © (2006-12-24 00:37) [141]

> ors_archangel (24.12.2006 0:33:20) [140]

Это ты еще про LongRec не слышал

← →
Sha © (2006-12-24 00:50) [142]

> ors_archangel © (23.12.06 18:27) [131]

Весь этот огород понадобился компилятору из-за твоего собственного нежелания помочь ему сгенерировать оптимальный код. Вот он и создает временную копию строки и генерирует код для ее уничтожения по завершении процедуры. В таких случаях обычно помогает указание const или var.

Не могу припомнить ни одного случая, чтобы мне когда-нибудь действительно потребовалась создавать копию параметра - скорее всего подобное говорит либо о неряшливости, либо о плохой продуманности проекта.

Конечно до jmp никакой компилятор не оптимизирует, но до обычного call - запросто.

> jack128 © (24.12.06 00:17) [139]
> гордо писать в пресс релизе "поддержка inline функций

Ну почему же... Можно, например, теперь сделать реализацию Pos через PosEx, не рискуя потерять время на call-ret, и т.п.

← →
Sha © (2006-12-24 00:55) [143]

> ors_archangel © (24.12.06 00:33) [140]
> ведь намного быстрее работает and и shr, или хотя бы mod и div

Могу добавить, что в некоторых случаях это самое "намного быстрее"
составляет разы в целом по проекту.

← →
Sha © (2006-12-24 01:19) [144]

> Sha © (24.12.06 00:50) [142]
> Конечно до jmp никакой компилятор не оптимизирует, но до обычного call - запросто.

Кстати, здесь инлайн как раз подойдет как нельзя лучше :)

← →
ors_archangel © (2006-12-24 01:24) [145]

> Sha © [142]

Вот именно, я не имею никакого желания помогать компилятору делать его работу.

> Sha © [143]

Intel Compiler уже пытается применять SSE, а дядя Борланд сидит и пятки чешет :)

> Sha © [144]

Если /dev/mem мне не изменяет, то Turbo Prolog от того же Borland в своё время мог оптимизировать хвостовую рекурсию, - могли, когда надо было, блин :(

← →
ors_archangel © (2006-12-24 01:28) [146]

В Паскальном forе не хватает basicовского stepа, вот это уж точно, приходится делать while, где им и не пахнет :(

← →
ors_archangel © (2006-12-24 01:31) [147]

А ещё для так любимого Borland OOP, inline то ж ой как пригодился б, хотя размер exeшников и так очень уж крут и без того, может, в этом причина, не хотели, чтобы exeшники весили ещё больше, больше, ведь уже некуда? А причина здесь уже в языке

← →
Sha © (2006-12-24 01:32) [148]

> ors_archangel © (24.12.06 01:24) [145]
> Вот именно, я не имею никакого желания помогать компилятору делать его работу.

Помогать не требуется, достаточно сообщить о своих желаниях :)
В том случае ты обманул компилятор, сказав ему что желаешь иметь возможность изменять параметр, вот он и удовлетворил твое желание по полной программе, предоставив тебе такую возможность. А то, что ты ей не воспользовался - не его вина. Он сделал все как ты просил :)

← →
Step by step (2006-12-24 03:52) [149]

> ors_archangel © (24.12.06 01:28) [146]
>
> В Паскальном forе не хватает basicовского stepа, вот это
> уж точно, приходится делать while, где им и не пахнет :(

А множитель использовать - типа ума не хватило ?
Чтож. Сочувствую.

> ors_archangel © (24.12.06 01:24) [145]
>
> Intel Compiler уже пытается применять SSE, а дядя Борланд
> сидит и пятки чешет :)

Какой же ты агрессивный ламер. Пока Интел пытается, в GLScene уже много лет есть оптимизация и под SSE и под 3DNow для ключевых функций. Сама определяет их наличие и сама использует если они есть. И всё работает даже на старой Дельфи 6.

← →
AM (2006-12-24 04:14) [150]

>Необоснованной грязи у себя я не увидел
"но вот подобные АМ, не до конца понимающие когда именно и что именно оптимальней использовать" - откуда вы знаете, что я не до конца понимаю? Это и есть необоснованная грязь - переход на личности. Про лично Думкина я вообще ничего не писал, только про его посты.

>Во первых твоим же оружием по тебе же. А ты уверен что слишком >уверенно судишь о Думкине не имея представления о нем? Ай ай ай.
Я написал про фразу, а не про него.

>Думкин отнюдь не пишет об превосходстве. Он пишет о различности >реализации. Покажи мне где он пишет о превосходстве?
Думкин пишет "оптимальности Паскалевского Фор в Си нет".

>Ну да, меньше букв. Ага. Особенно смешны слова "это не оптимизация, это >условие работы цикла". Нет, твоя голова в этой фразе точно не работала. >Что УЖЕ позволяет соствить о тебе мнение.
Дело в том, что если значение List.Count должно изменяться в контексте цикла, его нужно было бы вызывать каждый раз при проверке условия окончания цикла. Но из-за специфика Фора в Делфи значение List.Count может быть вычилсено только один раз. Если честно, я не понимаю, чего вас так удивила эта фраза.

>Кстати в плюсах оно по другому и не реализованно.
Вы неправы. Сравните:
for (int i = 0, end = function_call(); i < end; ++i) //аналогично List.Count
for (int i = 0; i < function_call(); ++i)
>Певый вопрос по поводу "Как?".
"Как?" относилось к тому, что я написал выше.

>ничего себе, и это говорит парень который >типа пришел с геймдев.ру, где любой нормальный человек понимает что >инлайн функции это отнюдь далеко не оптимально в рендеринге? ужасть...
Вот вы придираетесь к моим фразам, но сами-то пишете не менее косноязычно - "неоптимально в рендеринге". В общем-то, проблемы инлайнинга (я думаю, раз вы написали про рендеринг, они вам известны) касаются не только 3д движков, но и любого performance-critical приложения. Тем не менее, современные компиляторы достаточно умны, чтобы минимизировать возможность появления этих проблем, учитывая те преимущества, которые он дает.
>Это показатель оптимальности?
Нет, но я использовал Делфи очень давно и это то, что вспомнилось конкретного про его недостатки (впрочем, возможно, я был неправ, см. ниже)

>Да нет. Он написал про основную массу. Раз ты запостил сюда свое >негодование, вывод очевиден...
Я попрошу вас вести себя более сдержано, вам вроде как не 18 лет.

>jack128
Хмм, а с какой версии? Просто я давно его не использовал, может быть и неправ был.

> Step by step (24.12.06 03:52) [149]
> А множитель использовать - типа ума не хватило ? Чтож. Сочувствую.

- один add, чтобы увеличить счётчик, или в лучшем случае несколько mul - каждый раз умножать счётчи (ума же хватило :), что же быстрее? Спасибо, конечно, за сочувствие… :)

> Пока Интел пытается, в GLScene уже много лет есть оптимизация
> и под SSE и под 3DNow для ключевых функций. Сама определяет
> их наличие и сама использует если они есть. И всё работает
> даже на старой Дельфи 6.

Я конечно извиняюсь, но GLScene - это не компилятор HLL. Читаем описание Википедии: "GLScene — это бесплатный OpenGL-ориентированный графический движок для Дельфи с открытым исходным кодом", а Intel C++ Compiler, как видно из названия, - компилятор, т.е. он "automatically parallelizes code to maximize underlying processor capabilities. This advanced optimization analyzes loops and determines when it is safe and effective to execute several iterations of the loop in parallel by utilizing MMX™, SSE, SSE2, and SSE3 instructions… Features include support for advanced, dynamic data alignment strategies, including loop peeling to generate aligned loads and loop unrolling to match the prefetch of a full cache line", Intel C++ Compiler - это, компилятор, который анализирует HLL-код и может применять SSE там, где он видит это возможно, при этом тебе не нужно даже знать ни одного асм-опкода, именно это я имел в виду.

← →
Step by step (2006-12-24 05:22) [153]

> ors_archangel © (24.12.06 04:47) [151]
>
>
> > Step by step (24.12.06 03:52) [149]
> > А множитель использовать - типа ума не хватило ? Чтож.
> Сочувствую.
>
> - один add, чтобы увеличить счётчик, или в лучшем случае
> несколько mul - каждый раз умножать счётчи (ума же хватило
> :), что же быстрее? Спасибо, конечно, за сочувствие… :)

То есть ты делаешь всё через ж**у ради экономии наносекунд. Тогда сочувствую вдвойне.

> Я конечно извиняюсь, но GLScene - это не компилятор

Тебе шашечки или ехать?

Все эти SSE и 3DNow! большинству офисных приложений которые мы пишем нафиг не нужны. А в GLScene нужны. Поэтому и написаны.

> это, компилятор, который анализирует HLL-код и может применять
> SSE там, где он видит это возможно, при этом тебе не нужно
> даже знать ни одного асм-опкода, именно это я имел в виду.

В GLScene тебе тоже не нужно знать. Всё уже давно написано.

И процессор ещё должен поддерживать SSE. А раздвувать программу типа блокнот, за счёт включения в неё двух экземпляров кода с SSE и без SSE - это тупость.

Уважаемый Step by step !
Я имел в виду, что
for i := 1 to 10 step 2 do …
лучше чем
i := 1; while i <= 10 do begin … inc(i,2); end
и только это, так же я считаю, что первое лучше и
for i := 1 to 10 div 2 do … i * 2 - 1
- я имел в виду только и именно отсутствие step как модификатора for, который по моему мнению был бы удобен и улучшил бы удобочитаемость в соотвествующих случаях, конечно, тебе, например, больше нравится делать for с умножениями, мне приятней сознавать, что код оптимален - все мы разные и это замечательно, я согласен с твоей позицией, ведь, действительно, незначительный выйгрышь/проигрышь в скорости в наше время не так много значит.
Далее, SEE-оптимизация - это был только пример возможностей IntelC++ Compiler, как действительно оптимизирующего компилятора, сильно отличающегося в этом от нашего любимого dcc. А вот причём здесь тот же GLScene, ума не приложу, видимо это хороший движок, раз он даже юзает 3DNow!, я же сравнивал компиляторы Intel и Delphi. Понимаешь, в GLScene не нужно было бы писать asm-SSE код, если бы dcc оптимизировал как волшебник (или как бог), он же оптимизирует скорее для вида ("я оптимизирую, я оптимизирую, посмотрите!" :) В действительности, между $o+ и $o- разница не особая и совсем уж локальная. Меня просто убило, что ты практически заявил "есть програ, юзает SSE уже давно, так что нафиг нам не надо компиляторов, которые такие проги смогут делать за нас!" …И я согласен, что делить блокнот - это тупость, блокнот - это вообще тупость :) я использую bred3 (©Gladiators Soft)

P.S. Что ещё умеет Intel C++ Compiler (читай: "чего ещё не умеет компилятор Делфи"):
# Multithreaded Application Support, including OpenMP and auto-parallelization for simple and efficient software threading. # Interprocedural Optimization (IPO) dramatically improves performance of small- or medium-sized functions that are used frequently, especially programs that contain calls within loops. # Profile-guided Optimization (PGO) improves application performance by reducing instruction-cache thrashing, reorganizing code layout, shrinking code size, and reducing branch mispredictions. # Automatic Vectorizer parallelizes code and aligns data, including loop peeling to generate aligned loads and loop unrolling to match the prefetch of a full cache line. (это и есть MMX/SSE-оптимизация) # High Level Optimization (HLO) delivers aggressive optimization with loop transformation and pre-fetching.
©Intel

> AM (23.12.06 15:13) [129]

Качество обсуждения там было именно тем, что я озвучил. Если вас - задело, ну значит задело. Попробуйте исправится - чтобы не задевало.

А АСМ я знал, судя по вашему настрою, еще тогда когда вы о стол башкой стукались. Причем тут это?

А в остальном

> Palladin © (23.12.06 20:54) [134]

озвучил верно.

← →
Step by step (2006-12-24 06:41) [157]

> ors_archangel © (24.12.06 06:01) [154]
>
> Уважаемый Step by step !
> Я имел в виду, что
>
> for i := 1 to 10 step 2 do

А если ты прокрутил экран и забыл какой там был шаг, то что тогда ? Крутить туда-сюда, или устраивать конкурс на лучшую память ?

for i := 1 to 10 step 2 do
for j := 1 to 10 step 9 do
for k := 1 to 10 step 7 do
for m := 1 to 10 step 4 do

Давай, держи всё это в голове, где там какой шаг был обозначен. Если лично тебе удобнее обозначать шаг в одном месте, а использовать его в другом. Типичная для Си манера ребусности.

← →
Step by step (2006-12-24 06:54) [158]

> ors_archangel © (24.12.06 06:01) [154]
> Понимаешь, в GLScene не нужно было бы писать asm-SSE код,
> если бы dcc оптимизировал как волшебник

Переводя на русский ты не знаешь встроенного в Дельфи асемблера. Даже на уровне:

movq mm0, [eax] pfadd mm0, [edx] movq [ecx], mm0 movq mm1, [eax+8] pfadd mm1, [edx+8] movq [ecx+8], mm1 femms

Могу тогда посочувствовать в третий раз.

Может быть ты вообще ничего кроме Бейсика не знаешь, и ничего кроме "Здарвствуй мир !" на нём в жизни не написал ?

И поэтому требуешь компиляции этой программы только с SSE.

> я использую bred3

Понятно.

2 Step by step

> Крутить туда-сюда, или устраивать конкурс на лучшую память
> for i := 1 to 10 step 2 do
> for j := 1 to 10 step 9 do
> for k := 1 to 10 step 7 do
> for m := 1 to 10 step 4 do

- интересный пример, думаю, если бы я сделал в компиляторе step-модификатор для forа, то я бы уж и сделал и хинт для переменной цикла в виде "i: integer, step x", например… Знаешь, если развить твою мысль, то лучше при упоминании переменной сразу же писать её тип, чтобы не "крутить туда-сюда" и не "устраивать конкурс"ы - шутка конечно, - как ни раз говорилось на этом сайте - "всё можно довести до абсурда", и твой пример, согласись, довольно искусственный. Ты принципиально против шага цикла, указываемого в его заголовке? Или ты просто хочешь разоблочить всех "агрессивных ламеров" на свете?

> AM (24.12.06 04:14) [150]
> Думкин пишет "оптимальности Паскалевского Фор в Си нет".

Да, я написал эту фразу. Подразумевал, бееспорно конструкцию вида:
for(i=0;i<f(n);i++)
Если приведенное вами, закрывает это также как и в Паскале - что ж, в этом пункте был неправ. И Сишный фор - это ходячий монстр. :)

Сишные циклы FOR в Паскаль не переводятся? Найти похожие ветки