OberonCore
https://forum.oberoncore.ru/

Сатори
https://forum.oberoncore.ru/viewtopic.php?f=6&t=769
Страница 1 из 2

Автор:  Иван Кузьмицкий [ Четверг, 29 Ноябрь, 2007 12:04 ]
Заголовок сообщения:  Сатори

Вчера изучал одну конструкцию Ящика, Files-HostFiles. И возникло странное ощущение идеальности перехода от исходного текста модулей к физической реализации. Не уверен, что смогу хорошо описать, и заранее прошу прощения за сумбур, но суть в следующем.
В Ящике исходный текст модуля находится в отдельном документе. И вот то, что оформлено в текстах, без каких-либо оговорок и нюансов, переходит в исполняемые конструкции. Как написал, так оно и получилось. Это даёт чувство удивительного комфорта.
В отличие, например, от Клариона (на С++ не писал, поэтому не могу судить), где исходный текст на экране ещё не означает законченности конструкции и выглядит как просто часть большого листа с чертежом. Чертёж этот надо ещё умудриться увидеть, чему служат многочисленные "помогальники" - дерево процедур, вставки кода и т.п. :)
А в Ящике этот чертёж уже на стадии исходного текста явно разделён на блоки.
Когда я впервые взялся за Ящик, мне, как и многим, не хватало навигации по текстам, всяких рюшечек и т.п.
А сейчас я ощущаю, что этого, по большому счёту, и не нужно. Сам язык содержит в себе средства организации, что и отражено в Ящике.

Автор:  Wlad [ Среда, 05 Декабрь, 2007 21:50 ]
Заголовок сообщения:  Re: Сатори

Ну, дык, батенька, Вирт так и формулировал задачу: язык-то высокого уровня (я бы даже сказал уровня выше понимания иных "профи" от "программинга"), но с ясно видимой, во ЧТО выльются конструкции при компиляции... можна сказать - 1-в-1 (с естественными оговорками)

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

Автор:  Евгений Темиргалеев [ Четверг, 06 Декабрь, 2007 09:08 ]
Заголовок сообщения:  Re: Сатори

Владимир Лось писал(а):
пока с гарвардской архитектурой не пришлось поработать...
При нынешнем развитии "микросхемоделания" переход к раздельному хранению кода/данных должен по идее упростить сущ-е системы. Однако пока явно все переходить не собираются, бабло и так срубают. Не дадите ссылочку, если есть, - почитать про то оборудование на котором Вы работали? Антиресно!

Автор:  Vlad [ Четверг, 06 Декабрь, 2007 16:59 ]
Заголовок сообщения:  Re: Сатори

Владимир Лось писал(а):
Я вот раньше кипишился на счёт отсутсвиеф таких же, как в Си, конструкций инициализации при объявлении...... пока с гарвардской архитектурой не пришлось поработать...


А какое отношение гарвардская архитектура имеет к инициализации при объявлении?

Автор:  Wlad [ Четверг, 06 Декабрь, 2007 21:48 ]
Заголовок сообщения:  Re: Сатори

Евгений Темиргалеев писал(а):
При нынешнем развитии "микросхемоделания" переход к раздельному хранению кода/данных должен по идее упростить сущ-е системы. Однако пока явно все переходить не собираются, бабло и так срубают. Не дадите ссылочку, если есть, - почитать про то оборудование на котором Вы работали? Антиресно!

Э-хе-хе... Вот оно, поколение взрощённое и вскормлённое дядюшкой Билли... Ничегошеньки за пределами ClientRectangle-ов и не видим... Ну иногда в Линукс забегантишен...
А между тем, совокупный вклад микроконтроллеров в "дело компьютеризации и автоматизации всего вся" - просто несоизмерим по масштабам и значимости ни с какими там веб-поделками али ещё какими всякими R3 и разными прочими биллингами...

Ссылочку? - их есть у меня: http://www.atmel.ru/Articles/Atmel14.htm да и разные прочие аналогдивайсы с техасинструменсами....... :о)

Автор:  Wlad [ Четверг, 06 Декабрь, 2007 21:53 ]
Заголовок сообщения:  Re: Сатори

Vlad писал(а):
А какое отношение гарвардская архитектура имеет к инициализации при объявлении?

С какой стороны?

Автор:  Vlad [ Пятница, 07 Декабрь, 2007 03:27 ]
Заголовок сообщения:  Re: Сатори

Владимир Лось писал(а):
Vlad писал(а):
А какое отношение гарвардская архитектура имеет к инициализации при объявлении?

С какой стороны?


Хоть с какой-нибудь.

Автор:  Wlad [ Пятница, 07 Декабрь, 2007 22:13 ]
Заголовок сообщения:  Re: Сатори

Vlad писал(а):
Владимир Лось писал(а):
Vlad писал(а):
А какое отношение гарвардская архитектура имеет к инициализации при объявлении?

С какой стороны?

Хоть с какой-нибудь.

Блин, а самому последствия распределения сегментов программы, при условии разнесения памяти программ и памяти данных, слабо домыслить?...
Или - "а - поговорить?..."
Объяснить канешна не "слабо", но иногда складывается впечатление, что собеседнику собственно объяснения не нужны...

Автор:  Евгений Темиргалеев [ Суббота, 08 Декабрь, 2007 10:49 ]
Заголовок сообщения:  Re: Сатори

Владимир Лось писал(а):
Объяснить канешна не "слабо", но иногда складывается впечатление, что собеседнику собственно объяснения не нужны...

Можете объяснить мне. Чесно говоря, единственную разницу, которую я сам вижу (если говорить про Си) - глобальные данные сразу загружаются проинициализированными (когда грузятся программа+данные), а в случае разделения памяти (предполагаю, что данные вообще не загружаются - только программа) надо генерировать код инициализации, инициализация по умолчанию может быть и не востребована, а лишний код в микроконтролеерах...

Автор:  Vlad [ Суббота, 08 Декабрь, 2007 21:12 ]
Заголовок сообщения:  Re: Сатори

Владимир Лось писал(а):
Блин, а самому последствия распределения сегментов программы, при условии разнесения памяти программ и памяти данных, слабо домыслить?...


Какие сегменты? Как это относится к возможности инициализировать переменные при объявлении?

Владимир Лось писал(а):
Или - "а - поговорить?..."
Объяснить канешна не "слабо", но иногда складывается впечатление, что собеседнику собственно объяснения не нужны...


Просто представь, что собеседник не посвящен в особенности реализации компиляторов для экзотических платформ.

Автор:  Vlad [ Суббота, 08 Декабрь, 2007 21:56 ]
Заголовок сообщения:  Re: Сатори

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


Речь зашла (цитирую) об: "инициализации при объявлении". Лично я под этим понимаю конструкт вида:
Код:
int i = f();


Но я не понимаю (и поэтому спросил), почему такой конструкт должен противопоставляться такому (в случае гарвардской архитектуры):
Код:
int i;
i = f();


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

Автор:  Info21 [ Воскресенье, 09 Декабрь, 2007 00:17 ]
Заголовок сообщения:  Re: Сатори

Vlad писал(а):
Но я не понимаю (и поэтому спросил) ...


Тоже не понимаю.

Автор:  Wlad [ Вторник, 11 Декабрь, 2007 22:35 ]
Заголовок сообщения:  Re: Сатори

Vlad писал(а):
При том, что все известные мне компиляторы для обоих случаев сгенерят абсолютно идентичный код.
А сколько вам известно компиляторов?... Применительно к миру встроенных систем и систем РВ...
Вот, например некоторые "нюансы" работы с памятью программ в Мегах http://www.nongnu.org/avr-libc/user-man ... space.html
Хотел ещё описание подобных же "трюкачеств" и для Analog Device-ов найти - запропостились куда-то доки и ссылки, но искать - в лом - но, поверьте, там "плясок с бубнами" не меньше и они не менее забористы...
И, заметьте, ни о каком "общем стандарте" от производителей даже по "самому распространённому" языку речи нет! Каждый произодитель - в свою дуду дудит...
Конечно, при достаточной усидчивости можно всё вычитать. Со временем... Для всего набора процов, используемых в проектах... Хорошая перспектива? Тока не надо говорить о том, что профессионал постоянно должен учиться! Это я и без советчиков знаю. Потому и полез сразу, по приходу в контору и переходе на Меги в разделы док, посвящённые поддержке вариантом языка "неординарностей" архитектуры. Оказалось - не зря! Люди, по нескольку лет уже программировавшие этот кристалл, просто не добрались (по причине цейтнота или незнания английского) до нужных разделов и в их программах был расход памяти.
С другой стороны, применяй я обероны - отпала бы проблема "учёта нюансов" - компилятор и так бы строки-константы помещал в сегмент кода, идущего при "прожиге" в паямть программ... А код инициализации так-и-так приходится ручками писать для гарварда - что на оберонах, что на аде, что на си...

ЗЫ ещё, например, учтите, что, как правило, ячейки памяти данных и памяти программ имеют разную разрядность... И не всегда размер одних является делителем резмера других. Например в AD218x & AD219x разрядность данных 16 бит, а кода - 24 бита. И там - свои "особенности" свистоплясок с учётом и вовлечением "лишних" старших 8 бит при хранении данных в памяти программ... И, - соответственно - "расширение" си конструкциями и макросами для поддержки всего этого хозяйства... Что бы было понятно, с чем приходится сталкиваться - представьте себе все варианты хранения указателей на данные и код в памяти программ и памяти данных... Или вот ещё. в gcc есть средство запоминания адреса метки через специальный вариант получения адреса: && . Мне например, моя логика ничего не подсказала, как проинициализировать на меге массив адресами меток (ну нужно было! :о) ). Заработавшую кострукцию (со всеми макросами и волшебными словами), я нашел тупым перебором возможных сочетаний макросов и введённых служебных слов для объявлений, пока у меня светодиоды на "дебаггерном" порту не зажглись в нужной, ожидаемой последовательности... :о) И получившийся набор тарабарщины был ой как далёк от того, что предлагали все коллеги-сишники на форумах и в конторе для разрешения проблемы...

Автор:  Info21 [ Среда, 12 Декабрь, 2007 00:14 ]
Заголовок сообщения:  Re: Сатори

Владимир Лось писал(а):
... И получившийся набор тарабарщины был ой ...

Instructive. Йес уж.

Автор:  Wlad [ Среда, 12 Декабрь, 2007 01:10 ]
Заголовок сообщения:  Re: Сатори

Info21 писал(а):
Владимир Лось писал(а):
... И получившийся набор тарабарщины был ой ...

Instructive. Йес уж.

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

Автор:  Vlad [ Среда, 12 Декабрь, 2007 06:00 ]
Заголовок сообщения:  Re: Сатори

Владимир Лось писал(а):
Vlad писал(а):
При том, что все известные мне компиляторы для обоих случаев сгенерят абсолютно идентичный код.
А сколько вам известно компиляторов?... Применительно к миру встроенных систем и систем РВ...


С сишными компиляторами для встроенных систем никогда не сталкивался.

Владимир Лось писал(а):
Вот, например некоторые "нюансы" работы с памятью программ в Мегах http://www.nongnu.org/avr-libc/user-man ... space.html


Ужас.

Владимир Лось писал(а):
С другой стороны, применяй я обероны - отпала бы проблема "учёта нюансов" - компилятор и так бы строки-константы помещал в сегмент кода, идущего при "прожиге" в паямть программ...


С чего такая уверенность? С того, что таких компиляторов нет в природе и поэтому они свободны от недостатков уже имеющихся? ;) Кто мешает нафигачить в компиляторы оберона точно таких же __ATTRIBUTE__, SYSTEM.WHATEVER и т.д. А нормальные сишные компиляторы и так помещают строки-константы в RO сегмент данных.

Автор:  Wlad [ Среда, 12 Декабрь, 2007 23:24 ]
Заголовок сообщения:  Re: Сатори

Vlad писал(а):
С сишными компиляторами для встроенных систем никогда не сталкивался.
Я прошу прощения, а это не из разряда случаев "спора о вкусе устриц и омаров"?...
Vlad писал(а):
Ужас.
"...А ваша мама знает, что вы здесь?..." Ж:о)
Vlad писал(а):
С чего такая уверенность? С того, что таких компиляторов нет в природе и поэтому они свободны от недостатков уже имеющихся? ;) Кто мешает нафигачить в компиляторы оберона точно таких же __ATTRIBUTE__, SYSTEM.WHATEVER и т.д. А нормальные сишные компиляторы и так помещают строки-константы в RO сегмент данных.

Уверенность с многолетнего подтверждения виртовского принципа "неосновывания на информации о механизме исполнения".
А "нормальный сишный компилятор" - это вот чего такое?
Ещё один вопросец: с какого боку совместились понятия "сегмента данных только для чтения" (и его описание в загружаемом модуле-файле) и специфика гарвардской архитектуры (конкретно - наличие памяти программ)???

Автор:  Vlad [ Пятница, 14 Декабрь, 2007 10:14 ]
Заголовок сообщения:  Re: Сатори

Владимир Лось писал(а):
Vlad писал(а):
С сишными компиляторами для встроенных систем никогда не сталкивался.
Я прошу прощения, а это не из разряда случаев "спора о вкусе устриц и омаров"?...


А разве спор идет о компиляторах для встроенных систем? У меня были претензии к обоснованности вот этого поста:

Владимир Лось писал(а):
Я вот раньше кипишился на счёт отсутсвиеф таких же, как в Си, конструкций инициализации при объявлении...... пока с гарвардской архитектурой не пришлось поработать...


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

Владимир Лось писал(а):
Vlad писал(а):
С чего такая уверенность? С того, что таких компиляторов нет в природе и поэтому они свободны от недостатков уже имеющихся? ;) Кто мешает нафигачить в компиляторы оберона точно таких же __ATTRIBUTE__, SYSTEM.WHATEVER и т.д. А нормальные сишные компиляторы и так помещают строки-константы в RO сегмент данных.

Уверенность с многолетнего подтверждения виртовского принципа "неосновывания на информации о механизме исполнения".


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

Владимир Лось писал(а):
А "нормальный сишный компилятор" - это вот чего такое?


Например VC. С оговорками ;)

Владимир Лось писал(а):
Ещё один вопросец: с какого боку совместились понятия "сегмента данных только для чтения" (и его описание в загружаемом модуле-файле) и специфика гарвардской архитектуры (конкретно - наличие памяти программ)???


Это был комментарий вот к этому:
Владимир Лось писал(а):
С другой стороны, применяй я обероны - отпала бы проблема "учёта нюансов" - компилятор и так бы строки-константы помещал в сегмент кода, идущего при "прожиге" в паямть программ...


Я почему-то подумал, что речь идет именно об RO данных, а не запихивания их в сегмент кода. Правда я не понимаю нафига это надо именно в случае гарвардской архитектуры (впрочем если объясните, то буду благодарен). Зато теперь с новым пониманием я сформулирую такой вопрос: почему именно компилятор оберона будет класть строки в сегмент кода? В описании языка оберон я такого требования к реализациям не помню.

P.S. Вообще если есть такая сильная уверенность в правильности оберонов для встроеннных систем, то кто мешает написать кросс-компилятор? По моим прикидкам, для сильно обрезанного варианта (без GC и сопутствующего рантайма) и с учетом 100% загрузки на работе, для этого достаточно нескольких выходных. Что мешает? Вопрос без иронии, просто интересно.

Автор:  Рэйлвэй Каген [ Пятница, 14 Декабрь, 2007 21:25 ]
Заголовок сообщения:  Re: Сатори

Vlad писал(а):
[Вообще если есть такая сильная уверенность в правильности оберонов для встроеннных систем, то кто мешает написать кросс-компилятор?


Для встраиваемых систем на базе микроконтроллеров:
1. динамическая загрузка и компоновка модулей - идет лесом, т.к. загружать-то нечего и некуда. Программа целиком прошивается во флеш и исполняется оттуда же.
2. сборка мусора, динамическая работа с типами, метапрограммирование - непозволительная роскошь. Типичная RAM - от сотни байт до десяти килобайт. Конечно можно держать описатель типа в сегменте кода, но это уже изврат, да и динамика в этом случае невозможна. Для кода RAMы нет.
3. расширяющее программирование(расширение модулей и типов данных), раздельная компиляция и подмена "на лету" - ну не перешить флешку "на лету", не подгрузить ничего к исполняемому коду.
4. У части моделей стек вообще аппаратный, типичная глубина от трех до тридцати уровней. Для других моделей создание расширяемых записей на стеке и передача по ссылке, конечно, позволит работать родовым шинам сообщений, но по-видимому это только слегка подсластит горькую пилюлю.
5. ООП - на голом си тоже можно писАть "в объектах". Иногда спасает.
6. все взаимодействие с периферийными модулями микроконтроллера пойдет с использованием SYSTEM, т.к. исп. голая регистровая адресация.

В общем нетленным остается только обероновский стиль программирования в лучшем смысле этого слова. Перевесит ли это перечисленные выше минусы?

ЗЫ: Да, совсем забыл - целевых платформ будет просто тьма.

Автор:  Geniepro [ Суббота, 15 Декабрь, 2007 01:13 ]
Заголовок сообщения:  Re: Сатори

Vlad писал(а):
P.S. Вообще если есть такая сильная уверенность в правильности оберонов для встроеннных систем, то кто мешает написать кросс-компилятор?
Ну, Вирту никто не мешает делать свои кросс-компиляторы Оберонов для микроконтроллеров Strong-ARM...
Vlad писал(а):
По моим прикидкам, для сильно обрезанного варианта (без GC и сопутствующего рантайма) и с учетом 100% загрузки на работе, для этого достаточно нескольких выходных. Что мешает? Вопрос без иронии, просто интересно.
Ну, там ещё придётся сделать какую-никакую стандартную библиотечку, библиотеку арифметики с плавающей точкой, и т.д. и т.п....
Было у меня как-то желание сподвигнуться на это дело, но эти библиотеки перевесили сомнительные выгоды от такого транслятора. Меня лично Си вполне устраивает в микроконтроллерах, с чужим кодом общаться почти не приходится, а если и приходится, то переписываю всё нафик, а мой стиль написания программ на Си меня вполне устраивает и, по-моему, он вполне нормальный. Я не использую такие выкрутасы, как ++i+j++ и тому подобные маразмы... :о)

Рэйлвэй Каген писал(а):
Для встраиваемых систем на базе микроконтроллеров:
...
В общем нетленным остается только обероновский стиль программирования в лучшем смысле этого слова. Перевесит ли это перечисленные выше минусы?
Для таких целей (имхо) лучше всего взять общее подмножество языков Модула-2 и Оберон, с добавлением объединений из Модулы-2...

Страница 1 из 2 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/