ошибка в названии статьи, правильное название — "язык ассемблера"... а собственно ассемблер — это разновидность транслятора... слово "ассемблер" часто используют для обозначения языка ассемблера просто для краткости или по незнанию, но это не верно... --Dionys 12:29, 20 Июл 2004 (UTC)
Ассемблер это и символическая запись команд конкретного микропроцессора, и сам транслятор, и его входной язык (который может содержать, скажем, специфические для транслятора макросредства). Одно слово, но три значения. --Арви Хэкер20:09, 16 мая 2007 (UTC)[ответить]
Тут уж как условиться, так и будет (Перельмана читал - про "обход вокруг белки"?). Ясен пень, для краткости лучше везде "ассемблер". Нужно только добавлять примечания/секции про терминологию. — Vano03:08, 26 ноября 2007 (UTC)[ответить]
Ассемблеры для архитектур
По хорошему должен быть в Википедии портал, отправляющий на странички по ассемблерам конкретных архитектур. Ну и на общие bla-bla-bla про синтаксисы AT&T, NASM'а, историю этих компиляторов и т.д. --Арви Хэкер20:09, 16 мая 2007 (UTC)[ответить]
Не, портал - это слишком (порталы вообще для другого предназначены). Для описания всех разновидностей достаточно раздела; если разрастется - статьи. Все-таки у нас тут не техническое описание языков со всеми командами и директивами. — Vano03:03, 26 ноября 2007 (UTC)[ответить]
Почему в статье синтаксис Intel ассемблера описан как единственный? Есть еще AT&T(UNIXовый, тоже распространенный) и bin86(ужас на котором загрузчик Linux 2.0 был, теперь уже перешел на AT&T усилиями Peter Anvin). — Эта реплика добавлена с IP 212.152.41.35 (о) 20:12, 12 января 2008 (UTC)[ответить]
Исследования вирусов
Хотелось бы спросить, с каких это пор исследование вирусов стало нелегальным ? Ведь сами производители антивирусов исследуют их точно таким же образом, а если не исследуют - то грош цена их антивирусам. Неужели они боятся что такие люди унесут секреты обезвреживания вирусов в массы и их продажи упадут ? Помоему они сами запрещают делать то чем сами активно занимаются. Пусть по крайней мере покажут строку в УК РФ или в конституции РФ где бы это запрещалось. Ведь пока есть только статья о "Создании И(!) распостронении вредосноных программ" исследования вирусов под эту статью не попадает, а значит данное утверждение лишено всякого смысла и может быть рассмотренно как неверная трактовка закона или изобретение своих собственных, а это как раз попадает под статью.
62.141.50.14905:54, 14 августа 2008 (UTC)Исследователь[ответить]
Ссылки
Ссылка на ASMFAQ (http://sgww.ru/asmfaq.htm) Внимание этом FAQ находится ошибка, в таблице значений для команды xor написано
Какой умник требует ссылки на абзацы типа:
>>>
Искусный программист, как правило, способен написать более эффективную программу на ассемблере, чем те, что генерируются трансляторами с языков программирования высокого уровня, то есть для программ на ассемблере характерно использование меньшего количества команд и обращений в память, что позволяет увеличить скорость и уменьшить размер программы.
>>>
? Если не понимает предмета написанного, чего требует? Это ж то же самое, что попросить ссылочку на заявление вроде "Как правило, автобусы опаздывают"...
87.252.243.17123:47, 15 августа 2009 (UTC) Почитавший[ответить]
Как это соотносится?
Искусный программист, как правило, способен написать более эффективную программу на ассемблере, чем те, что генерируются трансляторами с языков программирования высокого уровня, то есть для программ на ассемблере характерно использование меньшего количества команд и обращений в память, что позволяет увеличить скорость и уменьшить размер программы.
и
Главное преимущество ассемблера практически полностью нивелируется хорошей оптимизацией в современных компиляторах языков высокого уровня.
Нет тут противоречия, поскольку ключевые слова - "искусный" в первом и "практически" во втором утверждении. Искусные программисты - это очень малая часть всех программистов (даже среди тех, кто может на асме писать), но даже искусные программисты не обязательно всегда пишут безупречный код. И потому, искусность в одном аспекте оптимизации может нивелироваться пробелами в других (например, в знании каких-то процессорных тонкостей). Так что да, на практике, в большинстве случаев оптимизация компилятором будет скорее всего не уступать ручной оптимизации. -- AVBtalk21:38, 9 января 2010 (UTC)[ответить]
На самом деле всё что вы сказали было бы правильней описать "Главное преимущество ассемблера практически полностью нивелируется неискусностью и незнаниями программистов на нём". По-моему к самому языку это вообще-то мало относится. Xchgall21:48, 9 января 2010 (UTC)[ответить]
к самому языку это вообще-то мало относится - во-первых, языки в отрыве от носителей/программистов мало что значат. То, что ассемблер - это более тонкий инструмент, не будет ничего значить, если его тонкостью некому будет воспользоваться. И наоборот: оптимизация компилятора сглаживает как неэффективность самого языка, так и неэффективность работы программистов. Соответственно, это имеет к языку прямое отношение - его преимуществом является "тонкость", но это преимущество нивелируется как низким уровнем среднего программиста, так и хорошими оптимизаторами. Во-вторых, ваша формулировка по сути говорит то же самое, что и было сказано изначально, только без детализации. Так что если в исходных утверждениях вы видите противоречие, то и в вашей формулировке оно остаётся. -- AVBtalk23:59, 9 января 2010 (UTC)[ответить]
AVB, 1-й пункт недостатков весьма неопределенный. "Могут нивелироваться", то есть, могут, а могут и не нивелироваться, то есть формально правильно, но читателю преподносится мнение, не подкрепленное фактами. В указанной Вами ссылке Касперски пишет
Заключение И все же, есть области, в которых ассемблер необходим - можно даже сказать, неизбежен. В первую очередь это высокопроизводительные математические и графические библиотеки, использующие векторные инструкции типа MMX или SSE. На эффективную векторизацию данных компиляторы, увы, не способны.
И на языках высокого уровня тоже надо знать, как писать. На любом языке можно написать сколь угодно неэффективную программу
Пример ошибки компилятора: http://forums.topcoder.com/?module=Thread&threadID=631917&start=0&mc=21
Реальный недостаток ассемблера -- это то, что при написании на языках высокого уровня можно быстрее закодировать более эффективные алгоритмы.
Поскольку источников для заявления нет, я его убираю.Mathaddict12:09, 1 июня 2010 (UTC)[ответить]
могут и не нивелироваться - вы правы, "могут нивелироваться" не является недостатоком, недостатком является то, что это происходит как правило в случае посредственного программиста (таковых большинство) и более-менее оптимизирующего компилятора. Так что я сейчас поправлю формулировку. эффективную векторизацию данных компиляторы, увы, не способны - это утверждение может быть верно для конкретного набора конкретных версий компиляторов, но оно не является непреложной истиной в последней инстанции для всех компиляторов сейчас и в будущем. Эффективно векторизовать данные не может ещё большее количество программистов, так что паритет сохраняется. тоже надо знать, как писать - кто спорит. Однако языки высокого уровня за счёт оптимизации компилятором "прощают" большую небрежность при написании, нежели в случае языка ассемблера. И в этом вся соль пункта, на который вы взъелись. Пример ошибки компилятора - то, что в компиляторах, как и в других программах, (могут) существовать ошибки - это не новость. Но каким боком это относится к обсуждаемому пункту? Поскольку источников для заявления нет - смело. Типа, то, что я какие-то источники (может, не самые лучшие из возможных) представил - это можно смело не брать в рассчёт? -- AVBtalk17:49, 1 июня 2010 (UTC)[ответить]
Насчет будущего - википедия отражает существующее настоящее. Когда оно меняется, меняется и статья. Так что ваше высказывание о фразе из источника -- не к месту. Там к тому же очевидно, что автор говорил о достаточно хороших компиляторах.
Эффективно векторизовать данные не может ещё большее количество программистов, так что паритет сохраняется. -- это высказывание такого же рода, что в игре го компьютер равен человеку, т.к. большинство людей не умеет играть в го.
Моя претензия заключается в том, что из источников вовсе не вытекает то, что написано в пункте статьи (так обычно и бывает, когда источники подыскиваются задним числом), наряду с неэнциклопедическим "нивелируются", и в этом же пункте дублируется последний. Поэтому я приведу пункт в соответствие с источником.Mathaddict03:45, 3 июня 2010 (UTC)[ответить]
ваше высказывание о фразе из источника - вы забываете, что я говорю не только о временах, но и о полноте исследованного множества компиляторов. Ведь кроме "потребительских" компиляторов вроде Borland C существуют и менее известные компиляторы с более качественными оптимизаторами, в том числе ориентированные и на векторизацию. Но даже если их не было бы, вопрос всё равно не в конкретных компиляторах "здесь и сейчас", а в принципиальной возможности. подыскиваются задним числом - но сути обсуждаемого утверждения это не меняет. приведу пункт - отсутствие встроенного оптимизатора даёт шанс оптимизирующим компиляторам (1) обойти программу на асме, написанную средним программистом, и получить более качественный результат при перекомпиляции под другую платформу (тогда как программа на асме останется незменной); своим редактированием вы порезали значимую часть утверждения про перекомпиляцию под другую (совместимую) архитектуру. -- AVBtalk11:30, 6 июня 2010 (UTC)[ответить]
Меняет. То, что для доказательства орисса про "среднего программиста" приводится источник, в котором говорится "начинающий программист", не есть хорошо. Тогда как программа на асме останется незменной неверно: условная трансляция, самомодифицирующийся код. Из заезженного утверждения про оптимизацию под платформу вроде как следует, что Java должна быть быстрее C/C++, тогда как на практике наблюдается обратно. Вы, кажется, не понимаете основной разницы между программами на языках высокого уровня и ассемблере.Mathaddict05:05, 9 июня 2010 (UTC)[ответить]
Зачем все эти "Статьи РФ"?
Прямо не энциклопедию, а УК РФ читаю: там 2 года дадут, тут 7 лет отсидеть... Для чего эти строчки в тексте? Попугать? Может в статью об отвертках тоже написать сколько за колото-ножевые раны дают? Убрать этот бред немедленно! 93.81.238.22218:29, 2 февраля 2010 (UTC)[ответить]
"...директивы (команды, не переводящиеся в процессорные инструкции, а выполняемые самим ассемблером)"
Это как? А "сам ассемблер" чем выполняется? Не процессором?
Имеются в виду, что директивы влияют в первую очередь на процесс трансляции, а на результат трансляции влияют только косвенным образом. --Grig_siren18:34, 1 мая 2011 (UTC)[ответить]
Ошибочный код
К сожалению, программный код выполняет иные действия, чем заявлено. Этот код копирует строку в видеобласть. Никакого отношения к считыванию дискеты не имеет
Откатил эту правку т.к. свои комментарии нужно высказывать на странице обсуждения + комментарий неверен. В коде используется косвеная адресация и в al будет загружен 1 байт из соответствующей ячейки памяти. Xchgall22:09, 20 марта 2013 (UTC)[ответить]
Достоинства и недостатки
Я не совсем уверен, что такая глава вообще должна быть в вики-статье. Достоинства и недостатки - это довольно субъективные понятия. Так же, в этом разделе присутствуют "Достоинства", которые таковыми назвать нельзя.
Например фраза "Язык ассемблера используется для создания «прошивок» BIOS." - это не достоинство, а скорее сфера применения.
В примеры
использование директив языка ассемблера для превращения любого бинарного файла в его db HEX репрезентацию
(позволяет выкладывать точные репрезентации файлов, на ресурсах, на которых выкладывать бинарные формы запрещено)
(репрезентация db HEX - полностью обратимый аналог бинарного файла, собирается любым ассемблером обратно в бинарный файл)
format binary as 'txt'
dd 'db '
offs = $
itsz = $
file 'полный путь до файла, которому должна быть создана db HEX репрезентация';:0,304
size = $-offs
db size dup (0,0,0)
dollar = '$'
comma = ','
linenums = size shr 4
dd linenums dup 0
repeat size
idx = size-%
row = idx shr 4
load c byte from idx+offs
l = c/16
h = c mod 16
if h>9
h = h + 'A' - 10
else
h = h + '0'
end if
if l>9
l = l + 'A' - 10
else
l = l + '0'
end if
w = l+ h shl 8
store byte dollar at (idx + row)*itsz + offs-1
store word w at (idx + row)*itsz + offs
if idx mod 16 < 15
store byte comma at (idx + row)*itsz + offs+2
else
store word $0A0D at (idx + row + 1)*itsz + offs-2
store word 'db' at (idx + row + 1)*itsz + offs
store byte ' ' at (idx + row + 1)*itsz + offs+2
end if
end repeat
store byte '?' at $-1
Использовано лично для загрузки репрезентаций EXE и DLL, например, во вконтакте. Это будет полезный примерчик, который может помочь каждому расшарить в интернете ресурсы которые расшарить в бинарной форме нельзя, повысить доверие к любому сайту со стороны антивирусов...
Дизассемблирование не единственная операция обратная ассемблированию, формирование db HEX репрезентации, такая же обратная ассемблированию операция.
(Как говорится, я предложил, а Вы там поавторитетнее, посчитаете интересным добавить - добавьте)
У:ProMiNick11:17, 26 октября 2020 (UTC)[ответить]
Против. Возражаю, поскольку, во-первых, это является ВП:ОРИССными исследованиями, и, во-вторых, не имеет никакой энциклопедической значимости, в-третьих, Википедия - не место для публикации эссе. Я уже писал Вам вот здесь, что подобные изыскания стоит публиковать в личных блогах. Судя по Вашему опыту и квалификации, а также желанию делиться ими с другими, Вам давно пора завести такой блог и публиковать в нём интересные статью (я серьёзно). Но это не значит, что каждый существующий фрагмент кода или вариант его использования должен размещаться в энциклопедию. Юрий (обс.) 08:50, 26 октября 2020 (UTC)[ответить]
@Yurakum: значит ли это, что и пример «Пример структурирования данных: создание BMP-файла к коде программы с помощью директив» из статьи надо удалять? Если да, то будет ли это кто-то делать? — Vort (обс.) 08:53, 26 октября 2020 (UTC)[ответить]
Этот пример также был написан участником У:ProMiNick, только находился в статье Ассемблер, а мной был только перенесён сюда вместе с другими кодами, когда я чистил ту статью (так как примерам место не там, а тут). А вообще я лично тоже не приветствую нахождение здесь этого примера про BMP, потому что он выходит за рамки основной цели языка ассемблера. Если будет поднят вопрос о его удалении, я проголосую "за" с уже озвученной аргументацией. Юрий (обс.) 09:01, 26 октября 2020 (UTC)[ответить]
Источники ни для одного не указаны, их происхождение я не знаю. Но это не значит, что они не рабочие, и к тому же они здесь, скорее, просто для иллюстрации. Если всё удалять, мы вообще без примеров остаемся, что не очень хорошо. Юрий (обс.) 09:14, 26 октября 2020 (UTC)[ответить]
В том-то и дело. Если тщательно следовать правилам, то раздел с примерами написать будет или очень сложно, или невозможно. Но и тащить в него всё подряд тоже неправильно. Я бы предложил тривиальность в роли критерия. Это и количество примеров ограничивает и их оригинальность. — Vort (обс.) 09:34, 26 октября 2020 (UTC)[ответить]
На счёт критерия согласен. Количество примеров, скорее, ограничивается числом рассматриваемых архитектур и операционных систем (в случае ПК). Юрий (обс.) 09:44, 26 октября 2020 (UTC)[ответить]
Задача сложнее, чем просто найти какой угодно кусок кода в авторитетном источнике. Надо ведь, чтобы этот код своим примером показывал читателю, каким является язык ассемблера. И именно на это нужен авторитетный источник. pl:Gynvael Coldwind, кстати, похож на специалиста, источники которого подойдут для статей. Но в данном случае они просто не в тему. — Vort (обс.) 10:35, 26 октября 2020 (UTC)[ответить]
@Yurakum: ещё интересный вопрос. Если всё же найти высококачественный источник с примером, который будет представлен именно как пример, то можно ли его будет помещать в статью? Не прийдут ли защитники авторского права и не скажут ли, что это КОПИВИО? Для простых случаев аргументом может быть тривиальность примера (то есть, отсутствие творческого вклада, а, значит, и защиты авторским правом), но уверенности в этом у меня нет. — Vort (обс.) 10:52, 26 октября 2020 (UTC)[ответить]
Значит из соображений тривиальности мой пример хорош - он не использует ни одной мнемоники процессора, и являет собой пример, что ассемблер это не узкофункциональный мнемопроцессор, а ассемблер. директивы которого даже сами по себе - могучий инструмент. (А то у вас не ассемблер, а мнемопроцессор какой то выходит) У:ProMiNick15:10, 26 октября 2020 (UTC)[ответить]
А https://en.wikipedia.org/wiki/Assembly_language - авторитетный источник? где базовые элементы языка директивы данных? ассемблерные директивы? мой пример как раз на то что у вас отсутствует вовсе. Где энциклопедическое содержимое эквивалентное английской версии. Почему русская версия ассемблера мнемонический обрубыш ассемблера? У:ProMiNick17:26, 26 октября 2020 (UTC)[ответить]
Нет, Википедия на другом языке не является авторитетным источником. Там сидят такие же участники, как и у нас тут, и они ничем не более авторитетны (это не только в плане ассемблера, а вообще).
Примеры кода приводятся чаще всего для иллюстрации подхода конкретного языка, для приведения примеров специфичных для языка конструкций или особенностей — цели не нарушаем.
Следует избегать написания любого примера, если он не внесёт значимого вклада в фундаментальное понимание энциклопедического содержимого — поэтому, полагаю, пример кода с BMP подлежит удалению, а новый (предлагаемый выше) пример использования директив - неиспользованию, так как энциклопедической значимости они не имеют. Число "примеров программы «Hello, world!» для различных платформ ЭВМ" я бы тоже подсократил, оставив наиболее распространённые среды программирования (но не настаиваю). Коды по микроконтроллерам действительно разношёрстны, можно оставить.
Код, не относящийся к энциклопедическому содержимому, должен быть перемещён за пределы Википедии. Викиучебник - подходящий проект Викимедиа для кода — У:ProMiNick, вот Вам и ответ, куда можно разместить все Ваши примеры. Там есть инструкции, посмотрите, пожалуйста, сами, с Викиучебником я не работал и не могу подсказать лучше того как там написано.
Реализации исходного кода должны быть совместимы с лицензиями GFDL и CC-BY-SA (эти лицензии несовместимы с GPL) — в нашем случае это вообще труднодостижимо. Хорошие АИ — печатные книжки и журналы по Ассемблеру, но они все под ВП:КОПИВИО, а большинство ещё и ВП:САМИЗДАТ. Так как мы не ставим тут целью доказывать работоспособность приведённых примеров, а наша задача — это просто иллюстрирование фрагмента кода на языке (подошёл бы и вообще незаконченный фрагмент кода), наверное, компромиссное решение — оставить эти самописные примеры, которые есть, без указания источников.
Не рекомендуется помещать листинг в шаблоны вида Википедия:Сворачивающиеся блоки — печалька. Но это рекомендация, не требование.
примеры не должны быть представлены галереей в конце статьи, их нужно использовать в разделах статьи — ещё печалька. Но мне кажется, мы не сможем так это раскидать, эти примеры не относятся к какому-то отдельному разделу.
Самое главное — эта страница правилом не является. У страниц-правил есть определённые отметки. Второе по важности — этот раздел касается статей об алгоритмах. Поэтому использовать его надо, скорее, не как руководство к действию, а как источник вдохновения. — Vort (обс.) 16:07, 26 октября 2020 (UTC)[ответить]
С причинами использования фрагментов кода согласен — они должны рассказывать читателю что-то новое. Правда, формализовать это, скорее всего, непросто. — Vort (обс.) 16:11, 26 октября 2020 (UTC)[ответить]
Рекомендация про сворачивающиеся блоки, скорее, относится к фрагментам, которые иллюстрируют какую-то особенность. Допустим, в тексте идёт описание возможности языка и рядом приводится фрагмент. Конечно, его в блок заворачивать не надо. Или статья про алгоритм и посреди статьи именно этот алгоритм напечатан. Тоже скрывать смысла мало. — Vort (обс.) 16:11, 26 октября 2020 (UTC)[ответить]
С лицензиями и ориссом ситуация самая нехорошая. Согласен, что лучше орисс на грани тривиальности, чем нарушение авторского права. Так как спорить со сторонниками идеального соблюдения авторских прав — занятие не из приятных. Глупая причина, но что есть, то есть. — Vort (обс.) 16:15, 26 октября 2020 (UTC)[ответить]
Она относится к тематическим руководствам. Сворачиваемые блоки в нашем случае смотрятся лучше, чем несколько страниц сплошного многобувия, и в конце статьи в таком виде им намного лучше, чем раскиданными по тексту.
Я предлагаю убрать примеры про загрузочный сектор дискеты (явно не тривиально и не относится к "Hello, world!" как таковому) и про файл BMP (это вообще нестандартное использование ассемблера). Пример добавления строки «Hello world!» в код программы лучше убрать в раздел с директивами и сделать несворачиваемым, а в раздел "Типичный формат записи команд" добавить несворачиваемый пример из 2-3 строк просто фрагмента текста программы со всеми атрибутами (метки, мнемокод, параметры, комментарий). А остальной сворачиваемый фрагмент оставить в конце статьи как иллюстрацию. Юрий (обс.) 16:28, 26 октября 2020 (UTC)[ответить]
Хорошо, займусь. Заодно тут напрашивается немного изменить структуру статьи и желательно поменять картинку, потому что на ней листинг, а не исходный код. Юрий (обс.) 16:44, 26 октября 2020 (UTC)[ответить]
Кроме того, существуют компьютеры, реализующие в качестве машинного язык программирования высокого уровня (Форт, Лисп, Эль-76). Фактически, в таких компьютерах они выполняют роль языков ассемблера.
Если посмотреть примеры программ на этих языках по ссылкам, то у меня лично возникают сомнения, что процессоры поддерживают такие команды на уровне своих инструкций. Предлагаю привести источники или удалить. Юрий (обс.) 01:17, 28 октября 2020 (UTC)[ответить]
"далее нескольких прототипов microJava 701 дело не пошло" https://www.osp.ru/cw/2005/09/86657http://www.chipinfo.ru/chipdir/fam/java/index.htm , но ведь до нескольких прототипов дело дошло - значит архитектура имеет место быть, а java это язык высокого уровня (и кстати java байткод без проблем формируется прямо из под ассемблера - fasmg так может, так что есть как процессоры для java байткода так и ассемблеры, конечно java байткод это не совсем java, но есть однозначное соответствие одного другому) У:ProMiNick 08:24, 28 октября 2020
Различие в том, что ассемблер занимается трансляцией. Был код операции в виде текста, получился код операции в виде байта в памяти. Для Java же такое не пройдёт. Для начала надо скомпилировать Java в байткод и затем уже можно этот байткод выполнять (интерпретируя или напрямую). — Vort (обс.) 06:40, 28 октября 2020 (UTC)[ответить]
; This example uses a very simple set of macroinstructions to generate
; the basic structures of JVM class file.
; Please refer to "The Java Virtual Machine Specification" for the detailed
; information on this file format.
include 'jclass.inc'
format binary as 'class'
u4 0xcafebabe ; magic
u2 0,49 ; minor and major version
constant_pool
_Code constant_utf8 'Code'
_init constant_utf8 '<init>'
_main constant_utf8 'main'
_void_arrstr constant_utf8 '([Ljava/lang/String;)V'
Test_class constant_class _Test
_Test constant_utf8 'Test'
Object_init constant_methodref Object_class,init_method
Object_class constant_class _Object
_Object constant_utf8 'java/lang/Object'
init_method constant_nameandtype _init,_void
_void constant_utf8 '()V'
System.out constant_fieldref System_class,out_field
System_class constant_class _System
_System constant_utf8 'java/lang/System'
out_field constant_nameandtype _out,PrintStream_type
_out constant_utf8 'out'
PrintStream_type constant_utf8 'Ljava/io/PrintStream;'
PrintStream_println constant_methodref PrintStream_class,println_method
PrintStream_class constant_class _PrintStream
_PrintStream constant_utf8 'java/io/PrintStream'
println_method constant_nameandtype _println,_void_str
_println constant_utf8 'println'
_void_str constant_utf8 '(Ljava/lang/String;)V'
Integer_toString constant_methodref Integer_class,toString_method
Integer_class constant_class _Integer
_Integer constant_utf8 'java/lang/Integer'
toString_method constant_nameandtype _toString,_str_int
_toString constant_utf8 'toString'
_str_int constant_utf8 '(I)Ljava/lang/String;'
number constant_integer 17
end constant_pool
u2 ACC_PUBLIC+ACC_SUPER ; access flags
u2 Test_class ; this class
u2 Object_class ; super class
interfaces
end interfaces
fields
end fields
methods
method_info ACC_PUBLIC, _init, _void ; public void Test()
attribute _Code
u2 1 ; max_stack
u2 1 ; max_locals
bytecode
aload 0
invokespecial Object_init
return
end bytecode
exceptions
end exceptions
attributes
end attributes
end attribute
end method_info
method_info ACC_PUBLIC+ACC_STATIC, _main, _void_arrstr ; public static void main(String[] args)
attribute _Code
u2 3 ; max_stack
u2 2 ; max_locals
bytecode
ldc number
istore 1
example_loop:
iload 1
dup
imul
invokestatic Integer_toString
getstatic System.out
swap
invokevirtual PrintStream_println
iinc 1,-1
iload 1
ifne example_loop
return
end bytecode
exceptions
end exceptions
attributes
end attributes
end attribute
end method_info
end methods
attributes
end attributes
так что именно там не пойдет под ассемблером? взято из примеров fasmg У:ProMiNick 12:29, 28 октября 2020
Там ниже написано «For accurate language codes, see complete details in the Pygments document and there are some mappings for some language names which were supported by GeSHi». Чтобы уж совсем убедиться, можно глянуть в исходники (про Pygments сказано вот тут). В самом списке, кстати, языки, а не коды. asm вполне соответствует "Assembly (various)", то есть «всяким ассемблерам». — Vort (обс.) 16:54, 18 января 2021 (UTC)[ответить]
Не используется только в блоке, в котором не сам ассемблерный код, а его формат. Там подсветка и не нужна, так как, грубо говоря, этот блок не скомпилируется. — Vort (обс.) 16:56, 18 января 2021 (UTC)[ответить]
Юрий, добрый вечер! Вы уверены, что 1983 год — это «на ранних этапах развития программирования»? На мой взгляд, 1990 год в этом плане ничуть не лучше и не хуже, а вот иметь в качестве источника действующий стандарт, находящийся в открытом доступе, всё же лучше с точки зрения ВП:ВЕР. Определение понятия «автокод» в нём присутствует слово-в-слово как в статье, специально проверил перед правкой. Может, вернём?.. 91.203.191.321:56, 13 января 2025 (UTC)[ответить]
Утверждение в статье звучит так: "на ранних этапах развития программирования было введено понятие автокод". Речь не только об определении "автокода", а и о процессе во времени. Замена ГОСТа на более новый, которую Вы выполнили, с этой точки зрения не имеет никакой пользы. Если считаете, что упомянутый в статье ГОСТ недостаточно старый, замените на более старый ГОСТ или другой источник, в котором вводилось это понятие. Либо на более новый, но в котором упоминается исторический аспект рассматриваемого вопроса. Юрий (обс.) 22:10, 13 января 2025 (UTC)[ответить]
1983 год — это «на ранних этапах развития программирования»? - это очень даже ранний этап развития программирования как инженерно-технической дисциплины. Уж поверьте человеку, который свою первую программу написал в 1982 году в рамках учебного процесса, а с 1991 года зарабатывает этой профессией деньги. Сколько с тех пор изменилось в этой сфере - даже просто сформулировать сложно. Могу только сказать, что то, что я учил по этой теме на 1-м курсе института (1985-86 учебный год), к моменту защиты диплома уже стало морально устаревшим хламом, который уже никому не был нужен. Grig_siren (обс.) 22:31, 13 января 2025 (UTC)[ответить]
Согласен, поменялось очень многое, но значение понятия-то осталось неизменно. Разве в таких случаях не принято ссылаться на актуальные словари, а не преданья старины глубокой? Да и текущий источник, строго говоря, указан некорректно: в нём слились воедино два разных — ГОСТ и справочное пособие. Предлагаю упомянуть ГОСТ отдельно, возможно, со словами «см. также». 91.203.191.322:50, 13 января 2025 (UTC)[ответить]
Разве в таких случаях не принято ссылаться на актуальные словари, а не преданья старины глубокой? - а вот не факт на самом деле. Потому что речь идет не о том, какой источник более свежий и актуальный, а о том, какой источник вообще ввел это понятие. И в этом смысле преданья старины глубокой значительно лучше свежака. Грубая аналогия: для населенных пунктов и других объектов с древней историей очень часто возникает вопрос о том, к какому году относятся первые упоминания объекта в сохранившихся письменных документах. Да и текущий источник, строго говоря, указан некорректно: в нём слились воедино два разных - это неважно. Важно то, что в нем требуемая информация есть. Grig_siren (обс.) 05:12, 14 января 2025 (UTC)[ответить]
Решением, которое должно устроить всех, я всё же вижу разделение некорректно указанного АИ на два корректных (без удаления имеющегося). Так всяко будет лучше, чем то, что имеем сейчас. 91.203.191.309:35, 14 января 2025 (UTC)[ответить]
Добавил ссылку на ГОСТ вдобавок к имеющемуся АИ. Исторический контекст это, конечно, хорошо, но источник, который ещё попробуй найди в электронном виде, малопригоден для проверки изложенной информации. 91.203.191.308:26, 24 января 2025 (UTC)[ответить]
Правилами не запрещено использование печатных источников, см. ВП:ОФЛАЙН, и они не считаются менее надёжными. В том виде, в каком сейчас сделали правки, пойдёт, принимаем, отпатрулировал. Юрий (обс.) 16:20, 24 января 2025 (UTC)[ответить]
