Можно ли FASM сделать высокоуровневым?

[flamehowk]

Сообщение от waleri

А теперь попробуйте написать хоть какое-то ПО, у которого логики чуть побольше, чем у калькулятора, на электронных компонентах и посмотрим, что у вас получиться.

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

Сообщение от waleri

Создается впечатление, что вы не имеете опыта ни с С, ни ассемблером,

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

Сообщение от 7in

Или вы считаете, что сможете написать язык (или ОС) без единого бага?

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

Сообщение от Pavia

Однако надёжность только повысилось у меня компьютер работает бес сбоев сутками, когда как в 98 перезагружался каждые 2 часа.

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

Если немного резюмировать, то на самом деле может быть две ситуации - либо устройство можно спроектировать и тогда оно должно работать правильно в независимости от его сложности, но нужно его спроектировать верно, либо же проектирование заданного устройства вообще не возможно выполнить, ибо данная задача является нерешаемой.
Что касается ЦПУ + ПО - технически это решаемая задача, нужно ее только правильно поставить и решить.

Сообщение от Pavia

Зато вот драйвер видео-карты из-за ошибок вынужден перезагружаться 1 раз в 10 секунд.

Вы лишь еще раз подтверждаете мои слова - все, что сделано в наше время стоит на костылях прошлых поколений... Но это НЕ НОРМАЛЬНО. Так не должно быть. Нужно все переделать, вот и вся задача. Кстати - включая и архитектуру, над чем я, собственно, и работаю в свободное время. Все ошибки, о которых Вы говорите - есть следствие ошибки проектирования на том или ином уровне. Не важно где она, то ли в слишком малом размере электронных компонентов, то ли в плохом расчете синхронизации сигналов управления, то ли в самом ПО драйверов, то ли в крайней нестабильности всех компонентов - но там есть ошибка проектирования и это единственная причина по которой система работает не так, как должна. Мы это можем исправить, если не будем гнаться за сверхприбылями ценой некачественных решений, а будем делать на века и толково.

Сообщение от Pavia

Язык не решает проблему, а системы настолько сложны что мы не знаем как их протестировать.

Значит нужно создать систему, в которой эта проблема будет решена на аппаратном уровне.

Сообщение от 7in

написав сотни тысяч и миллионы строк кода можно что-то неучесть и косякнуть.

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

Сообщение от 7in

разные части системы при взаимодействии могут выдать какой-нибудь у-упс.

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

Сообщение от 7in

И вот так с бухты-барахты создать идеальный язык не получится.

Почему "с бухты барахты"? Я ничего такого пока не обнаружил. Стоит простая и четкая задача, все что необходимо для ее выполнения уже имеется. Здесь куда справедливее применить другую пословицу: "глаза боятся, а руки делают".

Сообщение от 7in

Уголовный и прочие кодексы писались не один год и даже век. И то куча дыр

Совершенно некорректное сравнение, ибо "закон як дышло - куды повэрнулы, туды й выйшло".

[flamehowk]

Сообщение от Pavia

Давайте к нам на remdev.org.

Даю...
А куда зайти?

[flamehowk]

Про АДу почитал - интересно. В общем и об умной девочке Аде и про язык АДА я и раньше знал, но правда никогда не вдавался в подробности. История, конечно, интересная, но мало к нам применимая, потому как нам нужно либо писать ЯП для широко распространенных писишных архитектур, либо вовсе разрабатывать свою собственную с нуля и синхронно с ней разрабатывать ЯП.

[waleri]

Сообщение от flamehowk

Дело в том, что я немного занимаюсь проектированием архитектуры цпу

Дело в том, что цпу спроектировать проще и легче, чем законченную логику. Именно поэтому микропроцессоры набралю такую популярность.

А если вы пытаетесь сказать, что мол проектируете наборы инструкций но не разбираетесь в ассемблере, то это не ко мне...

Сообщение от flamehowk

но там есть ошибка проектирования

Еще бывают и ошибки реализации.

Я пас...

[flamehowk]

Сообщение от Pavia

Из современных к примеру язык программирования AL-IV (АЛФОР)

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

[flamehowk]

Сообщение от waleri

что мол проектируете наборы инструкций но не разбираетесь в ассемблере

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

[flamehowk]

Сообщение от 7in

Но в любом случае любой сложный язык порождает проблему дырявых абстракций (почитайте на досуге

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

[7in]

То есть Вы хотите создать такой язык, который не будет содержать дырявых абстракций вообще в принципе?
Если так, то это весьма идеалистическая, я бы даже сказал утопичная идея... (ИМХО, разумеется)
Даже в такой, казалось бы, точной науке, как математика, есть нюансы. Сначала нас в школе учат тому, что все числа целые и положительные, а потом оказывается, что есть ещё и дробные, а потом что и отрицательные тоже бывают. А ещё говорят, что на ноль делить нельзя и корень из отрицательного числа не извлечь. А дальше изучаем пределы и комплексные числа. Т.е. человек думал так и решения выдавал соответствующие, а оказывается-то, что есть "нюансы".
А тут (в программировании) всё ещё хуже. Если в математике перед изучением степени проходят умножение, а ещё раньше - сложение, то тут любая функция высокого уровня (а без них никак) скрывает то, что написано в вызываемой ею низкоуровневой функции (и в документации подробный алгоритм обычно не приводится). А нюансы, о которых не знает тот, кто эту высокоуровневую функцию использует, всегда найдутся. Мне, конечно, тоже не всегда доставляет удовольствие чтение секции "Remarks" в описаниях WinAPI-функций из MSDN, но пока без этого никуда. Более того, иногда нужно ещё и "See also" почитать, да и вообще иметь представление об архитектуре ОС.
Можно делать защиту от "дурака" на каждом этапе, конечно, но надо понимать, что один делает что-то из дурости, а другой намеренно. Да и мыслей всех дураков не прочесть, а земля талантами полна...
Конечно, всё возможно в этом мире, но это задача не просто амбициозная, а из разряда "как сделать мир во всём мире"

[flamehowk]

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

[Pavia]

Сообщение от flamehowk

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

Вы в своём ЦПУ применяете код Грея?

Сообщение от flamehowk

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

Вот в этом и проблема. У железячников системы простые как часы. А у программистов они на два-три десятичных порядков сложнее. У нас функций в разы больше. И не только функций. Каждый объект это машина состояний. А в ваших часах и цпу их то 1-2. А QT насчитывает более 1000 штук классов.

Не говоря о том что программы как раз и исправляют недоработки по функционалу железа.

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

Сообщение от flamehowk

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

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

Сообщение от flamehowk

Как я написал чуть выше - технически все должно работать идеально,

Увы, но вы не правы. Вся техника ломается и страдает от ошибок. А если говорить о философских и математических аспектах то и тут есть ошибки.
Нет систем сто процентнов правильных. Они лишь правильные в меру ваших знаний. А ведь за кругом ваших знаний располагается бесконечность вашего незнания.

Сообщение от flamehowk

Но если ее правильно спроектировать, применить качественные материалы, то ее суммарные люфты будут настолько малы, что их роль в работе передаточного узла можно будет не учитывать

Заблуждаетесь. Вы уже её учли при проектирование.

Сообщение от flamehowk

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

Опять заблуждаетесь. Дайте определение критической нагрузки? Критическая нагрузка это нагрузка при которой изделие выходит из строя.

Сообщение от flamehowk

Что касается ЦПУ + ПО - технически это решаемая задача, нужно ее только правильно поставить и решить.

Технически. Эта не решаемая задача. Открываем любой учебник по тестированию. Доказать что функция работает правильно мы не можем. Даже для самой простой.

Сообщение от flamehowk

Значит нужно создать систему, в которой эта проблема будет решена на аппаратном уровне.

:D
Видимо стоит напомнить какая надёжность была у ЦПУ 50-60-тых годов. один отказ на 1000 операций. И раз в 5 минут приходилось менять сгоревшую лампу. И ещё напомню что в те времена устраивали соревнования на скорость и точность с человеком.

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

В том-же 8086 есть флаг чётности, который служит для проверки правильности счёта.

А вы знаете сколько ошибок находят в серийном процессоре через год после его выхода?
И вообще x86 (AMD-64) это очень кривая архитектура.

Сообщение от flamehowk

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

Увы но пока мы этого не умеем. Все попытки начиная с 70-тых годов провалились.
Не то что-бы совсем. Качество повысилось. Но не намного.
Статистический анализ.
- проверка грамматики
- проверка типов
- проверка частых ошибок
Динамический анализ
Проверка технических заданий на полноту и логическую правильность.
Автономное тестирование
Интеграционное тестирование
системное тестирование.

Включая появления отдельной специальности тестировщик ПО.

Сообщение от flamehowk

но там есть ошибка проектирования и это единственная причина по которой система работает не так, как должна.

Не единственная. Ошибки вычислений делятся на 3 рода.