Комментарии 15
мне больше всего fasm нравился, когда в универе нужно было что то писать, в проде ни когда не приходилось что то писать чисто на asm
AsmX Foundation реализовали довольно необычную систему, которая больше похожа на JIT‑компилятор, но не является классической виртуальной машиной. Впервые я сталкиваюсь с подобным подходом, и это можно считать своего рода ноу‑хау
Ассемблер на интерпретаторе JS-кода - это и вправду ноу-хау, потому что смысла в этом = 0.
Ассемблер — это низкоуровневый язык программирования, который напрямую взаимодействует с аппаратным обеспечением.
AsmX подходит под данное определение? Вопрос конечно риторический. С учётом того, как автор данной статьи восхищается AsmX - не удивлюсь, что он есть также и автор данного ассемблера. Более подробно про AsmX можно почитать в статье: Обзор языка программирования AsmX.
Спасибо за ваш комментарий!
Вы абсолютно правы, что традиционный ассемблер - это низкоуровневый язык, напрямую взаимодействующий с аппаратным обеспечением.
AsmX действительно не является классическим ассемблером в привычном понимании этого термина, так как он не взаимодействует напрямую с аппаратным обеспечением. Это ближе к концепции высокоуровневой абстракции или виртуальной платформы, где ассемблерный синтаксис используется для управления кодом в окружении, которое не является "железом" в традиционном смысле. Однако, это не означает, что в этом подходе нет своего рода уникальности или инновации (или даже ноу-хау), особенно если он позволяет решать задачи, которые стандартные виртуальные машины или JIT-компиляторы не закрывают.
Что касается ReLax, я не сказал бы, что он меня "не смутил". Это действительно виртуальная машина, и она, как вы правильно заметили, не является ассемблером в классическом понимании. Однако, оба этих проекта, насколько я понимаю, предлагают свои решения для специфичных задач, и здесь стоит корректно различать архитектурные подходы, которые они используют, хотя и позиционирование некоторых терминов может быть спорным.
Оба проекта, AsmX и ReLax, хоть и используют терминологию ассемблера, не являются классическими ассемблерами в традиционном понимании этого слова. Они скорее представляют собой высокоуровневые абстракции.
Вы справедливо отметили, что использование термина "ассемблер" в данном контексте вводит в заблуждение. Более точным было бы называть их "псевдо-ассемблерами" или "виртуальными низкоуровневыми языками".
Однако, это не означает, что в этом подходе нет своего рода уникальности или инновации (или даже ноу-хау), особенно если он позволяет решать задачи, которые стандартные виртуальные машины или JIT-компиляторы не закрывают.
И какие задачи он позволяет решать, если даже обычный высокоуровневый JS будет быстрее и читабельнее?
Извиняюсь за циничность, но почему в статью попала эта детсадовская поделка уровня BolgenOS (а учитывая код - никак иначе это назвать нельзя, ну блин, парсер на регулярках, без построения AST, использующий самый грубый и медленный алгоритм разбора -- каждый шаг матчить новое значение -- это даже не смешно), а не, например, LLVM IR, который на выходе может выдавать тот же бинарь под веб или любую существующую платформу. Или почему не WASM, который на порядки быстрее и эффективнее этой поделки? Или почему не AssemblyScript? Или почему... А я напоминаю, что перечисляю только ассемблерные языки на которых можно написать что-то под веб, которые в разы популярнее (28 звёздочек у этого AsmX с 1 контрибьютером, против 3к+ звёздочек только у одной репы спеки WASM, и 7.5к у транспайлера из С/С++), производительнее и качественнее.
Да миллион же всяких более популярных решений. Тот же C# во что собирается? Правильно, в CLR, который фактически является таким же высокоуровневым ассемблером и поддерживает JIT, не?
Какое это блин "ноу-хау"? Это просто шутка, которая слишком сильно затянулась, раз кто-то это пытается оценить серьёзно.
Поддерживаю @Number571, выглядит всё так, что вы и есть автор этой поделки, иначе я даже не знаю как ещё объяснить подобное...
Спасибо за ваш комментарий! Ваше мнение весьма ценно.
Благодарю за ваше мнение и за то, что поделились информацией о различных ассемблерных языках и технологиях, таких как WASM, AssemblyScript и LLVM IR.
Сравнивать AsmX с такими проектами, как LLVM IR, не совсем корректно. Это как сравнивать самодельный деревянный велосипед с гоночным автомобилем. Оба средства передвижения, но классы разные.
Касательно сравнения по количеству звёзд на GitHub, это действительно не всегда корректный показатель качества или значимости проекта. Звёзды могут отражать популярность, но не всегда дают полную картину о практической ценности и функциональности.
Вопрос о "ноу-хау" в данном случае, вероятно, не стоит воспринимать буквально, как принципиально новое изобретение. Скорее, речь может идти об образовательном или экспериментальном аспекте проекта. В таком контексте, простота реализации и использование менее эффективных методов (например, парсера на регулярных выражениях) могут быть оправданы целью обучения. Важно, что автор попробовал реализовать что-то сложное, пусть и не самым оптимальным способом.
Не исключено, что AsmX был создан школьником. Это не необходимо оценивать как нечто плохое или незначительное. Наоборот, это может быть примером интереса и увлеченности молодого человека.
Наконец, я хочу подчеркнуть, что я не являюсь автором AsmX и выражаю свое мнение исключительно как независимый наблюдатель. Благодарю вас за ваш интерес и конструктивную критику!
В данной статье мы не будем рассматривать ARM, AVR и другие микроконтроллерные архитектуры, а сосредоточимся исключительно на компьютерных ассемблерах.
В порядке придирок.
ARM, AVR -- это, конечно, архитектуры, но не обязательно микроконтроллерные, если говорить об ARM (есть и ПК, и полноценные серверы, да и смартфоны не на микроконтроллерах реализованы). "Персоналочная" архитектура, неофициально обозначаемая как x86 (официально -- IA-32 для 32-разрядных процессоров и AMD64 / Intel64 для 64-разрядных) -- это тоже архитектура (и, в принципе, может быть и микроконтроллерной: технических препятствий нет). Архитектура определяет, как "выглядит" процессор (или вычислительная система в целом) с точки зрения программиста -- в первую очередь, какова его система команд. Эта тема в статье затрагивается, но весьма несильно, что неудивительно: для глубокого погружения в систему команд даже IA-32, без всего, что появилось в 64-разрядных процессорах, потребуется толстенный талмуд.
Но в целом автор рассуждает не о системе команд, а о ассемблерах в узком смысле слова -- о трансляторах языка ассемблера. В спойлере "Программы на разных ассемблерах" можно увидеть примеры одного и того же кода для разных трансляторов.
По сути, эта статья даёт обзор синтаксиса нескольких трансляторов для одного исходного языка, и её название формально является совершенно корректным. Но реальное употребление слова "ассемблер" в жизни куда шире и даже, скорей, обозначает именно язык, а не транслятор (более того, нередко встречается словосочетание "компилятор ассемблера", что не очень-то правильно). Как по мне, лучше б название было изменить на что-нибудь вроде "Знакомимся с трансляторами ассемблера для ПК" -- тогда сразу станет ясно, о чём пойдёт речь.
Это не трансляторы ассемблера, а ассемблеры. Ассемблер - не язык, а транслятор мнемокода.
Я выше уже откомментировал название статьи. Раньше там стояло просто "ассемблеры" и формально это было корректно ("ассемблер" -- транслятор, а транслируемый им язык -- "язык ассемблера", assembly language). Но в реальном использовании этого слова под ассемблером почти всегда понимают именно язык, а отнюдь не транслятор. Явное упоминание последнего в названии статьи сразу говорит, что речь пойдёт именно о трансляторах, а не о языке как таковом. Кстати, термин "мнемокод", кажется, давным-давно уже не используется...
Было бы интересно почитать про сравнение дисассемблеров.
У меня статья вызвала некоторое недоумение:
ну сравнивать нечто типа "виртуального assembly language" с реальным несколько писец как некорректно;
сам уровень статьи (ну песочница же ведь);
некоторые заявления автора как в статье так и в комментах, причем они иногда не коррелируют;
ну и вишенка - когда-то давным давно я писал на assembly language c компиляцией TASM Borland - так размер в памяти был как-то сильно много меньше при сильно более сложной программе (а для умножения в 3 строки - там наверное до пары десятков байт) и время исполнения было ну буквально единицы тактов. Откудова у автора взялося 256KB на NASM-е? То ли он оптимизацию не делал то еще что-то. И откудова 0,38 секунды времени исполнения 6 строчек в assembly language? Может я что-то не доганяю. Ведь вся программка влезет в кэш первого уровня - там просто моментом все исполнится. Снова я чего-то не догоняю... Старею видать...
Очень странные результаты тестов, скорее всего, некорректные.
Знакомимся с трансляторами ассемблера для ПК