Hello, Odi$$ey!
ША>> Поправьте форматирование, видны тэги.

ША>> xor <kw>eax</kw>,<kw>eax</kw> ; a = 0</com>

Oe> в упор не вижу

Поправил уже.

Здравствуйте!

Довольно познавательная статья, не будешь же все время бороздить инет в поисках новых решений
Пара дополнений по поводу FPC. Во-первых, ранние версии порождали до крайности нестабильный код. Фактически, нельзя было надеяться, что компиляция будет проведена правильно. Впрочем, все багрепорты желающие могут сами увидеть на официальном сайте.
В целом, однако, компилятор мне нравится больше Delphi. Помнится, последние версии даже компилировали нормально код, на котором Delphi обломала зубы. Одно из мелких нововведений, отсутствие которых меня сильно бесило в Delphi — статические члены классов (вводятся ключевым словом static).
Насчет оптимизации по правилу 1-1-4 нельзя не заметить, что под P4 с его Trace Cache такая оптимизация способна замедлить выпонение кода, сам с таким сталкивался. Так что, если в качестве целевого процессора выставляли P4, возможно, компиляторы неспроста не занимались этим. Там другие правила оптимизации, с экономией на параллельном выполнении операций и т.п.. Было бы время, можно было бы посмотреть, насколько удачны эти решения в рассчете на P4.

С уважением,
Slicer

Здравствуйте, Петр Каньковски, Вы писали:
[skip]
Что имелось ввиду под:
Перегрузка арифметических операторов, операторов сравнения и присваивания."
в пункте относящемся к freepascal. Как это вообще выглядит на языке Pascal....если не сложно приведите небольшой пример класса....а то не нашел
P.S. Просто я последний раз кодировал на Object Pascal когда этого там не было

Хотел бы пожелать:

статья называется "средства разработки",
и именно это многим людям интересно.

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

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

Надо бы отделььныую статью про ассемблер, кому это важно.

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

Прикладных аспектов (реально непосредственно полезных), маловато.


Наилучшие пожелания писать то что надо, а не другие развлечения.
Хе-е. Юмор.

Здравствуйте, Петр Каньковски, Вы писали:

ПК>Статья:


ПК>Авторы:
ПК> Петр Каньковски

ПК>Аннотация:
ПК>Бесплатные средства разработки, основанные на C и C-подобных языках (MinGW, LCC32-Win, Digital Mars), и на Pascal (Free Pascal). Сравнение оптимизации, многочисленные ссылки.

Интересная статья. Вот только утверждение:
ПК>Вторая категория — устаревшие программы, которые раньше успешно продавались, а теперь фирмы-разработчики раздают их бесплатно (сюда относятся уже упомянутый Turbo Pascal, Watcom C++ и еще несколько компиляторов под DOS). Ни одного Windows-компилятора в этой категории вы не найдете.

— излишне категорично.
http://www.openwatcom.com

Здравствуйте, <Аноним>, Вы писали:

А>Интересная статья. Вот только утверждение:
ПК>>Вторая категория — устаревшие программы, которые раньше успешно продавались, а теперь фирмы-разработчики раздают их бесплатно (сюда относятся уже упомянутый Turbo Pascal, Watcom C++ и еще несколько компиляторов под DOS). Ни одного Windows-компилятора в этой категории вы не найдете.

А>- излишне категорично.
А>http://www.openwatcom.com

К сожалению, даже последний Ваткомоский компилятор высоким соответствием нашей библии (Стандарту) похвалиться AFAIK не может — лучше уж MS C++ Toolkit 2003 "брать".

Здравствуйте, Аноним, Вы писали:

А
А>VC 6.0. В свойствах файлов Cl*.* указана версия 12.00.8168.0.
А>Intel Compiler 4.1.1.0
А>gcc version 3.2 (mingw special 20020817-1)
А>lcc-win32 version 3.8.
А>Borland C++ 5.5.1 for Win32
А>D Compiler Beta v0.63
А>Free Pascal Compiler version 1.0.10 [2003/06/27] for i386

а почему интел н присутствует в последней табличке?

Здравствуйте, Петр Каньковски, Вы писали:

ПК>Статья:
ПК>Альтернативные средства разработки под Windows

Автор(ы): Петр Каньковски
Дата: 11.04.2004
Бесплатные средства разработки, основанные на C и C-подобных языках (MinGW, LCC32-Win, Digital Mars), и на Pascal (Free Pascal). Сравнение оптимизации, многочисленные ссылки.

ПК>Авторы:
ПК> Петр Каньковски

ПК>Аннотация:
ПК>Бесплатные средства разработки, основанные на C и C-подобных языках (MinGW, LCC32-Win, Digital Mars), и на Pascal (Free Pascal). Сравнение оптимизации, многочисленные ссылки.


тут кажется опечатка

В C/C++ (соглашение о вызовах _stdcall) принято проталкивать параметры в стек в обратном порядке и очищать стек в вызывающей функции. Если вызывается несколько функций подряд, стек между вызовами можно не очищать.

Здравствуйте, Сергей,

СМ>тут кажется опечатка
СМ>

СМ>В C/C++ (соглашение о вызовах _stdcall) принято проталкивать параметры в стек в обратном порядке и очищать стек в вызывающей функции. Если вызывается несколько функций подряд, стек между вызовами можно не очищать.

А как должен выглядеть правильный вариант?

Петр.

Здравствуйте, <Аноним>

СМ>>тут кажется опечатка
СМ>>

СМ>>В C/C++ (соглашение о вызовах _stdcall) принято проталкивать параметры в стек в обратном порядке и очищать стек в вызывающей функции. Если вызывается несколько функций подряд, стек между вызовами можно не очищать.

с:

int __stdcall f1(int a,int b)
{
    return a+b;
}
int __cdecl f2(int a,int b)
{
    return a+b;
}

void t(void)
{
    f1(1,2);
    f2(1,2);
}

asm:

int __stdcall f1(int a,int b)
{
    mov         eax,dword ptr [esp+4] ; eax = a 
    add         eax,dword ptr [esp+8] ; eax += b
    retn 8    ; очистка стека в вызываемой подпрограмме
}

int __cdecl f2(int a,int b)
{
    ; return a+b;
    mov         eax,dword ptr [esp+4] ; eax = a 
    add         eax,dword ptr [esp+8] ; eax += b
    ret        ; очистка стека в вызывающей подпрограмме
}


void t(void)
{
    ...
        f1(1,2);
    0042A03E  push        2            ; параметры в "обратном" порядке
    0042A040  push        1    
    0042A042  call        f1 (42862Bh) ; f1 сама уберёт
        f2(1,2);
    0042A047  push        2            ; параметры в "обратном" порядке
    0042A049  push        1    
    0042A04B  call        f2 (427E97h) 
    0042A050  add         esp,8             ; чистка за f2
    ...
}

А>А как должен выглядеть правильный вариант?

В C/C++ (соглашение о вызовах _cdecl) принято проталкивать параметры в стек в обратном порядке и очищать стек в вызывающей функции.

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

Здесь много тонкостей. В стеке могут лежать аргументы для вызываемых функций, локальные переменные. Балланс нарушится.

Разве что можно делать наподобие:

    push        2
    push        1
    push        2
    push        1
    push        3
    push        5
    call        f1
    call        f2
    call        f2
    add            esp,16        ; чистка за f2,f2

Здравствуйте, IceStudent,

В C/C++ (соглашение о вызовах _cdecl) принято проталкивать параметры в стек в обратном порядке и очищать стек в вызывающей функции.

да, Вы абсолютно правы: _cdecl, а не _stdcall. Извините, это опечатка. Соглашение о вызовах _stdcall используется при вызове процедур Win32 API, и оно не позволяет очищать стек сразу за несколько функций.

int __cdecl f2(int a,int b)

    push        2
    push        1
    push        2
    push        1
    call        f2
    mov [somewhere], eax  ; записали в глоб. переменную возвращенное значение
    call        f2
    add            esp,16        ; чистка за f2,f2

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

    push        2
    push        1
    call        f2
    mov [somewhere], eax ; использовали возвращенное функцией значение
    push        2
    push        1
    call        f2
    add            esp,16        ; чистка за f2,f2

Здесь много тонкостей. В стеке могут лежать аргументы для вызываемых функций, локальные переменные. Баланс нарушится.

Ну и что? Главное — после вызова всех функций окончательно очистить стек, и не вызвать его переполнения.

Петр.

Здравствуйте, <Аноним>, Вы писали:

Соглашение о вызовах _stdcall ... не позволяет очищать стек сразу за несколько функций.
Точнее, этого и не нужно

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

Есть еще очень неплохая вешь: https://libre.adacore.com/gps/

Здравствуйте, Петр Каньковски, Вы писали:

ПК>[Кроме того, в бета-версии Dev-C++ мне не удалось отключить добавление отладочной информации (пришлось удалять ее с помощью шестнадцатеричного редактора).

так есть strip.exe в minGW ( откуда он у меня, minGW нет дистрибутива allinone )

а как cdeblocks.org vs dev++ ?

А>а как cdeblocks.org vs dev++ ?
Codeblocks не пользовался, а впечатления от Dev++ отрицательные. Периодически вылетает с access violation, настройки компилятора устанавливает неправильно и т.п.