Эксперимент

[lvd]

Человек в роли оптимизирующего компилятора может побороться лишь со старыми компиляторами 80-х годов - большого прироста скорости это не даст, а вот времени убъет немерянно

Ну не скажи. Ни один компилятор сей не догадается на з80 юзать стек как попало (даже скорее как обычно =). Для всяких "недо"процессоров типа з80, мцс51, пик, авр вряд ли хоть один компилятор сравнится по извращенским оптимизациям с человеком =). А вот для таких монстров, как например ppc - компайлеры могут уже и порулить человека. Как-то я видел доку от мутороллы - что надо менять в компайлерах, чтоб код оптимизировали не под g3, а под g4. Там столько разных заморочек, незнание которых приводит к СОВСЕМ не оптимизированному коду.

[Advertiser]

[Shaos]

Ну не скажи. Ни один компилятор сей не догадается на з80 юзать стек как попало (даже скорее как обычно =). Для всяких "недо"процессоров типа з80, мцс51, пик, авр вряд ли хоть один компилятор сравнится по извращенским оптимизациям с человеком =). А вот для таких монстров, как например ppc - компайлеры могут уже и порулить человека. Как-то я видел доку от мутороллы - что надо менять в компайлерах, чтоб код оптимизировали не под g3, а под g4. Там столько разных заморочек, незнание которых приводит к СОВСЕМ не оптимизированному коду.

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

[dhau]

Для всяких "недо"процессоров типа з80, мцс51, пик, авр вряд ли хоть один компилятор сравнится по извращенским оптимизациям с человеком =)

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

[SfS]

Мое мнение - операционки надо писать на С и только на С. Разумется, после отладки - критичные места надо оптимизить ручками на асме.
Мнение основано на том, что в свое время я разрабатывал специфичные реал-таймовые микро-операционки для AVR, сейчас реал-таймовую разрабатываю операционку для ядер ARM. Уже работает уровень драйверов. Сейчас вожусь с менеджером задач и файловым уровнем. Еще пришлось работать с операцонкой для 196го писанной на асме. Кошмар!

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

Времени экономится - масса.

А с нуля раскорячивать идеи в ассемблер - никакого времени не хватит. Убъешь массу времени на "супер-оптимальный" кодинг, а потом окажется, что вся структура системы или части системы - плохо продумана и надо все переделывать.

Это мое ИМХО.

[GriV]

Мое мнение - операционки надо писать на С и только на С. Разумется, после отладки - критичные места надо оптимизить ручками на асме.
Мнение основано на том, что в свое время я разрабатывал специфичные реал-таймовые микро-операционки для AVR, сейчас реал-таймовую разрабатываю операционку для ядер ARM. Уже работает уровень драйверов. Сейчас вожусь с менеджером задач и файловым уровнем. Еще пришлось работать с операцонкой для 196го писанной на асме. Кошмар!

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

Времени экономится - масса.

А с нуля раскорячивать идеи в ассемблер - никакого времени не хватит. Убъешь массу времени на "супер-оптимальный" кодинг, а потом окажется, что вся структура системы или части системы - плохо продумана и надо все переделывать.

Это мое ИМХО.

Целиком поддерживаю коллегу.
Осталось только оптимизирующий C компилятор где нить нарыть

[Alchemist]

Целиком поддерживаю коллегу.
Осталось только оптимизирующий C компилятор где нить нарыть

Очень интересно было бы узнать чего вам не хватило в SDCC. (это серьезный вопрос, без иронии )

[SfS]

Целиком поддерживаю коллегу.
Осталось только оптимизирующий C компилятор где нить нарыть

Я во флейме писал - есть свободный кроскомпилер. Правила оптимизации можешь писать к нему сам, если стандартных не хватает. Оптимизирует на уровне ассемблерного исходника. Для обкатки идей - более чем достаточно.

[hex]

Суть эксперимента такова - написать ОС для компьютера семейства ZX Spectrum и эго клонов. … Есть работающий пример графического интерфеса …

Мое мнение - операционки надо писать на С и только на С. … Это мое ИМХО.

Какие графические интерфейсы, какой C? Вы что и зачем писать хотите, сами понимаете? Операционка ради операционки – это, конечно, хороший способ набраться опыта в работе с текстовым редактором, но разве она не должна решать существующие проблемы? Кто-то в этом форуме уже предлагал добавить в ПЗУ несколько RST для нормальной работы с памятью и файловой системой, вот уж что действительно было бы полезно. А какая польза будет от новой графической запускалки?

[SfS]

Какие графические интерфейсы, какой C? Вы что и зачем писать хотите, сами понимаете? Операционка ради операционки – это, конечно, хороший способ набраться опыта в работе с текстовым редактором, но разве она не должна решать существующие проблемы? Кто-то в этом форуме уже предлагал добавить в ПЗУ несколько RST для нормальной работы с памятью и файловой системой, вот уж что действительно было бы полезно. А какая польза будет от новой графической запускалки?

Я уже писал, почему С. Потому что пока ты на асме отладишь все эти RST дополнительные - у тебя столько времени уйдет - что все надоест. А "нормальная работа с памятью и файловой системой" вообщето и является одними из основных функций почти любой ОС. Что значит "добавить несколько RST" ? Одного достаточно. Но дело не в RST. Дело в том, что ОС обеспечиват прежде всего работу с разнородным оборудованием, устраняя проблемы несовместимости. Грубо говоря - программа пользователя обратилась к ОС с запросом - "дай мне 2к памяти", ОС должна вернуть адрес выделенного блока в какойто форме или код ошибки, если памяти нет. А уж на какие там порты подключено переключение страниц памяти и в какие окна и как все это делается - это сугубо интимные проблемы дрпайвера памяти, установленного на данной ОС в данной машине. И они никак не должны касаться программы пользователя.
Или работа с файлами - на кой программе юзера знать - на какой физической файловой системе лежит файл с данными игрушки ? Пусть эти проблемы мучают ОС. А программа пользователя должна только уметь сказать ос "myfileid=open("/games/mysupergame.dat",O_RDONLY):read(myfileid, &buffer, size);close(myfileid); - все !!! Остальное - интимные проблемы драйверов файловой системы и драйверов устройств !

Все нормальные компы так работают....

[DizZy]

чем вам IS-DOS не угодил? его б лучше дорулить...