Идея такая. Для PIC'ов насколько я знаю существует только одна реализация языка Си - и она платная. Также я практически не встречал реализаций Си++ для микроконтроллеров, а некоторые из его возможностей ой как хочется иногда задействовать.

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

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

Пару дней назад к идее решил присоединиться quarz.

Всю информацию по разработкам буду выкладывать здесь, надеюсь кому-нибудь будет полезно. Если у кого есть какие-то идеи, которые хотели бы увидеть в Протоне - пишите. 

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

Ух ты...
Поподробнее бы узнать, как это - ассемблер с элементами C.
Чего мне не хватало, когда работал на асме 51
- так это автоматизации распределения памяти под переменные.

Цитата(Crait @ 5.8.2005, 17:40)

Поподробнее бы узнать, как это - ассемблер с элементами C.

На этих выходных попытаюсь оформить

Цитата(Crait @ 5.8.2005, 17:40)

Чего мне не хватало, когда работал на асме 51 - так это автоматизации распределения памяти под переменные.

По-подробней пожалуйста.

прочёл название как "Высокоуровневый язык Питон для микроконтроллеров PIC". %)) аж дыхание перехватило. %)

(абзац. нельзя столько времени на работе проводить...)

Модератор: попрошу не флеймить...

Итак. Вот примерно то, что будет в первой сборке через неделю (альфа версия).

Во-первых. Протон - не столько самостоятельный язык, сколько надстройка над ассемблером. Все программы написанные на ассемблере без проблем компилируются как протоновские с одной - на синтаксис (каждая строка кода заканчивается ';' + Си-коментарии).

Вот пример программы на Протоне:

Код

orgd 0x03; byte_t Status;// Данная переменная располагается по адресу 0x03 (STATUS регистр) /* Демонстрационная программа */ main(byte_t Ch)// Это не то, что вы думаете :-) {     Status = Ch;// Г-гы :)) } orgc 0;// Точка запуска программы - ЗДЕСЬ!.. goto 10; orgc 4;// Если память не изменяет - это прерывания... swapf Status, 0// Хулиганим.... orgc 10; Status.bits[5] = 1;// У кого-то сейчас глаза на лоб полезут... :-) // ... и я даже догадываюсь кто это будет ... main(0xAA);// ХЛОП!.. goto pc-1;// Переход на прошлую строку кода :))

Как видно из этой демонстрационной совершенно бессмысленной программы, точка старта программы - это, отнюдь, не функция main Это первая команда программы (pc=0). Кроме того, стандартный тип byte_t (байт) оказывается несколько нестандартным В Протоне все базовые типы ничем не отличаются от определяемых пользователем, короме как тем, что их нельзя убрать. Но поддержку определяемых типов через неделю обещать не могу.

pc при использовании команды goto - это номер строки кода (строки заканчиваются точкой с запятой, не текстовые строки имеется ввиду). В определении функции можно не указывать возвращаемый параметр если функция ничего не возвращает. Вот, вообщем и всё, что я пока напридумывал

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

Это сообщение отредактировал(а) ManiaK - 8.8.2005, 15:35

ManiaK хорошая затея. Одно время разрабатывал идею макро-ассемблера для x51, но идея оказалась замученой и не выжила.

А одной из причин была как раз не переносимость. Птому как не хочеться знать где у контроллера точка входа, как реализованны прерывания и т.д. Ещё большой проблемой был вызов существующих функций/процедур, написанных на асме. Каждый человек пишет по своему, кто то любит получать аргументы в регистрах, кто то обьявляет функции без рекурсии и "бронирует" место под аргументы, кто то пользуеться стеком(чего под PIC'ом нет...). Нужна была схема, описываемая формальным языком. А затем можно было вызывать: procedure(ar1, arg2, arg3): schema(keil c);
Конструкция должна разбираться в момент компиляции, потому если функция меняеться(либа компилилась другим компилером), то схему тоже нужно менять.


Вообщем складывай идеи, если нужна помощь(например задокументировать твой код, мануал и т.д.), с радостью

Цитата

По-подробней пожалуйста

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

Вот ещё что было бы полезно : автоматический анализ используемых
подпрограммами регистров (с учётом вызовов всех
используемых в ней подпрограмм).

ИМXО для микроконтроллеров полезны такие фичи как:

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

Такой язык не удобен для компов, но удобен для микроконтроллеров, от простых, до сложных.

Цитата(Sardar @ 9.8.2005, 00:23)

если нужна помощь(например задокументировать твой код, мануал и т.д.), с радостью

Именно этим мне заниматься некогда, да и не умею я. Учту

Crait В pic12f675 стека как такового нет, поэтому эту идею я буду откатывать уже на нём. Только её надо доработать, передаваемые параметры для меня тоже пока проблема.

Цитата(Crait @ 9.8.2005, 04:43)

Вот ещё что было бы полезно : автоматический анализ используемых подпрограммами регистров (с учётом вызовов всех используемых в ней подпрограмм).

А для чего? Просто как информация кодеру?..

Цитата(Sardar @ 9.8.2005, 05:26)

процеруды и функции, а не просто функции

Если процедура от функции отличается только тем, что ничего не возвращает, то main на примере выше - процедура Кстати я подумал, там надо будет вставлять определитель func иначе трудно будет отделить в некоторых местах объявления переменных от деклараций процедур...

Цитата(Sardar @ 9.8.2005, 05:26)

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

У меня хитрость такая. Директива orgd перемещает каретку компилятора на нужный адрес. Допустим пишем - "orgd 0x03;". Каретка сдвинулась на третий адрес. После этого первая байтовая переменная, объявленная ниже будет лежать по адресу 0x03 (для pic12f675 это регистр STATUS). При объявлении переменной каретка сдвигается выше по адресу на размер переменной. Если мы следом объявим ещё одну байтовую переменную она будет лежать по адресу 0x04. То есть: 1. Мы не забиваем голову себе распределением переменных; если не нужно указывать конкретный адрес для каждой - указываем только для первой; 2. Мы имеем отличную возможность определять для каждой переменной свой адрес. По-моему удобно. Но для статических переменных, в динамические я пока вообще не лезу, это бы реализовать...

Цитата(Sardar @ 9.8.2005, 05:26)

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

Да, это было бы удобно но нужно подумать как при этом не нарушить "совместимость" с асмом.

Цитата(Sardar @ 9.8.2005, 05:26)

"Арифметика памяти" как в C

Не очень понял. Это ты про указатели?..

Цитата(ManiaK @ 9.8.2005, 10:25)

А для чего? Просто как информация кодеру?..

Ну да. Чтоб знать, какие регистры портятся.

Цитата(Crait @ 9.8.2005, 13:52)

Ну да. Чтоб знать, какие регистры портятся.

Это скорее функция IDE, а не компилятора. Хотя можно писать эту инфу в lst файл.

Цитата(ManiaK @ 9.8.2005, 13:24)

Это скорее функция IDE, а не компилятора.

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

Цитата(ManiaK @ 9.8.2005, 09:25)

Если процедура от функции отличается только тем, что ничего не возвращает, то main на примере выше - процедура

Синтаксис может быть каким угодно, пусть визуально процедура от функции не отличаеться, допустим function void main(...

При этом если мы пишем public int myvar=main(...) - то компиплер должен ругнуться.

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

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

Представим случай, есть средненкий микроконтроллер(х51, DS80320 память внешняя), в нём "загруженна" либа с общим функционалом и кооперативным менеждером задач. Всё это написанно на асме. Контроллер читает несколько сенсоров, простенько сжимает полученную инфу и пишет на какой нибудь большой флеш. Потключен какой нибудь сетью к общей системе, если что то не ладно, отсылает сигнал тревоги.

Пишем пару задачь/тредов, что будут выполнять работу. Вдруг упираемся что способ вызова твоей процедуры отличаеться от принятого в "системной" либе. Можно писать вызов на асме, но так придёться для всех функций, тогда смысла писать на "высокоуровневом" языке особо нет. Для этого нужны схемы возовов и получения результата. Функция может отдать не только один тип или массив, но и tuple, часть которого в регистрах, часть в памяти, ещё часть в стеке

Вот эту идею я не развил

Цитата(Sardar @ 9.8.2005, 17:53)

Вот эту идею я не развил

А надо Именно в этом весь смысл нового языка программирования. Я подумаю...

Цитата

Для PIC'ов насколько я знаю существует только одна реализация языка Си - и она платная.

а про GCC забыли? Я им пользуюсь под AVR, но под PIC его тоже можно скомпилить.