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/ |