|
|
Регистрация Восстановить пароль |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
|
Опции темы | Поиск в этой теме |
12.07.2017, 11:25 | #1 |
Пользователь
Регистрация: 12.07.2017
Сообщений: 18
|
Можно ли FASM сделать высокоуровневым?
Приветствую всех.
Вопрос к специалистам: можно ли с Вашей позиции FASM, с учетом наличия в нем макросов, превратить в язык высокого уровня? И если нет, то чего в нем не хватает, что нужно доработать, чтобы выполнить эту задачу? Заранее благодарю за ответы. Сам, к сожалению, на ассемблере никогда практически не программировал, так что опыта не имею. Почему-то мы его не изучали, да и на практике особо не приходилось сталкиваться, но это скорее потому, что я никогда не работал по профессии программиста, все больше делал какие-то мелочи для себя да друзей. Именно поэтому и имеется потребность обратиться к более опытным коллегам. |
12.07.2017, 11:48 | #2 |
Старожил
Регистрация: 09.01.2008
Сообщений: 26,229
|
|
12.07.2017, 13:14 | #3 |
Старожил
Регистрация: 13.07.2012
Сообщений: 6,342
|
|
12.07.2017, 15:29 | #4 |
Пользователь
Регистрация: 12.07.2017
Сообщений: 18
|
Serge_Bliznykov, простите, но я никогда не слышал о таком языке программирования, как 2500+. Ява - это уже язык программирования высокого уровня. О нем вопрос не стоит.
waleri, понимаю, да только малость кривовато сделано... при чем настолько кривовато, что если учесть, что подавляющее большинство ПО в мире написано на Си, и то - как это ПО работает, то возникают значительные претензии к этому самому Си. Но, как мы понимаем - лечить его никто не будет, а как правило все только добавляют болезней и костылей. Всем. Теперь про "зачем"... Простите, но почти уверен, что будете смеяться и, скорее всего, не поймете суть дела. Но я парень честный - объясню, хоть и поднимут на смех. Я, в некотором роде - идеалист. И несколько владея вопросом электроники и программирования вообще, мне откровенно не понятно, почему калькулятор никогда не глючит (разве, что батарея села), никогда не тормозит, никогда не вылетает в бсод, и всяко разно ошибок не выдает, а все абсолютно ПО, которое есть в мире даже и не думает так себя вести. С точки зрения теории любое ПО на электронных компонентах должно работать абсолютно идеально, без ошибок, без тормозов и прочих "сюрпризов". Но этого, почему-то, не происходит. Я лично с компами дружу с 92-го года, и помнится мне в те времена если с компом и происходили какие-то беды, то только по причине внезапного пропадания света, криворукости программиста и нестабильности магнитных носителей данных. Все. Такого понятия как падение системы, глюки и тормоза наблюдать не приходилось. Но как только продвинулись дальше - тут уж началось... В общем, не будем долго растекаться мыслию по древу - надоело мне мучиться и страдать при работе с таким ПО. Причина всех причин - этот самый Ваш Си, кривой как равнинная речка. Все беды полезли оттуда и на нем же они стоят до сих пор. Конечно, есть и другие причины, кроме кривых языков программирования, но не суть. Суть в том, что в данный момент накоплено уже достаточно опыта в этих делах, как на аппаратном, так и на программном уровне. По сути, большинство опытных программистов уже вполне способны составить некое ТО на то, какой должен быть правильный язык программирования и как с ним работать, чтобы в последствии годами не заниматься отловом багов и прочей живности в устаревающих программах. Тщательно порывшись в анналах интернета я такого языка программирования так и не нашел. Вернее нашел, но то не совсем пока еще то... ДРАКОН - вменяемый визуальный алгоритмический язык. На данный момент обладает практически всеми возможными алгоритмическими средствами для всего чего угодно и еще с запасом вперед. Одно "но" - нет у него собственного синтаксиса и толкового компилятора/интерпретатора. Пока выходят из ситуации добавляя наклейку в виде стороннего языка программирования и текстового сборщика, который из Дракона по правилам стороннего языка лепит текстовую программу, которую потом можно откомпилить стандартными средствами. Но! В этом случае Дракон лишается всей своей истинной мочи, ибо впадает в те крайности, которыми его ограничивают используемые языки. Есть еще один вариант - асм. Но, он уж слишком низкоуровневый и даже с использованием Дракона писать на нем серьезное большегрузное ПО будет проблематично. С другой стороны, чем ЯП ближе к машинным кодам - тем он веселее и надежнее, так что по сути нужно создать ЯП из Дракона приблизительно такого же уровня как Си, только ровный и с широкой базой - от асма до полноценного высокоуровневого языка. Еще раз покопавшись в анналах пришел к выводу, что если поработать над синтаксисом фасма, с учетом его возможностей, то вполне может оказаться, что из него и можно будет получить требуемый профит. Однако - есть одно "но". В мои годы мы почему-то учили алгоритмический язык, машинные коды и сразу - высокоуровневые Бейсик и Паскаль, а асм почему-то пропускали. Так что до сего дня я просто знаю, что есть такая штука и зачем она нужна, но никогда не работал с ним всерьез, так что полноценно оценить возможности и мощь этого инструмента просто физически не могу... А теперь совсем конкретно по факту. Я считаю, что нужно потратить время и все переделать. Да - практически все сызнова. И начать нужно именно с разработки толкового ЯП. Не важно сколько это займет времени, не важно сколько людей на разных этапах примут в этом участие, но это нужно сделать, чтобы прекратить порочную практику кривого программирования, выравниваемого костылями, прикрученными к старым подпоркам. Пусть на это уйдет десяток лет, но задачу нужно исправить, все проблемы сегодняшнего дня в области ИТ нужно решить, опять начиная с самой базы, но уже с учетом наработанного опыта. Затея всего этого должна быть по принципу "если хоть не для себя, то - детям". Не люблю я, в общем, когда то, что по своей природе должно работать ровно и надежно, постоянно демонстрирует признаки тяжелого детства и деревянных игрушек. В данный момент я пока просто собираю представление о проблеме и ищу пути ее решения. В последствии готов тратить свое личное время на работу над этим проектом, помошники, я думаю, найдутся, ну и кроме того, в далекой перспективе я возможно даже найду средства для того, чтобы этот проект спонсировать и постепенно доводить до ума. А пока я ищу, работаю над более эффективной и современной файловой системой. Такие дела. Ну, теперь, если что - можно смеяться... |
12.07.2017, 15:44 | #5 |
Старожил
Регистрация: 09.01.2008
Сообщений: 26,229
|
понятно.
Бывает. Не уверен, что Вы потянете разработку нового ЯВУ, но для начала разберитесь, что такое язык программирования, какие они бывают, что это вообще такое и т.д. начать можно с википедии - Язык программирования Вы не поняли. Сейчас уже в мире разработано более двух с половиной тысяч языков программирования. вот, например, список языков программирования Хотите создать ещё один? Ну тогда вооружайтесь соответствующим математическим аппаратом и — вперёд! Безумству храбрых поём мы песню... p.s. FASM - язык Ассемблера. Он не отвечает вашим требованиям. Наоборот, написать глюкавую программу на Ассемблере намного легче, чем, например, на той же Java. p.p.s. извините, если я чем-то нарушил Ваши мечты об идеальном софте. я больше не буду. |
12.07.2017, 16:25 | #6 |
Пользователь
Регистрация: 12.07.2017
Сообщений: 18
|
Serge_Bliznykov, похоже Вы не совсем меня поняли. Программист - это моя первая профессия, по которой я просто никогда не работал. Сейчас я пользуюсь для разных нужд несколькими ЯП, правда ни в один из них я не влезаю по уши, достаточно того, что знаю. Так что разбираться что такое ЯП мне не нужно, я и так вполне владею темой. С асмом у меня опыта нет - вот и спрашиваю.
Дело не в том, чтобы создать еще один такой же, как остальные. Дело в том, что бы создать один, но правильный ЯП, в основе которого лежит верный с алгоритмической точки зрения механизм работы, тесно завязанный на аппаратные особенности архитектуры. Собственно речь идет не о самом ФАСМ, а о том, чтобы на его базе создать ЯП из Дракона..., а Дракон сам по себе ликвидирует "глюкавость", если только все сделать правильно - это его основное преимущество. |
12.07.2017, 16:30 | #7 | |
Старожил
Регистрация: 13.07.2012
Сообщений: 6,342
|
Потому что калькулятор выполняет элементарные действия.
Цитата:
А теперь попробуйте написать хоть какое-то ПО, у которого логики чуть побольше, чем у калькулятора, на электронных компонентах и посмотрим, что у вас получиться. Создается впечатление, что вы не имеете опыта ни с С, ни ассемблером, что не удивительно, ибо многие считают С высокоуровневым ассемблером. |
|
12.07.2017, 16:47 | #8 | |||
(aka Jin X) !RTFM!
Форумчанин
Регистрация: 14.12.2014
Сообщений: 295
|
Цитата:
Цитата:
С чего вы взяли, что Си, C++ или Pascal/Delphi – глючные языки программирования с костылями? Да, чем сложнее язык, тем больше в них каких-то нюансов, о которых нужно знать и иметь в виду. Но тут уже всё зависит от сложности задачи, дебрей языка, в которые лезет программист, знания нюансов и, как вы правильно заметили, прямоты или кривоты рук программиста. Что для одного баг, для другого (знающего нюансы) – фича. Но в любом случае любой сложный язык порождает проблему дырявых абстракций (почитайте на досуге ), а значит незнание глубинных нюансов языка не освобождает от ответственности. Цитата:
Или вы считаете, что сможете написать язык (или ОС) без единого бага? Или собрать гениев, которые сделают это? Ну что ж, попробуйте... только реалистично оцените свои возможности и риски, чтобы лет через надцать не было мучительно больно за потраченные не на то годы...
Делаю лабы на Asm/Delphi/C++/Python/VBA(Excel): asmlabs.ru
Последний раз редактировалось 7in; 12.07.2017 в 16:52. |
|||
12.07.2017, 16:53 | #9 | |||||
Лис
Старожил
Регистрация: 18.09.2015
Сообщений: 2,409
|
flamehowk
Давайте к нам на remdev.org. 2500+ ЯВУ - это мало. Их сейчас насчитывается более 100 тыс. Вы и в правду идеалист. Цитата:
Цитата:
Цитата:
Ваш центральный процессор с надёжностью 10^12 совершает одну ошибку раз в час. Однако в большинстве случаев она остаётся не замеченной, благодаря свойству устойчивости. Зато вот драйвер видео-карты из-за ошибок вынужден перезагружаться 1 раз в 10 секунд. Но это происходит скрыто от пользователя и он ничего не замечает. Когда программисты CUDA постоянно сталкиваются с этой проблемой. Цитата:
Лично я что-бы не вводить путаницу разделяю несколько уровней обобщённости(высокоуровнивости). Цитата:
Где, то у меня книга была с этой историей. Но это было в 70-тых годах. Сейчас требования надёжности поменялись. Из современных к примеру язык программирования AL-IV (АЛФОР) Хотя у него тоже имеются недостатки с надёжностью. Проблемы я вижу в другом. Язык не решает проблему, а системы настолько сложны что мы не знаем как их протестировать. Большинство ошибок Windows, QT связаны с отсутствием интеграционного тестирования. Мы умеем тестировать модули автономно, но не умеем их тестировать в связке. И тут как раз вспоминаем UML. Он в какой-то мере решает эти проблемы. Но нет чётких руководств по его применению. Нужны шаблоны и кейсы для тестирования систем, аналогично тому как это сделано для автономных единиц исполнения.
Хорошо поставленный вопрос это уже половина ответа. | Каков вопрос, таков ответ.
У дзен программиста программа делает то что он хотел, а не то что он написал . Последний раз редактировалось Pavia; 12.07.2017 в 16:56. |
|||||
12.07.2017, 17:19 | #10 |
(aka Jin X) !RTFM!
Форумчанин
Регистрация: 14.12.2014
Сообщений: 295
|
Все написано людьми, а значит с повышением сложности чего-либо увеличивается вероятность допустить ошибку. Даже если это делает гений и за ним следят ещё десять таких, то написав сотни тысяч и миллионы строк кода можно что-то неучесть и косякнуть. А если ошибка будет в какой-то базовой функции, которая будет использоваться в нескольких более высокоуровневых, а та, в свою очередь, будет использоваться в ещё более высокоуровневой, то может быть крах в совершенно неожиданном месте (и миллион юзеров, протестировавших какую-либо функцию не дают гарантий того, что всё написано идеально). И ещё, как правильно заметил Pavia, разные части системы при взаимодействии могут выдать какой-нибудь у-упс. Это как если употребить идеально произведённое молоко и идеально приготовленную солёную рыбу, результат может превзойти все ожидания Если бы можно было всё писать через максимально простые процедуры (типа A+B, C*D), в которых ошибиться сложно, результат был бы более устойчивым, но к сожалению, не все процедуры можно сделать такими элементарными, да и даже в элементарном можно накосячить, если соединить одно с другим (а ведь разные модули пишут разные люди... пусть даже у них есть какой-то регламентирующий документ). Любой опыт нарабатывается веками и тысячелетиями. И вот так с бухты-барахты создать идеальный язык не получится. Уголовный и прочие кодексы писались не один год и даже век. И то куча дыр, лазеек, неучтённостей. И каждый год несколько новых законов выходит...
Делаю лабы на Asm/Delphi/C++/Python/VBA(Excel): asmlabs.ru
|
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Можно ли установить пакет '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 |