Форум программистов
 

Восстановите пароль или Зарегистрируйтесь на форуме, о проблемах и с заказом рекламы пишите сюда - alarforum@yandex.ru, проверяйте папку спам!

Вернуться   Форум программистов > Низкоуровневое программирование > Assembler - Ассемблер (FASM, MASM, WASM, NASM, GoASM, Gas, RosAsm, HLA) и не рекомендуем TASM
Регистрация

Восстановить пароль
Повторная активизация e-mail

Купить рекламу на форуме - 42 тыс руб за месяц

Ответ
 
Опции темы Поиск в этой теме
Старый 12.07.2017, 23:19   #11
flamehowk
Пользователь
 
Регистрация: 12.07.2017
Сообщений: 18
По умолчанию

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


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


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

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

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


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


Цитата:
Сообщение от Pavia Посмотреть сообщение
Язык не решает проблему, а системы настолько сложны что мы не знаем как их протестировать.
Значит нужно создать систему, в которой эта проблема будет решена на аппаратном уровне.


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


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


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


Цитата:
Сообщение от 7in Посмотреть сообщение
Уголовный и прочие кодексы писались не один год и даже век. И то куча дыр
Совершенно некорректное сравнение, ибо "закон як дышло - куды повэрнулы, туды й выйшло".
flamehowk вне форума Ответить с цитированием
Старый 12.07.2017, 23:21   #12
flamehowk
Пользователь
 
Регистрация: 12.07.2017
Сообщений: 18
По умолчанию

Цитата:
Сообщение от Pavia Посмотреть сообщение
Давайте к нам на remdev.org.
Даю...
А куда зайти?
flamehowk вне форума Ответить с цитированием
Старый 12.07.2017, 23:47   #13
flamehowk
Пользователь
 
Регистрация: 12.07.2017
Сообщений: 18
По умолчанию

Про АДу почитал - интересно. В общем и об умной девочке Аде и про язык АДА я и раньше знал, но правда никогда не вдавался в подробности. История, конечно, интересная, но мало к нам применимая, потому как нам нужно либо писать ЯП для широко распространенных писишных архитектур, либо вовсе разрабатывать свою собственную с нуля и синхронно с ней разрабатывать ЯП.
flamehowk вне форума Ответить с цитированием
Старый 12.07.2017, 23:49   #14
waleri
Старожил
 
Регистрация: 13.07.2012
Сообщений: 6,493
По умолчанию

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

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

Цитата:
Сообщение от flamehowk Посмотреть сообщение
но там есть ошибка проектирования
Еще бывают и ошибки реализации.

Я пас...

Последний раз редактировалось waleri; 12.07.2017 в 23:52.
waleri вне форума Ответить с цитированием
Старый 12.07.2017, 23:53   #15
flamehowk
Пользователь
 
Регистрация: 12.07.2017
Сообщений: 18
По умолчанию

Цитата:
Сообщение от Pavia Посмотреть сообщение
Из современных к примеру язык программирования AL-IV (АЛФОР)
Пока не совсем понятно - зачем он вообще создавался и что это может нам дать в надежности, если суть языка, насколько я понял, быть промежуточным звеном между мыслью программиста и теми же костылями в виде Шарпа, Джавы и прочих языков?
flamehowk вне форума Ответить с цитированием
Старый 12.07.2017, 23:54   #16
flamehowk
Пользователь
 
Регистрация: 12.07.2017
Сообщений: 18
По умолчанию

Цитата:
Сообщение от waleri Посмотреть сообщение
что мол проектируете наборы инструкций но не разбираетесь в ассемблере
Для той архитектуры, которой я занимаюсь еще не существует ассемблера...
flamehowk вне форума Ответить с цитированием
Старый 13.07.2017, 00:03   #17
flamehowk
Пользователь
 
Регистрация: 12.07.2017
Сообщений: 18
По умолчанию

Цитата:
Сообщение от 7in Посмотреть сообщение
Но в любом случае любой сложный язык порождает проблему дырявых абстракций (почитайте на досуге
Про дырявые абстракции почитал. По сути, человек с другой стороны выразил ту же мысль, что и я... только по факту наличия проблемы, но не предложения ее устранять.
flamehowk вне форума Ответить с цитированием
Старый 13.07.2017, 01:05   #18
7in
(aka Jin X) !RTFM!
Форумчанин
 
Аватар для 7in
 
Регистрация: 14.12.2014
Сообщений: 295
По умолчанию

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

Последний раз редактировалось 7in; 13.07.2017 в 01:08.
7in вне форума Ответить с цитированием
Старый 13.07.2017, 01:33   #19
flamehowk
Пользователь
 
Регистрация: 12.07.2017
Сообщений: 18
По умолчанию

Если хорошо подумать над логикой всех процессов, то окажется, что если только мы не ставим задачу создать ИИ, нам совершенно не нужно делать безконечной и безконтрольной вложенности функций. В общем, как я уже сказал, все зависит от того насколько прагматично мы подойдем к глобальному проектированию данной системы с учетом всех возможных способов ее использования, включая человеческий фактор. Не все так плохо, как Вы привыкли видеть в том, что уже существует.
flamehowk вне форума Ответить с цитированием
Старый 13.07.2017, 12:34   #20
Pavia
Лис
Старожил
 
Аватар для Pavia
 
Регистрация: 18.09.2015
Сообщений: 2,409
По умолчанию

Цитата:
Сообщение от 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 рода.
Хорошо поставленный вопрос это уже половина ответа. | Каков вопрос, таков ответ.
У дзен программиста программа делает то что он хотел, а не то что он написал .

Последний раз редактировалось Pavia; 13.07.2017 в 12:44.
Pavia вне форума Ответить с цитированием
Ответ


Купить рекламу на форуме - 42 тыс руб за месяц

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск


Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Можно ли установить пакет 'directx app' от Visual Studio, на win 7. Или это можно сделать только на win 8 win 10. vik7878 Софт 1 07.12.2016 10:47
можно ли писать php код внутри javascript инструкции if? если можно, то как это сделать? Ubihinon JavaScript, Ajax 2 20.02.2012 08:40
можно ли писать php код внутри javascript инструкции if? если можно, то как это сделать? Ubihinon PHP 2 18.02.2012 17:45
Чем отличаеться fasm от fasm editor&? TotKtoNado Assembler - Ассемблер (FASM, MASM, WASM, NASM, GoASM, Gas, RosAsm, HLA) и не рекомендуем TASM 5 07.11.2011 17:00
можно ли сделать wolf777 PHP 7 06.11.2011 18:25