каким же образм, smalcom ? У пиков совсем другие команды, более того, их всего 35.

все предельно просто. берешь GCC и компилишь его(ну там еще binutils надо), так вот если надо для AVR , то пишешь в configure: --target=avr, а для PIC'ов --target=pic. И юзаешь себе C

да уж по поводу gcc я поторопился , но есть выход из положения. Первый - это линки нарытые мной в смущенном состоянии в сети

http://sdcc.sourceforge.net
http://anyc.sourceforge.net

Второй более глубокий но рулезный и думаю равноценный написанию ПРОТОН'а - когда ставица GCC ему через опции передаеца для какого процессора он будет создавать код, так вот можно посмотреть что он делает для AVR, сравнить архитектуры PIC и AVR и возможно чего дописать и нам хорошо и весь мир OpenSource будет благодарен(надеюсь).

smalcom Спасибо за ссылки, но задача именно разработать качественно новый язык специально для микроконтроллеров. Это интересно
Кстати, обсуждение теперь лучше вести тут: http://forum.qpp.ru/index.php?showtopic=3
Здесь всё же форум по решению проблем, а не разработке проектов. Эта тема скоро будет закрыта.

Модератор: тема закрыта. Всё обсуждение и вся информация о Протоне - по ссылке, указанной в посте выше.

Sardar, я только сейчас понял, о чём ты говоришь насчёт вызовов функций и то - не уверен что полностью! Это произошло только тогда, когда я уже сам начал нащупывать тоже направление. С этого места по-подробней.

1. Для микроконтроллеров сейчас необходим не ещё один Си-подобный язык, а язык, основанный на обобщении Ассемблера.

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

2. Необходим более мощный препроцессор, нежели тот, что заложен в Си.

Если шаблоны в Си++ являют собой обобщение высокоуровневых операций (над типами главным образом), то в Протоне необходимо развить механизм автоматизации написания кода Ассемблерного. Иначе - все те механизмы, которые запускаются на этапе компиляции и ни в каком виде не фигурируют в конечном бинарном коде. Такие механизмы не тратят никаких ресурсов, однако на их основе часто можно организовать очень полезные в хозяйстве вещи, такие как автоматизированное размещение переменных (точнее того, что будет называться переменными; реально никаких переменных в Протоне, как и в Ассемблере нет, конечно) в оперативной памяти. На препроцессоре можно построить целый субязык. Сейчас у меня всё это в голове крутится, но на бумаге изложить нормально не могу, ухватить за хвост мысль, так сказать



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

Это сообщение отредактировал(а) ManiaK - 21.1.2006, 00:51

Идея всё-таки не умерла. Хотя в состоянии плачевном.

1. Лично мне кажется, что язык Си слишком высокоуровневый для микроконтроллеров.
2. Не под все embedded-платфоры есть бесплатные легальные трансляторы Си->Asm.
3. Ни один из существующих компиляторов, по моим данным, не протестирован современными научными методами.

Актуален ли хотя бы для посетителей этого форума данный вопрос?

Со своей стороны могу предложить:
    - Общение с фирмами-производителями микроконтроллеров от имени достаточно известного зарубежом Института Системного Программирования РАН.
    - Современные научные методы верификации нового компилятора

По деталям нового языка:
    1) Си-подобный (но не клонированный) синтаксис
    2) Возможность на уровне языка определять способ передачи аргументов в функции
    3) Однозначное соответствие между кодом на Языке и двоичным кодом (местоположение объектов, их размер, формат представления, ...)

Возможные платформы: PIC, ATmega, ATxxx, Fujitsu mb90xxx.

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

Прямая работа с памятью всё таки не очень хорошо. Моя идея выродилась в байткод, который обращаем в нативный при каждой сборке проекта.  Байткод самодостаточен, высокоровневый. Собирает память в сложные структуры, определяет для них операции. Свойства (аттрибуты) переменных и кода отслеживаются на манер, как Haskell отслеживает типы.

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

Код разделён на функции, функция изменяет своё поведение только согласно переданным аргументам (никаких глобальных переменных). Для собственных функций передача аргументов никак не оговаривается, система просто предоставит их в коде. Функция не рекурсивна, пока не будет отслежен сценарий, когда она будет вызвана рекурсивно. Отсюда ясно, что функции не являются конкретными процедурами, которе можно вызвать из левой asm'овой либы, конкретный код генерится из тела функции только ели он был использован, поэтому функция не имеет физического адреса. При генерации кода будут собраны все используемые функции, эквивалентные выражения будут собраны в ообщий код, отслеживается общая память (если две функции никогда не будут вызваны вместе, то память под их аргументы можно расшарить). Плюсы: код всегда максимально оптимизирован. Минусы: process image всегда меняется.

Функциям можно придать такие свойства как постоянный адрес, либо то, что она может быть вызвана из любого места (такая функция всегда будет присутствовать в process image, доступна для любых либ). Это заставит сборщик выделять экслюзивные ресурсы для этих функций.

Типов данных нет, на твой манер собираются сложные структуры массивов байти других структур. Можно всегда "увидеть"/применить какой либо тип к любому участку структуры. К структуре определяются операции над этой структурой,  код задаётся на asm'е для конкретного девайса. Так получаются int'ы, float'ы и прочие типы.

Идея была большая, но умерла как только перестал работать с микроконтроллерами. По любому новый язык никому не будет нужен, будут плеваться, извращаться, но использовать C - так сказало руководство 
Может поэтому ушёл в обычный прикладной софт, тут креатива больше.

Добавлено через 3 минуты и 26 секунд

Это плохо, теряется поле для оптимизации. Лучше явно объявлять функции, что могут быть использованы вне системы. Всё остальное собирается и упрощается до минимума, достаточного для вычисления результата. Реальные функции могут "исчезать" (вырождаться, вставляться inline), а могут появляться новые (на манер шаблонов в C++).

Забыл пояснить в предыдущем моём сообщении: сейчас мой взгляд на то, каким должен быть язык программирования для embedded-платформ (здесь: для платформ с катастрофически малым запасом ресурсов и относительно небольшой скоростью работы), совершенно иной, если сравнивать его со взглядом того времени, когда я начал этот топик. Следует рассматривать только последнее сообщение.

Sardar, понял очень смутно твою идею. С переменными понял.



Что такое - собственная функция? И что значит - просто предоставит их в коде? Поясни, пожалуйста подробней.



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



Я тоже сейчас занимаюсь "прикладным софтом", но всё же хотел бы вернуться к контроллерам. Оно мне роднее, да и в России, похоже, начинается подъём мелкого предпринимательства, значит и частные рукодельцы нужны будут. А имея возможность прикрыться дипломом и повторить подвиг Торвальдса, написав компилятор для диплома и для себя одновременно, было бы недурно, согласись? 

Добавлено через 1 минуту и 37 секунд
Я всё же в раздумьях относительно верности вектора моих размышлений, поэтому, Sardar, жду от тебя пояснений.

Это сообщение отредактировал(а) ManiaK - 4.3.2008, 16:26

Функция определённая на этом (новом) языке и не доступная как API другим (внешним, чужим) либам. Компилятор может делать с ней всё, что угодно, упростить, создать реальную функцию, вставить блоком в другую функцию, выполнить на этапе компиляции и заменить константой и т.п.


Расчитать нужен ли конкретный аргумент, как его лучше передать в функцию, выделить под него ресурсы. Зависит от железки, для тебя же это просто аргумент, которым можно пользоваться. К примеру можно оптимизировать использование функции, если точно известно, что она не меняет свои аргументы (если в языке есть INOUT аргументы).


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



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

IMHO язык должен быть декларативным, используются общие символические выражения, а вот на этапе сборки уже из общих алгоритмов генерится конкретный под железку код. При особо агрессивной оптимизации ловить в дебаггере будет нечего, трудно будет понять окончательный хитро-переплетённый асмовый исходник.

Sardar, мы работали, видимо, в диаметрально противоположных углах embeded-области. Я занимался преимущественно микроконтроллерами с настолько низкими запасами ресурсов, что не то, что сотни - пары десятков функций уже будет много. Программы для таких кристалло обычно представляют собой вполне обозримый код, полностью обозримый. И проблема переносимости тут так остро не стоит. Зато проблемы скорости и миниатюрности - на первом плане!



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



Теперь понятно. Тогда такой вопрос: какими контроллерами ты пользовался, когда разрабатывал этот язык, и какие задачи выполнял?

ManiaK я тож на досуге разрабатываю язык для контроллеров. Именно твоя идея близка..  Си расширенный низкоуровневыми возможностями для оптимизации.

Например иногда компилятор предоставляет выбрать как оптимизировать.. по размеру или по скорости. 
Но часто есть функции которые выполняются чяще других, а другие вобще редко вызываются и некритичны к скорости.

Идея такая заставить кампилить функции поразному..

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

Мини-вебсервер на eZ80 проце, вернее этот девайс. Ты прав, там с ресурсами действительно посвободнее чем в pic'е... 
С железкой идёт RTOS, каркас вебсервера и всякие полезные либы. Нужен был темплейтер для страниц, нормальная, очень компактная работа со строками (константы, ссылки на блоки, никаких копирований массивов символов) + нормальная среда для разработки простых XML сервисов. Начали с разработки языка, к середине забили, написали на чистых C'ях + собственные либы из движка языка.