Микроконтроллеры

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

void main(void)
{
    unsigned long i;

    for (;;)
    {
        for (i=10000; i; i--);

        Flag = ~Flag;
    }
}

Проверьте, если несложно, теперь -- какие цифры получатся. Разрыв между ними должен сократиться, хотя предполагаю, что sdcc будет все таки опережать почти в два раза по скорости. Как я уже говорил ранее, под кейл нужно немного "подстроиться" и помогать ему делать оптимальный код. Хотя это тоже косвенный показатель, что часто с оптимизациями у кейла бывает слабовато. Аналогично предлагаю преобразовать тест2, поменяв направление цикла:

void main(void)
{
  unsigned long i;
  long a=65539;
  ...
  for (;;)
  {
    for (i=100; i; i--)
      a=a*a;
    Flag=~Flag;
  }
}

Также интересно какие будут цифры. (Целесообразность использования long во втором примере под большим вопросом). Помните, что ничто так не улучшает показатели, как методика измерений. Из ваших двух тестов можно сделать только один вывод: оптимизация циклов для итератора цикла типа long в sdcc работает лучше чем в кейле. Хотя делать на основании только этих двух тестов вывод, что sdcc во всем круче кейла я бы не стал. Хотя уже видно, что sdcc не просто поделка. Это радует. Предлагаю вам запустить более сложный тест. Это стандартный тест whetstone, который оценивает качество оптимизации и качество работы с плавающей точкой. Я предлагаю этот тест, просто потому что он у меня валялся под руками. Есть еще аналогичный тест для целочисленной арифметики, можно поискать по слову drystone (если я не ошибаюсь). Исходный текст теста я положил в файлообменник (http://upload.caxapa.ru/) файл whetstone.c. Скомпилировать его для sdcc мне не удалось, поэтому предлагаю вам продолжить опыты с sdcc. Там же в файлообменннике я положил несколько модифицированный whetstone-sdcc.c, который учитывает некоторые неприятные особенности sdcc, из-за которых стандартный текст не компилируется в нем. Однако даже в таком виде я не смог собрать конечный испольняемый файл, линкер выдает такую ошибку: ?ASlink-Error-Could not get 133 consecutive bytes in internal RAM for area DSEG. Т.е. sdcc не смог уложить все переменные во внутреннем ОЗУ. Вот это уже грустный результат, потому что кейлу понадобилось только 104 байта и 2 бита, при компиляции под классический 8052. Если вы сумеете слинковать его и сравнить кейловые результаты с sdcc, то будет очень интересно. Также очень интересно знать не только скоростные параметры, но еще и размеры получающейся программы: сколько она занимает ROM и RAM. Кстати, про кейл. 6.5 -- это уже вчерашний день. Качайте с сайта кейла последнюю бесплатную версию (7.50), потом через почту спросите у меня лекарство - я дам. Пролеченный кейл не имеет проблем с float. А с CygnalIDE насколько я знаю поставляется урезанная версия кейла, которая не дает использовать плавающую точку.