"Ты не умничай, ты пальцем покажи" ту ошибку, которую я допустил. Или показатель фаллометра уже достиг той отметки, когда нечто бессодержательное писать можно, а конструктивное - уже таки нельзя? ******... А еще я на Эвересте не был. И в боулинг ни разу не играл, да. И даже канабис под регги еще ни разу не покурил . Я что, позиционирую себя как мегатруврубающийся? Как профи хай-класса? Может, я говорю, что просто понимаю больше, чем остальные здесь присутствующие? Да, я до хера чего не успел, поленился, забыл, не смог и прочее, написать, прочитать, понять, узнать, еtc. И что? Это значит, что я придумал ширму? Или, быть может, что всему свое время? Сюда я вышел с одной целью - найти тех, кому интересно то, что интересно мне. Не разговаривать насчет того, какой язык круче. Не меряться детородными органами со всякими идиотами. Не рассказывать о том, что я крут и пишу, чтоб "казалось страшней и непонятней". Какого хера, спрашивается, мне, за исключением всего нескольких постов, только об этом и твердят, в упор не замечая моих замечаний на этот счет? А насчет "надуманной философии" - открой описание какого-нибудь проца. Все, о чем я говорил в контексте понимания устройства, там есть. Уже, правда, не абстрактно, а вовсе даже конкретно. А дальше - медитируй. Может, и поймешь, о чем вообще здесь шла речь. О, да ты меня знаешь! Наверняка видел и программы, которые я пишу? Приведи сюда пример той "тупой рутины", что я пишу для остращания. Наверняка, при таком раскладе, у тебя завалялся исходник-другой... Ну или напомни мне, где я, и что, писал таким вот образом. Очень, знаешь ли, интересно...
"содержания понятия "гибкий" в контексте HLL" есть два языка. в них есть управляющие выражения, циклы, типы данных, абстрактные типы данных, возможность работать с памятью и ыеутренними "фишками" ЭВМ или ОС. так вот Паскаль и С эквиваленты. А раз эквивалентны, то не имеет смысла говорить какой язык гибче. "Структурированный массив данных - БД" структурированный массив данных - всего лишь данные, но никак не БД. система управления данными (СУД) является системой управления базами данных (СУБД) если: обеспечивает поддержку логически согласованного набора файлов; обеспечивает непосредственное управление данными во внешней памяти; обеспечивает управление буферами оперативной памяти; реализует язык определения данных (DDL) реализует языка манипулирования данными (DML); обеспечивает восстановление информации после разного рода сбоев; управляет единовременным доступом к данным со стороны многих пользователей в параллельном режиме; поддержимвает способность сохранения больших объемов информации на протяжении длительных периодов времени предотвращает несанкционированный доступ к данным. "позволяет перейти от абстрактно-заученных утверждений о устройстве машины и выполнении программ " знания об устройстве машины появляются, когда человек начинает работать с этим устройством, а уж какой язык он для этого использует - дело десятое. "читать начинаем", то что я написал про программирование графики и персонализатор для смарт карт. "Телепатия не входит в спектр моих умений, а для того, чтобы обойтись без вопросов, требовалась именно что она" тут не телепатия требуется, а элементарные знания. про языки и про СУБД. "открой описание какого-нибудь проца." тогда уж следует уточнять, что знание ассемблера поможет понять не устройство машины, а устройство процессора.
Да, Паскаль и С очень, очень похожи. Но при этом первый более формален. То есть, к примеру, конструкция if (c=0) {} (тупой пример, конечно же, но зато - донельзя наглядный) в нем - некорректна. И именно в этом контексте С был назван более гибким. Никак не? То есть, БД - это как бы не структурированные данные? Ок. Модусные, а не атрибутивные, свойства. Так где противоречие? Только в том, что я дал более широкую (а посему, конечно же, спорную) трактовку? А я ответил. Прочитав, ага. Еще раз относительно графики: то, чо кто-то когда-то набрал команду "ADD", или какую-нибудь "FSQRT", еще ни о чем тебе не скажет. Знания появляются, когда ты начинаешь работать системно, решая задачи в некоторой языковой среде. А смарт-карты вообще к Асму - никаким боком. Так же, как протоколы сетевого взаимодействия - это совершенно другая тема. Если бы ты немного отвлекся от самосозерцания, мог бы увидеть много интересного для себя. Например, смысл моих слов. Но понтами кидаться, конечно же, куда интереснее... О том, как процессор работает с машиной. А посредством этого - и о самой машине. HLL же изначально располагает к абстрагированию от железа.
Именно так: А на самом деле: Покажите работу (или проблему) которую интересно было бы обсудить. Поискать различные пути ее решения - решения практического, решения быстрого, решения производительного, решения красивого. Предложите свое решение на языке ассмблера, обсудим его в сравнении с другими решениями.
А где там азЪ и его знания, простите? Ок. Расскажи мне о моем проекте. Раз ты в курсе, что это не соответствует тому, что называется "СУБД", покажи мне его (да, именно что моего проекта, а не твоих проекций на мои слова) несоответствие содержанию этого понятия. В сад ходить не пробовал? Почитай, о чем эта тема.
"Киса, не делайте из еды культа..." (С) Остап Бендер ИМХО автор пытается сделать из Ассемблера религию, и всех в неё обратить Лично я ничего не имею против, если кто-то является Левшой, делает в свое свободное время что-то интересное, но делает это для себя и отдаёт себе отчёт в том, что это не более чем хобби. Когда же видишь в таком Левше некую одержимость идеей, становится тревожно, даже, как сказал бы Aksy, очень тревожно Оно, конечно, понятно, что именно из таких людей выходят гении, но... гениев мало и, к тому же, Гений != Чудак Если плавно переместиться ближе к теме, то в постах насторожил такой момент: Боюсь показаться банальным, но практика показывает, что изобратение усовершенствованных специфичных велосипедов очень-очень-очень редко порождает жизнеспособные конструкции. ИМХО, в программировании ЕСТЬ место искусству, но не в такой форме. Программы МОГУТ и ДОЛЖНЫ быть красивыми, причём как внешне (о чём тоже часто забывают) так и внутренне. Но если они позиционируются как не как произведение искусства, а как рабочее средство, то там большинство фокусов просто будет неуместным.
Сэр крайне хреновый телепат. То, что хотел автор, четко написано в первом посте. Или это у вас называется "сделать из Ассемблера религию, и всех в нее обратить"? Тады ой. В глазах смотрящего не только красота, но и более другие вещи. Рекомендую попробовать научиться понимать русский язык. Оно, говорят, бывает очень полезно, когда общаешься с его носителями. А вообще эта тема - апофигей того, как можно не видеть ничего, кроме своих представлений. Хоть, блин, конспектируй и диссертацию по психологии восприятия пиши. Моя конструкция жизнеспособна, пока я использую ее в программах. А с практикой, как я уже сказал, обратитесь к Borland Delphi или еще куда. Здесь далеко не последнее место занимает эстетика. Ну и личное удобство тоже, да . Что же касается "специфичного описания" - его можно лицезреть ниже. Ничего сложного. Описание чуть более трудоемкое, чем в C++ или Object Pascal'е, но использование - практически такое же.
www.oracle.com Ну неужели Вы на самом деле сами не понимаете? Я, прям, уже боюсь прямо говорить с Вами об этом, ваше здоровье вызывает сомнение.
В этих символах заключена Сущность СУБД? Или мусье думает, что я, говоря о том, что делаю, ставлю себя в один ряд с действительно серьезными разработчиками? Да, это правильно. Я действительно нездоров. Не тратьте более на меня ваше драгоценное, без сомнения, время. Тем более что я, кажется, уже сказал, куда обращаться с фаллометрией.
"Модусные, а не атрибутивные, свойства." да хоть как классифицируйте, но эти свойства _обязательны_ для того чтобы СУД называлась СУБД. если это не реализовано, то это может быть все что угодно, но ни в коем случае не СУБД. "Только в том, что я дал более широкую (а посему, конечно же, спорную) трактовку?" да можно просто было сказать. СУБД - это программа. делов-то. "смарт-карты вообще к Асму - никаким боком" смарт-карта вставляется в считыватель. считыватель - это специализированный компьютер с настоящим процессором. программы пишутся на кросс-компиляторе и кросс-ассемблере. в спецификации на считыватель отражена вся информация об устройстве с пиримерами вызова функций и обращения к "фишкам" считывателя. кстати пример, демонстрирующий внутреннею кухню, последовательность обработки команд, взаимосвязь компьютера, считывателя и смарт карты и вообще чего там происходит был написан на Visual Basic. "Еще раз относительно графики: " елки-палки. хорошо. уточню. для того, чтобы графика работала не просто быстро, а очень быстро, надо очень хорошо знать процессор. вплоть до того, что когда реализован алгоритм, имеющий минимальную сложность (получен алгоритм и наилучшая, минимальная оценка времени его выполнения), начинается его доводка применительно к особенностям этой модели процессора, вплоть до того, что считаются пересылки из регистро в память, число тактов процессора при выполнении какой-либо команды. но сама машина остается неизвестной. т.е. создатель алгоритма может даже не знать в какую ЭВМ поместят этот процессор. по поводу примера. интересно было бы посмотреть еще пример с наследованием и полиморфизмом.
Были бы обязательными - не были бы модусными . В том, что это нужно и полезно, я не сомневаюсь. Я сомневаюсь в том, что эти именно свойства дают право данным называться "базой данных". Вот именно это определение, с точки зрения формального обоснования, меня и интересует. Почему оно именно так? Потому что на так заборе (...ах, простите, в учебнике ) написано? Вариант . Ок. Правда, то, что использовался Басиц, вовсе не говорит, что Асм в плане "пощупать железо" был бы равнозначен. Или таки да? Мы с такими девайсами пока не игрались... Ок. Если внимательно читать листинг, можно кое-что обнаружить. А именно - вот это: Делаем "FILEOBJECT" макросом, и... Реализация полиморфизма тоже весьма банальна - добавляется (или встраивается) функция, вписывающая в определенное поле нужный offset. Offset этот либо прописывается в специальном поле включенном в структуру, либо формируется из шаблона, описывающего тот же самый класс, в котором поля, которые не надо переопределять, будут равны (DWORD PTR -1), путем "наложения" шаблона на оригинал, либо передаются в функцию (как вариант - создается функция, аналогичная CreateFileObject, в которой эти параметры вписаны в код)... кстати, к слову о "тупой рутине": самостоятельная реализация таких вещей может быть неуместна для создания неких конкретных вещей, но она очень уместна для того, чтобы программист понимал, как это делается в принципе.
"Вот именно это определение, с точки зрения формального обоснования, меня и интересует. Почему оно именно так? Потому что на так заборе (...ах, простите, в учебнике ) написано?" ок. причем здесь учебник. это определение происходит из-за того, чтобы не было путаницы между системами управления данными наподобие Вашей, файловой системой, может быть экспертной системой и другими, еще какими-то. давайте еще раз посмотрим на понравившиеся Вам свойства: "обеспечивает поддержку логически согласованного набора файлов; обеспечивает непосредственное управление данными во внешней памяти; обеспечивает управление буферами оперативной памяти;" на этом примере непонятно идет речь о файловой системе, СУБД, экспертной системем или вообще о каком-нибудь драйвере устройства. перечисленные мной свойства независимы и неясно, например, почему вам не понравилось свойство "поддержимвает способность сохранения больших объемов информации на протяжении длительных периодов времени". в отличие от "обеспечивает непосредственное управление данными во внешней памяти" "весьма банальна - добавляется (или встраивается) функция, вписывающая в определенное поле нужный offset" уточню вопрос, как реализованы виртуальные функции и перегрузка функций?
получаем "обертку", а где наследование? Это слишком общие слова. Весь вопрос в том, чтобы, как раз, корректно и гарантированно наложить... А для процедур придется еще завести таблицу виртуальных методов. Только "наложение" Вам не поможет.
Nevermind Эмбеддер я. Программирую микроконтроллеры, готовлюсь планомерно заниматься DSP. Основные предпочтения: RISC процессоры (ядра) с простой системой команд. Есть ещё интерес создать свой контроллер (хотя бы ядро) по своему образу и подобию , эмульнуть его на какой-нить Альтере . Думаю использовать симуляцию троичной логики - посмотреть её преимущества на деле. Если действительно дойдёт дело до проца (контроллера) - думаю создать для его программирования некий симбиоз АСМа с языками высокого уровня. Я представляю, чего я хочу, только нечётко пока. Общения на тему, я думаю, не получится - слишком велик разрыв того АСМа, к коему я привык, с писюковским огромным и неповоротливым АСМом.
black, "... Думаю использовать симуляцию троичной логики - посмотреть её преимущества на деле ..." мужчина! "... думаю создать для его программирования некий симбиоз АСМа с языками высокого уровня. ..." "... Я представляю, чего я хочу, только нечётко пока." "... слишком велик разрыв того АСМа, к коему я привык, с писюковским огромным и неповоротливым АСМом ... " прежде чем придумывать рекомендую сначала ознакомиться с языком ФОРТ. как раз для таких сумашедших (в хорошем смысле слова). я так думаю, если Вам понравилась троичная логика, то может быть и этот язык со своей специфичной архитектурой Вам понравится. о том, что он практичен, реентерабелен, может использоваться в системах реального времени и в специализированных устройствах говорят те факты, что он используется в системе перемещения багажом у "Американских авиалиний" или в системе интерактивного общения в аропорту с 500 процессорами и под 20 000 сенсорных датчиков. ПС. а вот некоторые высказывания про этот язык: "Только психованные программисты используют ФОРТ". "ФОРТ похож на Дао; это путь, и его можно только пройти. Его хрупкость есть его сила; его простота -- его направление".
Офигеть как много понаписали! Всё читать не стал, времени жалко. Помнится такой случай наблюдал... Нужно было запрограммировать алгоритм шифрования DES, у нас в команде один умелец сказал что типа это беру на себя, буду писать на ассемблере, потому что это язык для настоящего программера и будет быстрее работать. Короче промучался это умелец с месяц - так у него нифига не заработало. Программку на Си скачаную откуда то из сетей я лично откопилил за 20 минут, протестировал на соответсствие алгоритму. После этого случая ну пару раз использовал ассемблер, ну типа там для прямого доступа к портам. Но больше не видел необходимости. Кстати в наше время использовать ассемблер я вообще не вижу необходимости. Всякие там контроллеры и прочая мутотень уже программируются на языках типа Си (сам лично такое делал). Мож конечно и нравится кому язык... Так почему бы не программировать в машинных кодах?
При том, что я прочел то же самое в каком-то пособии. Обоснованием там было "принято называть". Не, я понимаю, восстановление данных, обеспечение работы в многопользовательском режиме и безопасность - это рулезно и вовсе даже актуально, но при чем здесь "база данных"? Чем "база данных" отличается от "массива данных" сама по себе? А ничем. Простая байтовая последовательность. Соответственно, все вопросы относительно различий адресуемы СУ: чем именно она управляет. Исходя из приведенных свойств, "базовость" у данных появляется, если СУ, в частности, содержит возможность восстановления данных и безопасность. Вот мне и интересно: какое отношние сервисные, в принципе, штуки, имеют к слову "база"? Я не вижу путаницы. Если подходить к БД с точки зрения наличия взаимосвязи элементов, FS - все та же БД, правда, не имеющая в структуре замкнутых цепочек связей. Насчет экспертных систем - аналогично: она может включать в себя СУБД как компонент. Угу. Поэтому данные свойства не могут описать сущность, а лишь характеризуют ее. Я просто не перенес его из одного списка в другой. Реализуемы. Не "реализованы". Перегрузка - никак. Такое возможно только при добавлении хорошей макронастройки, вводящей формальное описание функций и контролирующей конечный вид исходного файла исхода из анализа передавемых аргументов. Да и не нужна она, по большей части. Кстати, есть еще уточнения по поводу наследования, всвязи с чем реализация ООП с функциональностью, сравнимой с С++, можно поставить под вопрос. Смотри ниже. А про виртуальные функции я уже написал. Если есть вопросы по тексту - слушаю. ---- Так. Чего-то я наглючил. Во-первых, предложенный мной вариант предполагает фиксацию структуры. То есть, если _obj_def определен в начале структуры FILEOBJECT, для иных объектов он также должен быть первым. То же будет и для FILEOBJECT, если она будет определена как макрос. Что, в случае множественного наследования, рано или поздно приведет к невоможности дальнейшей разработки с использованием такой концепции. Это для статики. У динамики возникают другие трудности. Во-вторых, конструкторы и деструкторы порождающих классов в этой модели идут лесом. Возможно их восстановление посредством дописывания куда-нибудь в конец структуры, с завершающим нулем, но это уже надо смотреть на конкретном примере, насколько оно коряво получится. В-третьих, обращение к переменным класса возможно будет лишь через передачу дополнительного параметра или создание макронадстройки, обрабатываемой извне, что, в свою очередь, усложняет код (возможно, есть и более простые варианты, но пока ничего не придумывается). Итог: полноценно наследование реализуемо, но, при возможностях компилятора и макроопределений, нерентабельно. Куда проще создать отдельный объект, указатель на который, в случае нужды, сохраняется в переменной другого объекта. Получается не наследование, а вложенность, но с ней, при таком раскладе, иметь дело куда приятнее . Корректное и гарантированное наложение: LODSD CMP EAX, -1 JE _skip STOSD _skip: Зачем? Почему? ------- Так-таки уж и неповоротливым? Интересно посмотреть на нечто более продвинутое в этом плане. Ссылочку можна? -------- А вы попробуйте . Думаю, после пары килобайт кода желание задавать такие вопросы выйдет в сад. Навечно .
"При том, что я прочел то же самое в каком-то пособии. Обоснованием там было "принято называть"." не все книги одинаковы полезны. "Не, я понимаю, восстановление данных, обеспечение работы в многопользовательском режиме и безопасность - это рулезно и вовсе даже актуально, но при чем здесь "база данных"? ... Чем "база данных" отличается от "массива данных" сама по себе? ..." аккуратнее в терминах. база данных (БД) и СУБД - это две большие разницы. наверное поэтому-то и вся путаница. кстати, может я даже и скажу чем отличается БД от массива данных, если Вы дадите определение массива данных. теперь про ассемблер и ООП. "Перегрузка - никак. ... Да и не нужна она, по большей части." напоминает Ваши слова "Обоснованием там было "принято называть". " в ООП она нужна. да и одними макроопределениями тут не обойтись. "Получается не наследование, а вложенность, но с ней, при таком раскладе, иметь дело куда приятнее ." в терминах ООП это называется не вложенность, а композиция или агрегация, да и вообще ничего плохого в этом нет, наооборот, для создания качественного повторного использования компонент нужно композицию предпочитать наследованию класса. (в качестве примера см. технологию СОМ). да, фиксация структры не так уж и страшна. тот же макрос все расставит по своим местам. "В-третьих, обращение к переменным класса возможно будет лишь через передачу дополнительного параметра" именно так и есть. ПС. рекомендую как вариант посмотреть на 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