Ок, fasm может работать и в Windows и в Linux. Две популярные ОС, по твоей логике получается, что ассемблер - кроссплатформенный.

Кстати возможность asm вставок в код на C++ еще раз делает ассемблер кроссплатформенным, т.к. C++ тянет его за собой.



 нервный какой

Гы-гы. Позабавило  Только почему то никто не уловил суть - кроссплатформенной программу делает не язык, а используемые ей либы. И никто не мешает использовать их и на асме. Если я уже давно для операций с памятью/файлами/вводом/выводом использую сишные либы, то почему моя прога не будет кроссплатформенной? Достаточно только, при перекомпиляции, подставить соответствующие либы и все, даже не нужно изменять сорсы. Проверено ;) 
Мешают только плохому танцору, да и то сами знаете что  Нормальным асмовцав ничто не мешает ;) Даже писать не буду, выложу лишь пример к кроссплатформенной либе, для компиляторов MASM и FASM. Имеет менеджер памяти, потоки ввода/вывода (stream stdin/stdout), файловые операции, т.е. практически все ОС-зависимые операции. Расчитана на Win32 и Linux. Перекомпиляция под любую платформу не требует изменения сорсов ;) 

И это не прикол  

ну давай перекомпилируй для PowerPC
или для MIPS
или для ARM
  

MAKCim, аппетит приходит во время еды? Сначала речь была о никсах и винде, что я и сделал ;) 
Но если уж говорить об аппаратной кроссплатформенности, то и здесь асм иногда рулил. Или ты никогда не слышал о препроцессорах? Я сталкивался только два раза. Первый раз, когда переводил код с Z80 на x86. Препроцессор справился на пять, оставалось только подправить работу с железом, впрочем и с сишными сорсами были те же самые траблы. Второй раз столкнулся, когда понадобилось научить тасм командам MMX и SSE, благо был уже готовый код из какой то книжки. Не сомневаюсь, что можно написать препроцессор для компиляции x86 под тот же PowerPC. Только зачем это надо? Аппаратные различия платформ настолько велики, что от кроссплатформенных приложений нет никакого толка, они обречены на отставание от специализированных. Пример? Недавно был холивар с плюсовиками. Пока они отставали, по скорости, совсем немного(порядка 10-30%, на задачках в сотню-другую тактов), то напирали на то, что мол это ерунда, зато кроссплатформенно. Предложил реальную задачу, где крайне важна скорость (простое альфа-наложение). Их отставание стало в несколько раз! После чего один профи(в самом лучшем понимании этого слова) выдал блестящий сишный код:
Он отстал от моего всего на 30-50% (зависит от машины). Это я к чему? MAKCim, а тебе не кажется, что теперь и я могу заявить о том, что Плюсы не кроссплатформенны? Что, я не прав? Ну тогда компильни мне этот пример под ARM, MIPS, PowerPC, а еще лучше под Z80(он до сих пор производится и успешно применяется) ;) Только не надо говорить о том, что это редкость, подобных "кроссплатформенных" сорсов пруд пруди, особенно когда дело доходит до кодинга железа.
Так что не надо передергивать, полностью кроссплатформенных языков не может быть в принципе, у каждого свои ограничения. Впрочем можно назвать жабу, но это и не язык, а так, не пойми что (чисто имхо)  

AndNot, 
я не спорю, что и на ЯВУ можно писать программы, которые не будут кроссплатформенны
однако только лишь по семантике, а не по исходному коду (к примеру, различия между big и little-endian в тех случаях, где это важно)
здесь ЯВУ просто заменяет ассемблер и выступает в качестве инструмента, с помощью которого можно сделать те же вещи, только быстрее + его использование дает возможность избавится от большОго числа абсолютно не нужных зависимостей от архитектуры CPU и формата его инструкций
в остальном код на ЯВУ переносим, лишь бы был компилятор на целевой платформе
а вот насчет препроцессоров сильно сомневаюсь
ЯВУ определяет общие операции, отображение которых в инструкции возможно для всех (или для большинства точно) архитектур
ассемблер же расширяет круг используемых инструкций, некоторые из которых просто не могут быть преобразованы препроцессором в аналогичные инструкции другой архитектуры
возьмем, к примеру, те же CLFLUSH, WBINVLD, MWAIT, PAUSE и пр.
по поводу примера, может я туплю, но я не вижу в чем проблема
поясни
потенциальный затык может быть в месте сдвига на 8

еще раз говорю
есть задачи, которые по своей природе не могут быть кроссплатформенными
однако все ЯВУ кроссплатформенны 

Правильно делаешь, иначе они бы давно стали пользоваться спросом  Это просто был пример, из личной жизни.
Проблема одна - код жестко привязан к x86. Если присмотришся, то увидишь такие команды: unpack_low, packu_sat и прочие. Это костыли от Интела, которые переводятся непосредственно в MMX-инструкции, своеобразная замена встроенному асму. Были выпущены лишь из-за того, что они так и не научили свой компилятор самостоятельно их использовать. Используя эту возможность Сишник сознательно отказывается от аппаратной кроссплатформенности, в пользу производительности (а выигрыш не малый).
Верно, только замечу, что это для программ не сложнее Hello World!. Или приходится капитально ограничивать функционал программы. Например, возьмем сокеты. Не секрет, что можно написать программу, которая будет работать как под никсами, так и под виндой. И все бы хорошо, если бы не тот факт, что под виндой это будет работать, мягко говоря, отвратительно. У нее слишком другая архитектура, под которую мягкотелые разработали значительно более мощные методы работы с сокетами. Причем разница по производительности, между никсовским и виндозным методами, будет в десятки раз! Уже один этот факт заставляет писать сервера в двух вариантах  
Или возьми те проблемы, что возникли у Сишников, при переносе своих программ под 64-х битную архитектуру. Проблемы то возникли на ровном месте - неверная типизация данных. И это показало все "кроссплатформенность" во всей ее красе  
В этом и есть ответ, почему HLA не пользуется популярностью - ассемблерщикам не нужна полная кроссплатформенность, у них другие задачи. Если кто-то нанял асмовщика, то понятно, что под определенную архитектуру. Ну может еще условие поставят - под никсы и винды, что вполне реально, тем более либ пруд пруди.
Собственно я только и хотел упомянуть, что асм может быть отчасти кроссплатформенным, пускай и с ограничениями по аппаратной части, но в остальном вполне реально. Но кому это нужно?

из-за этого С не перестал быть кроссплатформенным   

поэтому и надо использовать кроссплатформенные библиотеки, оптимизированные для каждой ОС   

причем здесь кроссплатформенность?
это руки
при правильном подходе проблем с переходом от 32 к 64 нет
пример - кроссплатформенная сишная часть кода ядра Linux
работает без изменения кода на всех поддерживаемых архитектурах

Да как тебе сказать то. Раз язык поддерживает некоторые типы данных, то почему программист не должен их использовать (а иначе зачем тогда они вообще существуют)? А раз их использование создает определенные трудности с переносом на другую платформу, то извини, но это не кроссплатформенный язык. ИМХО это скорее язык с возможностью написания таких приложений. Но это немножко разные вещи. 
А кто мешает использовать их ассемблерщику? Но ты же сам подразумевал, что это еще не кроссплатформенность ;) Вообще не мешало бы поточнее определиться, что понимать под термином "кроссплатформенность". 

а что за данные?

да запросто
есть некоторый код на некотором ЯП
код является кроссплатформенным, если он без изменения может быть скомпилирован (естественно, при наличии компилятора) и запущен на более чем одной платформе
платформа представляет собой совокупность аппаратных (архитектура CPU) и програмных (ОС) компонентов
например PowerPC + Linux, IA-64 + Linux, AMD64 + Windows и т. д

Это сообщение отредактировал(а) MAKCim - 28.2.2008, 22:18

вернулись. см. 4-ый пост 

Ну так я же представил код под две платформы: x86+Windows и x86+Linux ;) Могу представить образец программы, под x86 (16-ть бит) и Z80 (8-бит). А это уже разные аппаратные платформы ;) Так на каком основании ты утверждаешь, что асм не может быть кроссплатформенным, поскольку я выполнил условие: 
Так в чем вопрос то? Я и не утверждал, что можно на всех, но под две-три вполне реально, было бы желание.
Да ничего удивительного ;) Ведь это понятие довольно расплывчатое, каждый понимает его по своему.