OSDev

Я имел ввиду те самые "логические типы величин". Да, в регистрах они меняются чаще, чем в ЯВУ из-за малого количества самих регистров. Но это делает проверку типов на порядок актуальней.

По-моему, асм всё же для того и существует, что программировать на низком уровне. По этому никаких типов там не должно быть. А если тебе нужны типы -- бери Си или др. ЯВУ. А на счёт того, что в команде должен указываться размер операндов как в AT&T -- я согласен.

Насчёт команд у меня вообще желание реализовать два подхода: один -- стандартные мнемоники от Интела (т.е. на уровне самих инструкций ассемблер будет совместим с MASM и иже с ним, что облегчит при необходимости перенос программ), второй -- свой формат, отчасти напоминающий AT&T (с явно заданной длиной операндов и % перед именами регистров -- всё это было ещё на PDP-11 и VAX-11, так что мне не привыкать).

vkos, можно сделать вывод, что ты не знаком с типами данных процессора.
Вообще писать программу из несвязных инструкций дело неблагодарное. К тому же у многих инструкций неявные операнды. Например надо быть ясновидящим, чтобы сразу правильно понять, что происходит с регистрами в инструкциях "cmpxchg [ebx],ecx", "mul ebx", "rdtsc", "cpuid" которые неявно используют и модифицируют множество дополнительных регистров. Ущербный синтаксис инструкций не отвечает современным стандартам выразительности.

+1 Однако, так наверное документации более можно заполучить...
Нынче камень преткновения serial-ata - либо он есть либо нету!
Если его нет тады совсем пата!

Chizh



"Современные стандарты выразительности" -- чушь, поскольку и раньше стандарты были ничуть не меньше (или, по-Вашему, в 1967-м выразительность неважна, а спустя 40 лет вдруг потребовалась?).

Что касается ущербного синтаксиса -- согласен, но он проистекает из ущербной системы команд, а её изменить мы не в силах. Единственное, что реально можно сделать (если не притягивать "за уши") -- это комментировать подобные места для облегчения восприятия (вообще, комментарии -- вещь очень полезная, даже если пишешь исключительно для себя).

Что же касается "ясновидения", то нужно не ясновидящим быть, а опытом достаточным обладать ;) Я вот сходу не скажу, что и как меняется в CMPXCHG, RDTSC и CPUID -- инструкции весьма редкие. А вот с MUL у меня проблем не возникает ;)

Простенький примерчик:
http://xskernel.svn.sourceforge.net/viewvc...174&view=markup

Chizh
SadKo

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

А за ссылку спасибо, на следующей неделе гляну (у меня трафик дорогой, несрочные вещи с работы делаю).

Когда создателя фасма спросили, что он думает про контролируемые сновидения, он сказал, что недавно совсем узнал об этом из интернета, что это именно так называется...
ато говорит долгое время прикалывался с них, пока они ему совсем не надоели...
Мне кажется если сильно погрузится в асм и осестроение, то сновидения и ясновидения долго не дадут себя ждать! :D

Тогда комментарии будут перегружены технической информацией, и энтропия не уменьшится :)
Именно из-за повышенной сложности программирования, я бы "думающим" транслятором не стал пренебрегать. Хотя конечно, ВЭДРО из него не получится :)