Администрация форума не несёт ответственности за достоверность информации и оставляет за собой право редактировать или в особых случаях даже удалять посты без предупреждения. Спасибо за понимание.

Программирование ATMEL в BASCOM.

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Программирование ATMEL в BASCOM. » Исходники » Компилятор


Компилятор

Сообщений 1 страница 30 из 49

1

А не замахнуться ли нам на Вильяма, понимаете ли, нашего Шекспира?

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

Предпосылки этого дела:

1. Практически вся информация по языку, компилятору, практике программирования доступна только на английском языке. Это нехорошо, т.к. повышает порог вхождения.
2. Компилятор платный. Бейсик должен быть бесплатен по определению для широких масс населения.
3. Язык очень простой, тем более его версия для микроконтроллера очень близка к ассемблеру, что упрощает реализацию.
4. Формат объектного файла AOF мне уже знаком и пока можно использовать его для отладки кода.
5. У нас уже есть готовый пример для подражания (bascomp).

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

Подход вижу таким:

1. Пишем программу на bascom-avr в виде одной функции/оператора/команды.
2. Компилируем, изучаем ассемблерный листинг.
3. Повторяем команду в своём компиляторе.
4. Переходим к следующей функции из списка и опять возвращаемся к п. 1.

Пока можно повторить архитектуру bascomp один в один, а потом, посмотрев на плюсы и минусы, доработать.

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

О русской транскрипции служебных слов Алгола 60. /Рукописный и машинописный варианты./

http://img.radiokot.ru/files/4453/thumbnail/d90a0j8mh.gifhttp://img.radiokot.ru/files/4453/thumbnail/d90bd8sgl.gif

В качестве среды разработки можно взять любой .Net язык, к примеру, VB.Net.

Отредактировано uni (2014-06-15 09:32:27)

+1

2

uni написал(а):

Я тут подумал, почему бы не написать свой собственный компилятор бейсика

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

uni написал(а):

2. Компилятор платный. Бейсик должен быть бесплатен по определению для широких масс населения.

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

uni написал(а):

5. У нас уже есть готовый пример для подражания (bascomp).

Но синтаксис баскома лучше не использовать. Мне больше нравится синтаксис PB - проще и понятнее и без лишнего. Можно его взять за основу.

uni написал(а):

1. Пишем программу на bascom-avr в виде одной функции/оператора/команды.

Тогда уж лучше брать за основу FastAVR.
Он кстати, в асм переводит исходник и компилирует его используя avrasm32.exe.

uni написал(а):

В качестве среды разработки можно взять любой .Net язык, к примеру, VB.Net.

Не думаю что стоит использовать .NET язык для этого. Даже у .NET языков компилятор напитан на другом ЯП. Это о чем-то да говорит.
Нужно компилировать в натив, чтобы работало без установки чего либо даже на Win9x ну и на Linux и MacOS X в перспективе, если все получится.

+1

3

я был вынужден писать на "языках" постсоветских разработок - это жуть!
лично меня дико раздражает "ЕСЛИ переменная = 10 ДЕЛАТЬ ПЕРЕХОД 100"
да и 1С - та же фигня, в ней тоже всё кириллицей (по крайней мере, лет 8 назад так было)

никто делать ХОРОШИЙ продукт "за так" не станет. В сети десятки сред, где заведено 1-2 МК, и усеченные команды, при минимуме библиотек. И брошены авторами.
Я согласен платить за продукт, если я этим зарабатываю

автору темы:
Вы прекрасно владеете написанием компиляторов?
знаете как Отче наш ассм АВР?
имеете за плечами офигенный опыт разработки ПО для ПК и МК ATMEL AVR?
согласны добавлять десятки библиотек под новое железо?
готовы выложить исходники своего детища в Сеть? и морально спокойны, видя, как возьмут ваш труд, причешут, облагородят и сделают свой продукт и за деньги?
у вас много свободного времени на написание, отладки сотен модулей своего ПО? думаю, годика два надо...

полностью согласен с Петром во всех вопросах и ответах :)

Отредактировано Александр Д. (2014-06-15 11:10:42)

0

4

Ну, как бы владею всем :) Я написал диззассемблер avr, чего ещё нужно (знаю все 143 инструкции)? Исходник выложен в сети: objdump. Берите, пользуйтесь, если образования хватит ;)

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

Если будет сообщество, то оно и напишет библиотеки, был бы инструмент простым, понятным, удобным.

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

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

Синтаксис bascom пока можно оставить, чтобы отладить процесс, а потом можно уже думать как сделать лучше. Сначала нужно повторить что есть, чтобы было с чем сравнивать.

У меня есть идея как сделать распределённую сеть контроллеров, чтобы была возможность отлаживать онлайн непосредственно исполняющийся код в каждом отдельном мк. Если вы когда-нибудь видели как программируют ПЛК, то знаете, что там есть среды разработки, которые позволяют в режиме реального времени заглядывать внутрь ПЛК и отслеживать его работу. Я хочу сделать примерно то же, но в маленьких размерах в целях домашней (малой) автоматизации. Если я напишу свой компилятор, то и симулятор к нему тоже смогу написать. Дальше можно использовать, к примеру, modbus, объединить устройства в сеть. Бейсик (на русском) использовать как язык автоматизации, каждое устройство снабдить возможностью управления по JTAG.

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

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

+1

5

uni написал(а):

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

Попробуйте сделать что-то простое для начала, типа объявления переменных, работу с ними (сложение, вычитание, умножение, деление и т. д.), а так же циклы и функции. Если это получится, то можно думать о продолжении работы над компилятором. Транслировать пока можно в асм и компилировать используя avrasm32.exe.

Только лучше не использовать .NET язык. Такие языки может и хороши при разработке, но для конечного пользователя они создают лишние проблемы. Не нужно быть программистом-эгоистом. Нужно также думать об пользователях вашей программы. Ведь какая она хорошая бы не была, если ее использование затруднено, то это сводит на нет ее достоинства. За примером далеко ходить не надо. Ваша программа objdump у меня не запускается.

Для запуска этого приложения сначала необходимо установить одну из следующих версий .NET Framework:v4.0.30319
Обратитесь к издателю приложения за инструкциями по получению соответствующей версии .NET Framework.

Ставить только из-за нее .NET 4 не вижу смысла.
Тоже может получится с вашим компилятором.

Отредактировано Пётр (2014-06-15 12:27:58)

0

6

Попробуйте сделать что-то простое для начала, типа объявления переменных, работу с ними (сложение, вычитание, умножение, деление и т. д.), а так же циклы и функции. Если это получится, то можно думать о продолжении работы над компилятором. Транслировать пока можно в асм и компилировать используя avrasm32.exe.


Да у меня уже есть готовый парсер математических выражений. Как-то давно писал: Calculator (vb6). Класс парсера там написан почти по-русски.

Насколько я помню грамматика для него выглядит вот так:

Код:
КОНЕЦ
ВЫВОД КОНЕЦ
Логика ВЫВОД КОНЕЦ
Логика ВЫВОД [ Логика ВЫВОД ] КОНЕЦ // [ ... ] - поддерживается одна и боле операций в строке
ИМЯ := Логика ВЫВОД [ ИМЯ:= Логика ВЫВОД ] КОНЕЦ

Логика:
  Логика ( < | > | <= | >= | = | <> ) СложВычит

СложВычит: // оператор+(), оператор-()
  СложВычит + УмножДелен
  СложВычит - УмножДелен

УмножДелен: // оператор*(), оператор/()
  УмножДелен / ВозвСтепень
  УмножДелен * ВозвСтепень

ВозвСтепень: // оператор^()
  ВозвСтепень ^ Факториал

Факториал: // ()!
  ОсновныеОпер!

Список: // оператор,()
  Логика
  Список , Логика

ОсновныеОпер:
  ЧИСЛО // десятичное число формата: n.nn[(E|e)(+|-)nn]
  ИМЯ // константа или переменная
  ИМЯ( Список ) // вызов функции
  - УмножДелен
  ( Логика ) // вот здесь нужна рекурсия
  [ Список ] // многомерный вектор

http://img.radiokot.ru/files/4453/d97k83ifz.png

Не нужно быть программистом-эгоистом... Тоже может получится с вашим компилятором.

Есть такая программа Smath Studio. Написана на c# и .Net 2.0. Запускается на Windows, Linux, MacOS. Никто не писал про какие-либо проблемы с .Net, кроме того, эта программа ранее существовала под мобильные устройства всё с тем же .Net'ом, правда только под Windows CE. Не обязательно использовать самый последний framework, тем более для консольного компилятора. 2.0, думается, есть у всех. И я думаю, что "эгоист" тут не тот, кто идёт в ногу со временем, а как раз наоборот - тот, кто удерживает всех ради устаревшей совместимости для себя одного.

Ставить только из-за нее .NET 4 не вижу смысла.

Смысл в том, что сейчас все программы для Windows пишутся на .Net и вероятность того, что у кого-то нет framework'а не такая большая.

Отредактировано uni (2014-06-15 14:14:33)

0

7

uni написал(а):

Смысл в том, что сейчас все программы для Windows пишутся на .Net

Не все.
Существует много компиляторов создающих проги без необходимости использования .NET.

0

8

Компиляторы-то существуют, я просто указываю на факт, что пользовательское ПО практически всё сейчас под .Net и трудно будет пользоваться офисом без .Net'а. Вот в чём посыл был. Кроме того, делать две копии программы под 32 и 64 разрядные архитектуры не очень удобно.

0

9

uni написал(а):

1. Пишем программу на bascom-avr в виде одной функции/оператора/команды.
2. Компилируем, изучаем ассемблерный листинг.
3. Повторяем команду в своём компиляторе.
4. Переходим к следующей функции из списка и опять возвращаемся к п. 1.

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

0

10

я против: net и русского в синтаксисе
за саму идею - только ЗА, и могу тестировать

0

11

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

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

Поэтому нужно разъяснить, что означает "лучше".

я против: net и русского в синтаксисе

Если я буду делать русский в синтаксисе, а я буду, то можно будет писать на любом языке. Операторы сделаю альтернативными и взаимозаменяемыми. Хочешь писать по-русски - пиши, хочешь по-английски - без проблем. Не обязательно делать привязку к какому-то конкретному языку. Это вообще не проблема. А что касается .Net, то плюсов у него я вижу больше, чем минусов. Я за рациональный выбор.

Отредактировано uni (2014-06-15 15:09:27)

0

12

почему я (судя по сообщениям, не только я) против NET
в своё время обслуживал парк ПК количеством около 100 штук: софт, железо...
самый гемор был (и есть!) когда софт пишут под net
один под 3.5, другой - под 4.0, третий - 2.21
мат, мат, мат
причем, обновляешь одно - начинает отваливаться другое или глючить
у меня был случай, когда человеку надо было иметь две программы, но они писались под разные версии Net
пришлось поставить вторую ОСЬ
второму- виртуальную машину.

кум, коий работал в еще большей организации, вообще не ставил софт, писанный на net - у них по безопасности он не проходил ни в какие ворота

плюс: программисту проще.
но всё остальное - минус!

0

13

Что касается компилятора Luna. Я когда-то слышал об этом проекте, но не обратил на него должного внимания. Теперь обращаю:

COMPILER/LANGUAGE

Modern, objekt oriented syntax.
No restrictions for the expression length.
Dynamical strings.
Dynamical memory blocks.
Function pointers und indirect calls.
Aliases/Defines.
Type casting.
Structures.
Pointers.
Daten objects.
User definied classes for code modularization.
Inline-Assembler.
Powerful bit- and data manipulation functions.
Many interfaces for hardware components of the controllers, like e.g. SPI, I2C, 1Wire, Uart, Ports, partially with extensions like
FIFO-buffer and much more.
Many software emulations of different interfaces, protocols and functions.
Many interfaces for special applications like DCF77-decoder, CRC-Calculation, read/write of controller-flashpages, Keymanager,
Taskmanager, Text-LCDs and much more.
Many Debugging functions like hex-dumps, exceptions for memory violations and much more.
Direct reading/setting of controller specific registers and interrupts.
Build-in software-eventsystem.
Many functions for input/output of data over the interfaces.
Powerful functions for integer arithmetics.
Powerful functions for floating point arithmetics.
Powerful functions for string manipulations.
Powerful user definied methods (Procedures and Functions), with referenced objects, local memory, static or dynamic dimension of
en variables and interrupt- and recursive capability.
Powerful condition types.
Direct support of multithreading and parallel execution.
Output of the created assembler source.
Combined Compiler/Assembler.

Очень не плохой набор возможностей и кто-нибудь это всё пробовал? Или объектный подход слишком сложным оказался? Надо будет подробнее с ним ознакомиться, посмотреть асм листинги и погонять код в Proteus. Надеюсь, объектные файлы компилятор выдаёт.

0

14

Можно писать программу на .Net 2.0 и только им специально ограничиться, тогда проблем не будет. Сам framework можно добавлять в дистрибутив. В SmathStudio при этом он увеличивается на 15 Мб, размер же самой программы в архиве около 2 Мб. Думаю, что это можно пережить.

Отредактировано uni (2014-06-15 15:46:18)

0

15

Вот, кстати, из описания можно посмотреть на шаги работы компилятора:

Compiler order.
1. Load file
2. Convert to tokens
3. Lexical analysis
4. Import Include source code files
5. Validate syntax
6. Pre Processing:
7. Identify Class basis of all constants
8. Evaluate Constants, Defines and conditional compiler directives
9. Analyze strings and variables
10. Analyze classes and subroutines
11. Pre compile: Structuring and sequence analysis
12. Compile/Assemble
13. Write to output file

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

Отредактировано uni (2014-06-15 16:01:29)

0

16

uni написал(а):

Я проблему вижу в другом. В самой архитектуре работающего кода. Здесь используется два стека. Если бы мне кто объяснил плюсы и минусы такого подхода.

В баском три стека. Хотя по моему хватило бы одного как это сделано в ПК. Те же локальные переменные, можно хранить в основном стеке, а не в дополнительном. Так что реализация с одним стеком на мой взгляд предпочтительнее.

uni написал(а):

А что касается .Net, то плюсов у него я вижу больше, чем минусов. Я за рациональный выбор.

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

0

17

Пётр написал(а):

В баском три стека. Хотя по моему хватило бы одного как это сделано в ПК. Те же локальные переменные, можно хранить в основном стеке, а не в дополнительном. Так что реализация с одним стеком на мой взгляд предпочтительнее.

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

На счет Луны: надо собраться силами и попытаться что-то на ней написать. Сходу - не получилось вникнуть (возникла сразу куча вопросов и пока не очевидно (глаз не хватает за код)).

0

18

Да, стека три, просто третий не совсем обычный. sw и frames используют как бы одну область памяти, но с разных сторон.

Самый основной плюс - это гибкость при решении задач на всём жизненном цикле программы. И я бы не ограничивал критерии одними только нуждами пользователей. Что за дискриминация? Между прочим, многие пользователи вообще не имеют никакого понятия что за файлы установлены в их системе. Спроси у любого что он слышал про папку winsxs? Если ничего, то можно заканчивать разговоры про разные файлы и необъяснимые беспокойства.

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

0

19

uni написал(а):

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

Бэйсик для этого и был придуман, чтобы упростить процесс программирования и не грузить пользователя рутиной. Где там стеки и как оно работает - не должно волновать. А в Баскоме - не до что сделано и не первое, и не второе. Сложные условия и вычисления - не понимает. Системная область должна существовать в теневой области. Если для раскрытия всего потенциала МК требуется ввести/придумать дополнительные операторы - пожалуйста.

На счет среды разработки: она должна быть такой, чтобы была максимальная совместимость с ОС и не требовать доп. библиотек. Я по этой причине до сих пор не могу слезть с VB6, т.к. он работает сейчас везде (достаточно чтобы офис стоял), а если старое, маломощное железо и ОС голая, то без проблем вместе с программой достаточно поставлять нужные DLL-ки. Про Net такого сказать нельзя.

0

20

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

в своё время, ради самообразования, я бил голову об компиляторы и синтактический анализ. Даже на Qbasic что-то там написал ))) но не было причин заниматься и бросил.

про ООП для 8-битников. На мой взгляд, это что-то " а не прикрутить ли нам к Зепору колёсики от Белаза?..."
проблема будет не в синтаксисе - он един для всех языков уровня Си (классический), Бейсик, Паскаль - а с библиотеками
мне задаром не надо компилятор, который гол как сокол! if, goto я и в ассме напишу :)

0

21

RDW написал(а):

На счет среды разработки: она должна быть такой, чтобы была максимальная совместимость с ОС и не требовать доп. библиотек.

аналогичного мнения! приносил свои программки на дискете - копировал и запускал. Всё.
а когда тащишь с собой привод с десятком программ и СервисПаков - жуть...

0

22

.net решила проблему ада dll. Скажите, какой размер у каждого папки windows\winsxs? Когда вы что-то устанавливаете в систему в эту папку копируются все необходимые файлы для работы вашей программы в будущем. Чем старше у вас система, тем жирнее эта папка. На этом фоне не имеет смысла говорить о каких-то жалких 20 метров для .net 2.0. Эта папка скрытая, только не вздумайте что-то там удалять, иначе вашей системе может прийти капут.

Если делать поддержку компилятором разных камней, то их ресурсы можно подключать по-разному. У avrstudio это куча dll'ок. На .net очень удобно с ними работать. Текстовой вариант не хорош тем, что парсинг занимает время.

Что касается объектного подхода. С точки зрения восприятия это хорошо, но если поддержка ооп будет кушать ресурсы, которых на мк и так не много, то это плохо. В промышленности используется несколько стандартизированных языков программирования, там ооп я не наблюдал. С другой стороны сами мк сейчас вооружаются такой многообразной периферией, что использование пространств имён - это само собой вытекающая идея. Так сделано в arm'ах. Поэтому и в Luna этот подход вполне логично выглядит.

0

23

uni написал(а):

.net решила проблему ада dll. Скажите, какой размер у каждого папки windows\winsxs?

А про кучу версий .NET (часто не совсем совместимых между собой) при этом умалчиваете.
Грамотно написанная программа не будет захламлять системную папку и нужные ей DLL держать в локальной папке. Быдлокодить захламляя системные папки можно и на .NET, так что аргумент не убедительный.

uni написал(а):

На этом фоне не имеет смысла говорить о каких-то жалких 20 метров для .net 2.0.

Зачем нужен .NET если аналогичную прогу (возможно даже лучшего качества) можно написать без его использования? В чем преимущество .NET-языка при разработке компилятора?

uni написал(а):

У avrstudio это куча dll'ок. На .net очень удобно с ними работать.

С ними можно работать из любого ЯП поддерживающего вызов API ОС, в частности функции LoadLibrary() и надо сказать что преимуществ .NET языков в этом нет.

uni написал(а):

Текстовой вариант не хорош тем, что парсинг занимает время.

Этож сколько там должно быть данных чтобы тормозило? 100 МБ или еще больше? Или это прога на .NET  языке тормозит при парсинге текста?

+1

24

Так я не понял, сколько весит папка windows/winsxs? У меня на чистой, только что поставленной Win7 x32, она занимает ~5 Гб. Каждый раз, когда вы устанавливаете что-то, а потом удаляете, на самом деле остатки собираются и хранятся в этой папке. Так что странно говорить о "грамотном" исполнении, когда Windows захламляет себя сама гигабайтами. Искать соринку, а проходить мимо бревна? Это так называется? А если бы я не сказал о winsxs, вы бы так в неведении и оставались и продолжали рассуждать о грамотном хранении частей программ?

Я писал на разных языках и в разных средах. Возможности .net вместе со средой разработки просто поражают. Современная VS с некоторыми дополнениями сама может дописывать за вас код, облегчая рутинное программирование. Причём не только дописывать, но и переписывать, предлагая варианты. Не могу сейчас показать, т.к. в другой системе. Это по началу даже смахивает на фантастику, но быстро к этому привыкаешь.

dll в .Net - это не обычная dll, это сборка, которая имеет малое отношение к LoadLibrary и прочим Win32API, т.к. весь .Net код работает в управляемом пространстве, а весь "старый код" в неуправляемом. В .Net нет традиционных указателей, просто нет, всё построено на объектах (точнее сказать, там есть специальные типы, которые включены для совместимости с неуправляемым кодом). Удобство сборок в том, что ты можешь получить полную информацию о её содержании, причём прямо во время разработки. Всё прозрачно, нет всякой хрени с декорированием имён экспортируемых функций, нет хрени с соглашением о вызовах, да вообще, старые методы модульности при помощи dll выглядят какими-то динозаврами.

Прога может тормозить от применяемого алгоритма. Многие разработчики в своей практике применяют автоматизированные средства сборки проектов. Это когда проекты собираются после какого-то количества изменений или через определённый промежуток времени (ночные сборки). Если компилятор трудится в таком режиме постоянных пересборок кучи проектов, то зачем ему втыкать палки в колёса, заставляя каждый раз парсить константые текстовые конфигурационные файлы? В чём смысл? Они ведь задаются один раз и навсегда для определённого камня.

Поэтому, чтобы сэкономить время, кое-где ввели понятие precompiled headers. Слышали о таком? Visual Studio, чтобы бесполезно не тратить время на сборку неизменяемых (библиотечных) заголовочников, компилирует их один раз заранее, а потом всегда использует их объектное представление. Иначе компиляция происходила бы нерационально. Парсить имеет смысл только то, что меняется.

0

25

Я за NET!
Несмотря на все аргументы против него, некоторые вещи вы просто ни на чём другом не напишите.
А об удобстве разработки / отладки я вообще молчу, здесь нужно только самому попробовать, сравнить.

0

26

uni написал(а):

Так я не понял, сколько весит папка windows/winsxs? У меня на чистой, только что поставленной Win7 x32, она занимает ~5 Гб. Каждый раз, когда вы устанавливаете что-то, а потом удаляете, на самом деле остатки собираются и хранятся в этой папке. Так что странно говорить о "грамотном" исполнении, когда Windows захламляет себя сама гигабайтами.

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

А по поводу остального. Выше писал про программиста-эгоиста, который думает лишь об удобстве разработки, а об пользователях даже не задумывается. По факту. .NET-программа требует больше ресурсов компа чем нативная (пори одинаковой степени оптимизации). Не у всех же топовые компы и зачем пользователям эти тормоза? Только лишь потому что программисту так удобнее? Это эгоизм.

0

27

эгоизм )
думаю, все высказали своё мнение.
теперь посмотрим на результаты
говорю сразу: если, скачав инсталятор, мне придётся скачать еще 200-300 мБ других программ, то меня с вероятностью в 95% посетит "дануеёнафигэтупрограмму" :)

0

28

Как всегда, "ни одно доброе дело не останется безнаказанным"...

Чтобы писать компилятор одному человеку, ему нужно просто его писать. Причём на любом языке.
Чтобы писать команде, нужно и привязку к одному языку сделать, и SVN использовать, и распределение человеческих ресурсов и многое другое.

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

Как мне кажется, вопрос в том, что если мы не владеем каким то языком, мы стараемся найти причины, чтобы его не использовать...
Настоящего профессионала отличает желание учиться, познавать новое, избирательно подходить к выбору ЯП для конкретных задач.
Для написания данного компилятора именно платформа NET более всего подходит, хотя я не отрицаю, что написать его можно будет практически на любом языке.
Я сам писал только на бейсике(VB6, VBA), но поставленные задачи просто превышали их возможности.
Понадобилось немного времени, чтобы перейти на VBNET & C#, о чём я не мало не жалею.

Александр Д. написал(а):

говорю сразу: если, скачав инсталятор, мне придётся скачать еще 200-300 мБ других программ, то меня с вероятностью в 95% посетит "дануеёнафигэтупрограмму"

Я думаю, что 200-300 мБ бесплатного софта нельзя сравнить с 89 евро Баскома?

Пётр написал(а):

NET-программа требует больше ресурсов компа чем нативная (пори одинаковой степени оптимизации). Не у всех же топовые компы и зачем пользователям эти тормоза? Только лишь потому что программисту так удобнее? Это эгоизм.


Для компилятора не нужны сверхскорости и большие ресурсы. Не вижу проблемы, чтобы для изготовления скульптуры использовать 3D CNC станок, а потом довести вручную, чем всё сделать вручную.
Скорость разработки тоже важна. И удобство.

Но это будет очередной офтоп о "лучшем из лучшего".
Давайте по существу в этой теме говорить, а остальное можно в отдельную ветку выделить.
Зачем спорить, если можно повести конструктивный диалог?

0

29

Василий, не сравнивайте "я его слеплю, когда мне надо" и "делаю под заказ, который оплачивают". Я плачу. И буду платить за продукт, который МЕНЯ устраивает :)

0

30

Александр Д. написал(а):

И буду платить за продукт, который МЕНЯ устраивает :)

Аналогично. Сейчас альтернативы просто нет Баскому. (

0


Вы здесь » Программирование ATMEL в BASCOM. » Исходники » Компилятор