Как лучше писать Опции

[npopok]

Keil mVision.Соответственно, есть куча разных функций.Одни для одного,другие для другого, где то они пересекаюся и не редко.В общем, как обычно.Вот вопрос-стоит ли собирать их в разные си файлы и делать кучу extern-ов, или лучше все-таки без особой необходимости этого не делать.Может, надо искать золотую середину?Есть ли какие-нибудь критерии,кроме здравого смысла? На что это влияет?Спасибо

[npopok]

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

[MrYuran]

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

Встречный вопрос: а засчёт чего?
Компилятор транслирует исходники функций в объектный код, линкер собирает из объектов файл прошивки. По большому счёту, им без разницы, в одном файле находятся функции или в 10. (20,50).
Скорость и свободное место - понятия взаимоисключающие.
Нужна скорость - inline и unrolling, соответственно теряем место.
Не хватает места - обратная ситуация, приходится жертвовать скоростью.

[defunct]

Компилятор транслирует исходники функций в объектный код, линкер собирает из объектов файл прошивки. По большому счёту, им без разницы, в одном файле находятся функции или в 10. (20,50).

Ну разница все-таки есть.
Если все в одном файле, и функции объявлены как static. Компилятор может сделать более эффективный код (например повставлять инлайнов там где это не указано явно, повыбрасывать неиспользуемые функции, заменить "дальний" вызов на "ближний" для процессоров где это актуально и .т.п.). С т.з. оптимизации компилятору лучше сразу видеть весь код в одном файле, потому что линкер ничего оптимизировать не будет.

Только читаемость когда "все в одном" будет никакой.

[ReAl]

Если все в одном файле, и функции объявлены как static. Компилятор может сделать более эффективный код (например повставлять инлайнов там где это не указано явно, повыбрасывать неиспользуемые функции, заменить "дальний" вызов на "ближний" для процессоров где это актуально и .т.п.). С т.з. оптимизации компилятору лучше сразу видеть весь код в одном файле, потому что линкер ничего оптимизировать не будет.

С gcc (не знаю просто, как с другими) можно при большом желании и на ёлку влезть, и всё такое прочее.
Если указать в командной строке все .c файлы проекта сразу и добавить ключики -combine (объединить промежуточное представление всех файлов в одно целое) и -fwhole-program (и это объединение - вся программа), то он ведёт себя так, как якобы все функции этого общего представления статические, т.е. снаружи "этого всего" никому не нужны и проводит все эти оптимизации (выбрасывание ненужного, inline-подстановки используемого единственный раз либо достаточно мелкого). Для "окончательного релиза" это может и есть смысл делать.

А вот замены вызовов на ближние делает как раз линкер, причём в том числе при линковке нескольких объектников и делает это в том числе со включенными из бибилиотек модулями.
Ключ --relax

[defunct]

-fwhole-program (и это объединение - вся программа), то он ведёт себя так, как якобы все функции этого общего представления статические, т.е. снаружи "этого всего" никому не нужны и проводит все эти оптимизации

Вот это зачОт! Спасибо, не знал о такой возможности.