Наиболее близким к стандарту является то, что поставщик, создавший набор процессор / инструкция, будет иметь документ, описывающий этот язык, и часто этот поставщик будет предоставлять своего рода ассемблер (программу). Некоторые поставщики более детализированы и ориентированы на стандарты, чем другие, поэтому вы получаете то, что получаете. Тогда такие вещи, как эта информация, могут испортить ситуацию. Добавьте к этому, что ассемблер gnu любит портить язык ассемблера для поддерживаемых им чипов, так что в целом у вас хаос.
Если бы существовал язык ассемблера, использование которого было сравнимо с C или C ++, то вы могли бы ожидать, что организация попытается разработать стандарт. Частично проблема по-прежнему заключается в том, что с такими вещами, как язык C, существует интерпретация до того, как он достигнет аппаратного обеспечения, а с ассемблером практически ничего не остается, поэтому производитель микросхем собирается делать все, что хочет, из-за рыночных факторов и стандарт должен был быть перетащен, чтобы соответствовать аппаратному обеспечению, а не наоборот, где стандарт ведет поставщиков.
Процессор opencore может быть тем, который может быть основан на стандартах, поскольку он не зависит от поставщика, возможно, он уже есть.
При сборке предположим, что каждая версия каждой программы / программного обеспечения / инструмента на ассемблере имеет свои собственные правила синтаксиса в одном наборе команд, а также в разных наборах команд. (что на самом деле вы получаете с C / C ++, но это уже другая тема): либо выберите свой любимый инструмент и узнайте только его, либо постарайтесь запомнить все варианты во всех инструментах, либо я предпочитаю избегать как можно большего количества инструментов конкретный синтаксис и нюансы, и попробуйте найти золотую середину, которая работает или, по крайней мере, имеет шанс работать или портировать через инструменты.