Ассемблер

"содержания понятия "гибкий" в контексте HLL"
есть два языка. в них есть управляющие выражения, циклы, типы данных, абстрактные типы данных, возможность работать с памятью и ыеутренними "фишками" ЭВМ или ОС. так вот Паскаль и С эквиваленты. А раз эквивалентны, то не имеет смысла говорить какой язык гибче.

"Структурированный массив данных - БД"
структурированный массив данных - всего лишь данные, но никак не БД.

система управления данными (СУД) является системой управления базами данных (СУБД) если:
обеспечивает поддержку логически согласованного набора файлов;
обеспечивает непосредственное управление данными во внешней памяти;
обеспечивает управление буферами оперативной памяти;
реализует язык определения данных (DDL)
реализует языка манипулирования данными (DML);
обеспечивает восстановление информации после разного рода сбоев;
управляет единовременным доступом к данным со стороны многих пользователей в параллельном режиме;
поддержимвает способность сохранения больших объемов информации на протяжении длительных периодов времени
предотвращает несанкционированный доступ к данным.

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

"Телепатия не входит в спектр моих умений, а для того, чтобы обойтись без вопросов, требовалась именно что она"
тут не телепатия требуется, а элементарные знания. про языки и про СУБД.

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

 

Именно так:

А на самом деле:

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

 

"Киса, не делайте из еды культа..." (С) Остап Бендер

ИМХО автор пытается сделать из Ассемблера религию, и всех в неё обратить Лично я ничего не имею против, если кто-то является Левшой, делает в свое свободное время что-то интересное, но делает это для себя и отдаёт себе отчёт в том, что это не более чем хобби. Когда же видишь в таком Левше некую одержимость идеей, становится тревожно, даже, как сказал бы Aksy, очень тревожно Оно, конечно, понятно, что именно из таких людей выходят гении, но... гениев мало и, к тому же, Гений != Чудак

Если плавно переместиться ближе к теме, то в постах насторожил такой момент:

Боюсь показаться банальным, но практика показывает, что изобратение усовершенствованных специфичных велосипедов очень-очень-очень редко порождает жизнеспособные конструкции. ИМХО, в программировании ЕСТЬ место искусству, но не в такой форме. Программы МОГУТ и ДОЛЖНЫ быть красивыми, причём как внешне (о чём тоже часто забывают) так и внутренне. Но если они позиционируются как не как произведение искусства, а как рабочее средство, то там большинство фокусов просто будет неуместным.

 

www.oracle.com

Ну неужели Вы на самом деле сами не понимаете? Я, прям, уже боюсь прямо говорить с Вами об этом, ваше здоровье вызывает сомнение.

 

"Модусные, а не атрибутивные, свойства."
да хоть как классифицируйте, но эти свойства _обязательны_ для того чтобы СУД называлась СУБД. если это не реализовано, то это может быть все что угодно, но ни в коем случае не СУБД.

"Только в том, что я дал более широкую (а посему, конечно же, спорную) трактовку?"
да можно просто было сказать. СУБД - это программа. делов-то.

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

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

по поводу примера.
интересно было бы посмотреть еще пример с наследованием и полиморфизмом.

 

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

давайте еще раз посмотрим на понравившиеся Вам свойства:
"обеспечивает поддержку логически согласованного набора файлов;
обеспечивает непосредственное управление данными во внешней памяти;
обеспечивает управление буферами оперативной памяти;"
на этом примере непонятно идет речь о файловой системе, СУБД, экспертной системем или вообще о каком-нибудь драйвере устройства.
перечисленные мной свойства независимы и неясно, например, почему вам не понравилось свойство
"поддержимвает способность сохранения больших объемов информации на протяжении длительных периодов времени". в отличие от "обеспечивает непосредственное управление данными во внешней памяти"

"весьма банальна - добавляется (или встраивается) функция, вписывающая в определенное поле нужный offset"
уточню вопрос, как реализованы виртуальные функции и перегрузка функций?

 

получаем "обертку", а где наследование?

Это слишком общие слова. Весь вопрос в том, чтобы, как раз, корректно и гарантированно наложить...

А для процедур придется еще завести таблицу виртуальных методов. Только "наложение" Вам не поможет.

 

Nevermind

Эмбеддер я. Программирую микроконтроллеры, готовлюсь планомерно заниматься DSP. Основные предпочтения: RISC процессоры (ядра) с простой системой команд.
Есть ещё интерес создать свой контроллер (хотя бы ядро) по своему образу и подобию , эмульнуть его на какой-нить Альтере . Думаю использовать симуляцию троичной логики - посмотреть её преимущества на деле.
Если действительно дойдёт дело до проца (контроллера) - думаю создать для его программирования некий симбиоз АСМа с языками высокого уровня. Я представляю, чего я хочу, только нечётко пока.
Общения на тему, я думаю, не получится - слишком велик разрыв того АСМа, к коему я привык, с писюковским огромным и неповоротливым АСМом.

 

black,
"... Думаю использовать симуляцию троичной логики - посмотреть её преимущества на деле ..."
мужчина!

"... думаю создать для его программирования некий симбиоз АСМа с языками высокого уровня. ..."
"... Я представляю, чего я хочу, только нечётко пока."
"... слишком велик разрыв того АСМа, к коему я привык, с писюковским огромным и неповоротливым АСМом ... "
прежде чем придумывать рекомендую сначала ознакомиться с языком ФОРТ. как раз для таких сумашедших (в хорошем смысле слова).
я так думаю, если Вам понравилась троичная логика, то может быть и этот язык со своей специфичной архитектурой Вам понравится.
о том, что он практичен, реентерабелен, может использоваться в системах реального времени и в специализированных устройствах говорят те факты, что он используется в системе перемещения багажом у "Американских авиалиний" или в системе интерактивного общения в аропорту с 500 процессорами и под 20 000 сенсорных датчиков.

ПС. а вот некоторые высказывания про этот язык:
"Только психованные программисты используют ФОРТ".
"ФОРТ похож на Дао; это путь, и его можно только пройти. Его хрупкость есть его сила; его простота -- его направление".

 

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

Кстати в наше время использовать ассемблер я вообще не вижу необходимости. Всякие там контроллеры и прочая мутотень уже программируются на языках типа Си (сам лично такое делал). Мож конечно и нравится кому язык... Так почему бы не программировать в машинных кодах?

 

"При том, что я прочел то же самое в каком-то пособии. Обоснованием там было "принято называть"."
не все книги одинаковы полезны.

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

теперь про ассемблер и ООП.
"Перегрузка - никак. ... Да и не нужна она, по большей части."
напоминает Ваши слова "Обоснованием там было "принято называть". "
в ООП она нужна. да и одними макроопределениями тут не обойтись.

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

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

ПС. рекомендую как вариант посмотреть на http://www.codexxi.com/Oop.html
есть много идей по-поводу реализации ООП на ассемблере, но еще никто, по крайней мере мне неизвестно, а я стараюсь отслеживать информацию связанную с ООП, не реализовал _полноценное_ ООП на ассемблере.
а раз ООП не реализовано, то личной мной все это воспринимается (даже при наличии макросов и всяких тулз) просто как некоторое удобство в работе, но уж никак не ООП программирование.

ППС. "А вы попробуйте . Думаю, после пары килобайт кода желание задавать такие вопросы выйдет в сад. Навечно ".
тоже самое можно сказать и про попытку полноценно ООП-программить на ассемблере.

 

AlTk

Спасибо за рекомендацию. Посмотрим.
Bob

Видать такой умелец пряморукий был.

Угу. Я помню, написание мной процедуры декодирования ADPCM на асме позволило сэкономить на стоимости контроллера, заменив его менее мощным.

Скажу больше, CPLD уже на яве программируют . До чего прогресс-то дошёл . А ты спец по программированию всякой мутотени ?
Nevermind

Ну хотя бы аналогдевайзовские DSP посмотри

black добавил [date]1109066766[/date]:
Nevermind
Описания мелких контроллеров. К сожалению, я не нашёл на их родном сайте из-за нехватки времени описаний архитектур процессорных ядер микроконтроллеров и DSP на английском...

 

black

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

 

Bob

Да, производители кросс-средств добились-таки их эффективной работы, но асм пока ещё вне конкуренции по получению оптимального кода. К примеру, процедура декодирования ADPCM может на восьмибитном процессоре, выполняющем 5000000 инструкций в секунду (PIC16F874 с тактовкой 20MHz) свободно декодировать в монорежиме с частотой дискретизации 44100 выборок/сек в то время как процедура декодирования, написанная на сях не способна работать даже с частотой дискретизации 22050