Человек в роли оптимизирующего компилятора может побороться лишь со старыми компиляторами 80-х годов - большого прироста скорости это не даст, а вот времени убъет немерянно :wink:Цитата:
Сообщение от Vitamin
Вид для печати
Человек в роли оптимизирующего компилятора может побороться лишь со старыми компиляторами 80-х годов - большого прироста скорости это не даст, а вот времени убъет немерянно :wink:Цитата:
Сообщение от Vitamin
Ну не скажи. Ни один компилятор сей не догадается на з80 юзать стек как попало (даже скорее как обычно =). Для всяких "недо"процессоров типа з80, мцс51, пик, авр вряд ли хоть один компилятор сравнится по извращенским оптимизациям с человеком =). А вот для таких монстров, как например ppc - компайлеры могут уже и порулить человека. Как-то я видел доку от мутороллы - что надо менять в компайлерах, чтоб код оптимизировали не под g3, а под g4. Там столько разных заморочек, незнание которых приводит к СОВСЕМ не оптимизированному коду.Цитата:
Сообщение от Shaos
Даже для z80 есть компиляторы, которые аргументы функций не через стек передают (точнее не все через стек), а по мере возможности через регистры. Хотя может критические участки кода и можно человеку писать, например внутренности циклов или разворачивать циклы работы с экраном и т.д. - где выигрышь в одном проходе не единицы тактов может дать существенный прирост в цикле.Цитата:
Сообщение от lvd
Никто не спорит. Но к времени когда ты докончишь оптимизировать ls и chmod, миром уже будут управлять органические роботы-киборги, а земля будет эксклюзивной курортной зоной для туристов из альдебарана :)Цитата:
Сообщение от lvd
Мое мнение - операционки надо писать на С и только на С. Разумется, после отладки - критичные места надо оптимизить ручками на асме.
Мнение основано на том, что в свое время я разрабатывал специфичные реал-таймовые микро-операционки для AVR, сейчас реал-таймовую разрабатываю операционку для ядер ARM. Уже работает уровень драйверов. Сейчас вожусь с менеджером задач и файловым уровнем. Еще пришлось работать с операцонкой для 196го писанной на асме. Кошмар!
В общем асм - это не для больших проектов. Однозначно. Лично мне по душе такой подход:
- Разрабатывается структура системы (я за основу принял UNIX-идеологию).
- Пишется на С вся ОС в общем виде.(особенно удобно на С описание структур, без которых ни одна нормальная ОС не обходится).
- Все отлаживается (особенно попистая отладка - это менеджеры памяти и задач).
- Выделяются узкие по производительности места.
- Переписываются узкие места (возможно на асме), оптимально.
Времени экономится - масса.
А с нуля раскорячивать идеи в ассемблер - никакого времени не хватит. Убъешь массу времени на "супер-оптимальный" кодинг, а потом окажется, что вся структура системы или части системы - плохо продумана и надо все переделывать.
Это мое ИМХО.
Целиком поддерживаю коллегу.Цитата:
Сообщение от SfS
Осталось только оптимизирующий C компилятор где нить нарыть :)
Очень интересно было бы узнать чего вам не хватило в SDCC. (это серьезный вопрос, без иронии :))Цитата:
Сообщение от GriV
Я во флейме писал - есть свободный кроскомпилер. Правила оптимизации можешь писать к нему сам, если стандартных не хватает. Оптимизирует на уровне ассемблерного исходника. Для обкатки идей - более чем достаточно.Цитата:
Сообщение от GriV
Цитата:
Сообщение от spectrum
Какие графические интерфейсы, какой C? Вы что и зачем писать хотите, сами понимаете? Операционка ради операционки – это, конечно, хороший способ набраться опыта в работе с текстовым редактором, но разве она не должна решать существующие проблемы? Кто-то в этом форуме уже предлагал добавить в ПЗУ несколько RST для нормальной работы с памятью и файловой системой, вот уж что действительно было бы полезно. А какая польза будет от новой графической запускалки?Цитата:
Сообщение от SfS
Эээ - по поводу оптимизации лс и чмода - это к Робусу =)))Цитата:
Сообщение от dhau