Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Asm: Общие вопросы > Кроссплатформеность

Автор: Real 4.1.2008, 20:41

Asm он кроссплатформеный или нет?

Автор: MAKCim 4.1.2008, 20:55

нет

Автор: SABROG 9.1.2008, 21:07

Если я задам вопрос: "C++ кроссплатформенный ?", что вы ответите ?

Не язык определяет кроссплатформенность, а компилятор. fasm - кроссплатформенный. Другое дело, что для того чтобы создать кроссплатформенную программу придется писать свою реализацию кода под каждую платформу и с помощью условий делать автоматический или ручной выбор. В большинстве случаев то же самое делается и в C++, стандартные библиотеки C++ я не рассматриваю.

Автор: dumb 10.1.2008, 01:15

для начала, стоило бы уточнить: что автор вопроса понимает под "кроссhttp://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80%D0%BD%D0%B0%D1%8F_%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B0енностью"?

Автор: rei3er 11.1.2008, 10:49

SABROG,
ЯВУ - это абстракции, которые преобразуются в код на ассемблере для данной архитектуры
код на ассемблере - это просто мнемонические обозначения инструкций, а инструкции не переносимы
мнемонику и инструкции нельзя поставить во взаимно-однозначное соответствие при переносе на другую платформу
FASM тут вообще не в тему
если компилятор есть под разные ОС, то это еще не говорит о том, что при переносе его, скажем, на PowerPC, все программы написанные для x86 скомпилируются
в этом суть некроссплатформенности ассемблера

Автор: SABROG 11.1.2008, 12:36

Но и не кроссплатформенным ты его не назовешь. Предположим есть старый компилятор C++, он ничего не знает о новых архитектурах, не знает как преобразовывать мнемонику, значит опять же не C++ не кроссплатформенный, а компилятор. Понятно, что это распространяется и на компилятора ассемблера. Если даже на новой платформе нет аналогу mov, xor, add, imul, то есть другие инструкции. И чтобы сделать программу на ассемблере кроссплатформенной, придется просто написать 2 разных кода. На C++ не нужно будет. А если даже нет компилятора под новую платформу, то можно тупо писать машинными кодами, если в этом спец, любой компилятор ассемблера это схавает.

И можно ли называть язык кроссплатформенным, если он поддерживат всего два процессора ? Или две операционные системы ? Я думаю, что можно.

Автор: rei3er 11.1.2008, 14:02

Цитата(SABROG @ 11.1.2008, 12:36

)

И чтобы сделать программу на ассемблере кроссплатформенной, придется просто написать 2 разных кода.

вот именно на этом моменте кроссплатформенность теряется
судь кк в том, что код переписовать не надо

Автор: SABROG 11.1.2008, 14:22

Если руководствоваться такой логикой, то Firefox не кроссплатформенный, т.к. имеет две версии исходников, одни для винды, другие для линукса. Php, Python, Perl тоже не кроссплатформенные тогда.

У каждой ОС свой набор API функций, ни один кроссплатформенный компилятор не знает о них ничего. А что говорить о MSVC или Delphi, они настолько не кроссплатформенные, что в них нельзя создать приложения win16 (не забыли еще о таких ?) или под ДОС.

Автор: W4FhLF 11.1.2008, 15:03

Цитата(SABROG @ 11.1.2008, 14:22

)

Ты несёшь бред. C/C++ потому кроссплатформенный, что для исполнения программы под другой ОС нужна только перекомпиляция, если ты ограничиваешься только средствами самого языка. Это идеальный случай, в крайности впадать не надо, т.к. везде есть исключения.

Скрипты тоже не нуждаются в переписывании, они исполняются на тех платформах, на которых есть интерпретатор. Сами же интерпретаторы не являются КК и их никто такими не считает.

Автор: SABROG 11.1.2008, 15:26

Цитата(W4FhLF @ 11.1.2008, 15:03)

Цитата(SABROG @ 11.1.2008, 14:22

)

А теперь подумай, если я ограничусь языком одного ассемблера и напишу программу, которая будет складывать 1+1. То чем она будет отличаться от C++ или Php, чем она не кроссплатформенна ?

Кстати помимо fasm'a есть еще gas (GNU Assembler), который работает под *nix'aми и в составе mingw под виндой (as.exe). У него синтаксис AT&T. Поэтому я категорически не согласен с тем, что ассемблер не кроссплатформенный.

Автор: W4FhLF 11.1.2008, 15:40

Цитата(SABROG @ 11.1.2008, 15:26

)

которая будет складывать 1+1

Хорошо, а теперь представь, что твоя программа должна складывать введённыое пользователем a и 1, а после выводить результат.

В чём может быть задача программы, которая ничего не получает и ничего не выдаёт?

PS Напиши кроссплатформенный "Hello World" на асме.

Автор: SABROG 11.1.2008, 15:59

Цитата(W4FhLF @ 11.1.2008, 15:40)

PS Напиши кроссплатформенный "Hello World" на асме.

Я писать ничего не буду, но скажу, что в какой ОС не пиши в видеопамять результат один - загараются пикселы на экране. И протокол работы с устройствами через порты (на нулевом кольце) от ОС не меняется никак.

Если с этим разобрались, теперь можно попытаться меня припереть к стенке переключением понятия "платформы", начав считать ею процессор, а не ОС. Но даже в этом случае доработав компилятор ассемблер снова становится кроссплатформенным.

Автор: W4FhLF 11.1.2008, 16:11

Цитата(SABROG @ 11.1.2008, 15:59

)

Я писать ничего не буду, но скажу

Я тоже могу много чего сказать, но слова - это всего-лишь слова.

Цитата(SABROG @ 11.1.2008, 15:59

)

что в какой ОС не пиши в видеопамять результат один - загараются пикселы на экране. И протокол работы с устройствами через порты (на нулевом кольце) от ОС не меняется никак.

Есть понятие платформозависимых и платформонезависимых приложений. Если ты работаешь с видеопамятью и устройствами напрямую, т.е. не используешь никаких средств ОС, то это платформонезависимое(native) приложение и к нему термин КК вообще не применим.

Так, что не мешай всё в кучу, а просто признай, что ошибся. В этом нет ничего смертельного.

Цитата(SABROG @ 11.1.2008, 15:59

)

Если с этим разобрались, теперь можно попытаться меня припереть к стенке переключением понятия "платформы", начав считать ею процессор, а не ОС. Но даже в этом случае доработав компилятор ассемблер снова становится кроссплатформенным.

Ога, а ещё мы процессор перепаяем, лишь ассемблер у нас кк стал smile

Автор: SABROG 11.1.2008, 16:34

Возьми драйвер клавиатуры в линуксе (в свободном доступе лежит) и драйвер клавиатуры Windows (тоже в свободном доступе DDK) и сравни протокол взаимодействия с контроллером. И тогда мои слова сразу перестанут быть просто словами.

Т.е. все-таки ты тянешь в сторону ОС, называя ее Платформой, а не архитектуру.

Тогда еще раз спрошу, чем пример с "1+1" тебе не нравится ? Он переносим ? Переносим ! А значит кроссплатформенный.

Насчет printf в С++. Ну не имеет компилятор ассемблера таких функций, он что не кроссплатформенным после этого становится ? А может программы которые он создает не должны ничего никому выводить на экран ? Это что обязательное условие кроссплатформенности, кто это утвердил ?

Я тоже могу такое условие поставить. Например используя стандартные средства C++ напиши кроссплатформенную программу, которая будет иметь инструкцию вставки любого файла в секцию данных. На фасме

Код


string db 'Hello, World',0
virus file 'smapta.exe'
handler dd ?

Не сможешь потому, что это особенность компилятора. Если по критерию типа printf ты решаешь кроссплатформенный язык программирования или нет, то в таком случае C++ не кроссплатформенный, т.к. не имеет команд, которые имеют fasm, gas, nasm...

Автор: W4FhLF 11.1.2008, 16:49

Ну ты танк smile

))

Цитата(SABROG @ 11.1.2008, 16:34

)

Так чё ж ты в дебри лезешь. Вся эта казуистика ни к чему, она бессмысленна.
Я прошу самый простейший пример. Напиши исходник на ассемблере, который выводит в консоль строку "Hello World", чтобы я взял этот исходник, спокойно скомпилил его и там, и там, запустил и поверил. Не можешь написать? Почему? Мешают конструктивные особенности ОС? Вот и всё.

Цитата(SABROG @ 11.1.2008, 16:34

)

Ты не видишь разницы между компилятором и языком? Ассемблер - набор мнемоник, всё остальное - не ассемблер. Си описан официальным стандартом и printf является частью этого стандарта.

Добавлено через 2 минуты и 33 секунды

Цитата(SABROG @ 11.1.2008, 16:34

)

Т.е. все-таки ты тянешь в сторону ОС, называя ее Платформой, а не архитектуру.

ok, давай возьмём архитектуру. Напиши мне "Hello World" на ассемблере, а я проверю его на x86 и на Mac smile

Автор: rei3er 11.1.2008, 17:29

Цитата(SABROG @ 11.1.2008, 16:34

)

Например используя стандартные средства C++ напиши кроссплатформенную программу, которая будет иметь инструкцию вставки любого файла в секцию данных

раз плюнуть
открываем спецификацию на нужный формат исполняемых файлов
дальше через fread/fwrite/fopen вставляем что надо куда надо с учетом формата smile

Цитата(SABROG @ 11.1.2008, 15:26

)

напиши
и чтобы она потом работала на x86, x86-64, MIPS, PowerPC, ...
перекомпилировать можно, переписывать нельзя
компилятором можешь любым пользоваться
на С так

Код


int main() {
    return 1 + 1;
}

абсолютная кроссплатформенность, пойдет на всех вышеназванных платформах
приведешь пример на ассемблере, тогда и будет ассемблер кроссплатформенным smile

Автор: SABROG 11.1.2008, 17:35

Не вижу никакой разницы между тем, чтобы реализовывать printf для известных платформ в одном исходники и выбирать нужную на этапе компиляции и между тем, чтобы компилятор сам подставлял нужную реализацию printf. Результат один - работающая программа.

Ассемблерщик сам себе кроссплатформист, он может сам выбрать будет ли язык кроссплатформенным или не будет, это в его власти в отличае от программистов на ЯВУ.

Цитата

раз плюнуть
открываем спецификацию на нужный формат исполняемых файлов
дальше через fread/fwrite/fopen вставляем что надо куда надо с учетом формата

Не правильно, ты не сможешь на этапе компиляции вставить любой набор байтов в середину программы или в секцию данных. Например:

Код


код
jmp next
myfile file 'musor.bin'
next:
продолжение кода

Если смотреть в отладчике или дизассемблере то после джампа будут идти байты из файла musor.bin, но дебаггер или отладчик его попытаются преобразовать в код.

Цитата

переписывать нельзя

А и не надо переписывать, внутри одного .asm файла будут все возможные реализации одной инструкции для каждой платформы, а препроцессор сам будет выбирать нужную реализацию исходя из операционной системы на которой производится компиляция. Т.е. совершенно прозрачно для юзера.

Автор: W4FhLF 11.1.2008, 17:46

SABROG, я тебя понимаю, но сейчас вопрос стоит не так: "А что было бы, если бы...", вопрос стоит: "Является ли?", т.е. на данный момент.

Да и дело тут даже не в возможности, а просто в понимании того, что ассемблер, как набор мнемоник исполняемых отдельным процессором, нельзя назвать кроссплатформенным по определению, т.к. он не имеет никакой абстракции и не может её иметь.

Автор: rei3er 11.1.2008, 17:54

Цитата(SABROG @ 11.1.2008, 17:35

)

а если на некоторых платформах нет аналогов элементов других платформ?
SGDT, LGDT, STR, LTR, INVLPG, WBINVD к примеру
как будем ВОЗ реализовывать?
smile

Автор: SABROG 11.1.2008, 17:54

Вот два кода, один Hello, World для линукса, другой для DOS'a. Не вижу никаких препятствий объединить эти два разных кода в один, создать макрос и препроцессорными средствами выбирать один из них:

//Linux

Код


section .data
    hello:     db 'Hello world!',10    ; 'Hello world!' plus a linefeed character
    helloLen:  equ $-hello             ; Length of the 'Hello world!' string
                                       ; (I'll explain soon)

section .text
    global _start

_start:
    mov eax,4            ; The system call for write (sys_write)
    mov ebx,1            ; File descriptor 1 - standard output
    mov ecx,hello        ; Put the offset of hello in ecx
    mov edx,helloLen     ; helloLen is a constant, so we don't need to say
                         ;  mov edx,[helloLen] to get it's actual value
    int 80h              ; Call the kernel

    mov eax,1            ; The system call for exit (sys_exit)
    mov ebx,0            ; Exit with return code of 0 (no error)
    int 80h

//DOS

Код


 org 100h

    mov    dx, message
    mov    ah, 9
    int    21h

    int    20h

 message db "Hello, world!$"

Цитата

а если на некоторых платформах нет аналогов элементов других платформ?
SGDT, LGDT, STR, LTR, INVLPG, WBINVD к примеру
как будем ВОЗ реализовывать?

А если на некоторых платформах нет математического сопроцессора ты как поступаешь ? А если на одном процессоре есть 3d Now!, а на другом нету как программы пишут ?

Автор: rei3er 11.1.2008, 17:57

Цитата(SABROG @ 11.1.2008, 17:54

)

Вот два кода, один Hello, World для линукса, другой для DOS'a.

под Linux не работает (MIPS)
smile

Автор: SABROG 11.1.2008, 18:09

Цитата(rei3er @ 11.1.2008, 17:57)

Цитата(SABROG @ 11.1.2008, 17:54

)

Вот два кода, один Hello, World для линукса, другой для DOS'a.

под Linux не работает (MIPS)
smile

Не вопрос, вот спека http://dkrizanc.web.wesleyan.edu/courses/231/07/mips-spim.pdf

Преобразовывай инструкции в машинный код и вставляй, любой компилятор схавает. Все в твоих руках.

Тут попонятнее http://www.mrc.uidaho.edu/mrc/people/jff/digital/MIPSir.html

О, коллекция Hello Worldов для разных архитектур http://www.roesler-ac.de/wolfram/hello.htm

Автор: rei3er 11.1.2008, 18:14

Цитата(SABROG @ 11.1.2008, 18:09

)

Преобразовывай инструкции в машинный код и вставляй, любой компилятор схавает. Все в твоих руках.

а где кроссплатформенность?

Автор: W4FhLF 11.1.2008, 18:18

Цитата(rei3er @ 11.1.2008, 18:14

)

а где кроссплатформенность?

на кончиках пальцев smile

Автор: rei3er 11.1.2008, 18:22

Цитата(SABROG @ 11.1.2008, 17:54

)

а на другом нету как программы пишут ?

мы поэтому и не напишем ничего
еще один показатель отсутствия кроссплатформенности
вообщем спор бесполезен

ps. признать свою неправоту не позорно smile

Автор: SABROG 11.1.2008, 18:26

Нет, пожалуйста, если есть компилятор, который MIPS'ы еще поддерживает то не вопрос. Я не думаю что все известные компиляторы C++ поддерживают MIPSы. Это что делает язык не кроссплатформенным ? Я вообще считаю достоточно 2 платформы, чтобы назвать язык кроссплатформенным.

Цитата

мы поэтому и не напишем ничего
еще один показатель отсутствия кроссплатформенности
вообщем спор бесполезен

Ну это ты не напишешь. А нормальные программисты всегда затыкали дырки эмуляторами или кодом, который делает тоже самое, пусть и медленно. Программа ведь не перестает работать с оптимизацией под SSE или без нее, потому что есть код, который заменяет эти возможности.

Автор: W4FhLF 11.1.2008, 18:33

Цитата(SABROG @ 11.1.2008, 18:26

)

Я не думаю что все известные компиляторы C++ поддерживают MIPSы

Т.е.? Компилятору достаточно поддерживать одну платформу, ибо, если он написан в соответствии со стандартом, то ему плевать под какую платформу написан hello.cpp, он её транслирует в соответствующий набор команд.

Автор: SABROG 11.1.2008, 18:44

Цитата(W4FhLF @ 11.1.2008, 18:33)

Цитата(SABROG @ 11.1.2008, 18:26

)

Я не думаю что все известные компиляторы C++ поддерживают MIPSы

Ему не плевать под какую платформу компилить, если он не знает ничего о новом процессоре, то и программа не будет на нем работать. Т.е. пока сам разработчик не отредактирует компилятор включив в него возможность компилить программы для других платформ программы на них работать не будут. И что тогда получится, если я сейчас спаяю процессор на коленке, то смогу сказать, что язык C++ не кроссплатформенный, т.к. компилятор GCC или MSVC, или BC не знают ничего о моем процессоре. Вот вы такой логикой руководствуетесь. Fasm, nasm, gas уже знают больше 1 платформы, а значит кросплатформенные. Причем не только по коду, но и по архитектуре.

Автор: W4FhLF 11.1.2008, 18:50

Цитата(SABROG @ 11.1.2008, 18:44

)

Ему не плевать под какую платформу компилить, если он не знает ничего о новом процессоре, то и программа не будет на нем работать.

Как он может ничего не знать о процессоре под который писался?

Цитата(SABROG @ 11.1.2008, 18:44

)

Fasm, nasm, gas уже знают больше 1 платформы, а значит кросплатформенные.

Вдолби себе одно: "Язык != Компилятор" и всё станет ясно.

А так, это бессмыслица уже даже не смешит. Пиши свои "1+1" и радуйся жизни, а я удаляюсь из этой бредовой дискуссии.

Автор: nerezus 11.1.2008, 18:51

Цитата

Я вообще считаю достоточно 2 платформы, чтобы назвать язык кроссплатформенным.

Это твое мнение. Мое такое: кроссплатформенность - это возможность работы под большинством популярных и распространенных платформ.

Автор: SABROG 11.1.2008, 18:59

Цитата(nerezus @ 11.1.2008, 18:51)

Цитата

Я вообще считаю достоточно 2 платформы, чтобы назвать язык кроссплатформенным.

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

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

Цитата

Вдолби себе одно: "Язык != Компилятор" и всё станет ясно.

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

Автор: AndNot 28.2.2008, 02:43

Гы-гы. Позабавило smile

Только почему то никто не уловил суть - кроссплатформенной программу делает не язык, а используемые ей либы. И никто не мешает использовать их и на асме. Если я уже давно для операций с памятью/файлами/вводом/выводом использую сишные либы, то почему моя прога не будет кроссплатформенной? Достаточно только, при перекомпиляции, подставить соответствующие либы и все, даже не нужно изменять сорсы. Проверено ;)

Цитата(W4FhLF @ 11.1.2008, 16:49

)

Я прошу самый простейший пример. Напиши исходник на ассемблере, который выводит в консоль строку "Hello World", чтобы я взял этот исходник, спокойно скомпилил его и там, и там, запустил и поверил. Не можешь написать? Почему? Мешают конструктивные особенности ОС?

Мешают только плохому танцору, да и то сами знаете что smile

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

Код

; example of FASMLIB usage in MASM

; compile with:
;       ml /c /coff dec2hex.asm
; link with:
;       link /subsystem:console dec2hex.obj fasmlib.obj kernel32.lib

; "fasmlib.obj" is copy of "bin/mscoff_win32.obj" in FASMLIB directory


; #########################################################################

      .586
      .model flat, stdcall
      option casemap:none    ; case sensitive

; #########################################################################

      include fasmlib.inc

; #########################################################################

    .code

start:
        ;initialize modules
        call    mem_init
        jc      error
        call    stream_init
        jc      error

        ;write prompt
        push    offset _example
        push    offset stream_stdout
        call    text_write
        jc      error

        ;EBX = read decimal number
        push    offset stream_stdin
        call    text_read_dec2d
        jc      error
        mov     ebx, eax

        ;write notice
        push    offset _hex
        push    offset stream_stdout
        call    text_write
        jc      error

        ;write EBX as hex number
        push    ebx
        push    offset stream_stdout
        call    text_write_d2hex
        jc      error

        ;uninitialize modules
        call    stream_uninit
        jc      error
        call    mem_uninit
        jc      error

        ;end program with exit code 0
        push    0
        call    process_exit



        ;on error, EAX contains error code
error:
        ;EBX = error message associated with error code in EAX
        push    eax
        call    err_text
        mov     ebx, eax

        ;write "error"
        push    offset _error
        push    offset stream_stderr
        call    text_write

        ;write EBX error message
        push    ebx
        push    offset stream_stderr
        call    text_write

        ;unintialize modules
        call    stream_uninit
        call    mem_uninit

        ;end program with exit code 1
        push    1
        call    process_exit


; #########################################################################
.data
        ;your data here
        _example        db "Example of FASMLIB usage in MASM ", 10
                        db "Please type decimal dword value: ",0

        _hex            db "It's 0x",0

        _error          db 10, "Error: ",0

end start

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

Автор: MAKCim 28.2.2008, 09:28

Цитата(AndNot @ 28.2.2008, 02:43

)

Перекомпиляция под любую платформу не требует изменения сорсов ;)

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

Автор: AndNot 28.2.2008, 12:45

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

Код

template <int count>
void AlphaFunc(RGBQUAD*& p1, const RGBQUAD*& p2, const Iu16vec4& alpha);

template <>
__forceinline void AlphaFunc<2>(RGBQUAD*& p1, const RGBQUAD*& p2, const Iu16vec4& alpha)
{
    Iu8vec8 m1(*reinterpret_cast<__m64*>(p1));
    Iu8vec8 m2(*reinterpret_cast<const __m64*>(p2));
    
    MLong<Iu16vec4> lm1 = MLong<Iu16vec4>::Unpack(m1, Iu8vec8(0));
    MLong<Iu16vec4> lm2 = MLong<Iu16vec4>::Unpack(m2, Iu8vec8(0));
    MLong<Iu16vec4> lma(alpha, alpha);
    MLong<Iu16vec4> lm1x256 = MLong<Iu16vec4>::Unpack(Iu8vec8(0), m1);

    (((lm2 - lm1) * lma + lm1x256) >> 8).PackUSat(m1);

    *reinterpret_cast<__m64*>(p1) = m1;
    p1 += 2; p2 += 2;
}

template <>
__forceinline void AlphaFunc<1>(RGBQUAD*& p1, const RGBQUAD*& p2, const Iu16vec4& alpha)
{
    Iu8vec8 m1(*reinterpret_cast<int*>(p1));
    Iu8vec8 m2(*reinterpret_cast<const int*>(p2));

    Iu16vec4 lm1 = unpack_low(m1, Iu8vec8(0));
    Iu16vec4 lm2 = unpack_low(m2, Iu8vec8(0));
    Iu16vec4 m1x256 = unpack_low(Iu8vec8(0), m1);

    Iu32vec2 res = packu_sat(Is16vec4(((lm2 - lm1) * alpha + m1x256) >> 8), Is16vec4(0));

    *reinterpret_cast<int*>(p1) = res[0];
    ++p1; ++p2;

}

void Alpha(Bitmap& srcBitmap, Bitmap& imgBitmap, int x0, int y0, int alpha)
{
    int width1 = srcBitmap.Width();
    int width2 = imgBitmap.Width();
    int height1 = srcBitmap.Height();
    int height2 = imgBitmap.Height();
    int xOver = width2 + x0 - width1;
    if (xOver > 0)
        x0 -= xOver;
    int yOver = height2 + y0 - height1;
    if (yOver > 0)
        y0 -= yOver;
    if (alpha < 0)
        alpha = 0;
    if (alpha > 256)
        alpha = 256;

    RGBQUAD* pix1 = srcBitmap.GetPixelPtr(x0, y0);
    const RGBQUAD* pix2 = imgBitmap.GetPixelPtr(0, 0);
    Iu16vec4 mAlpha(alpha, alpha, alpha, alpha);
    bool firstOdd = x0 % 2 == 1;
    bool lastHalf = (width2 - x0 % 2) % 2 == 1;
    int cntPairs = (width2 - x0 % 2) / 2;
    for (int i = 0; i < height2; ++i)
    {
        if (firstOdd)
            AlphaFunc<1>(pix1, pix2, mAlpha);
        for (int j = 0; j < cntPairs; ++j)
        {
            AlphaFunc<2>(pix1, pix2, mAlpha);
        }
        if (lastHalf)
            AlphaFunc<1>(pix1, pix2, mAlpha);
        pix1 += width1 - width2;
    }
}

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

Автор: MAKCim 28.2.2008, 15:04

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

Цитата(AndNot @ 28.2.2008, 12:45

)

полностью кроссплатформенных языков не может быть в принципе, у каждого свои ограничения

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

Автор: AndNot 28.2.2008, 17:15

Цитата(MAKCim @ 28.2.2008, 15:04

)

а вот насчет препроцессоров сильно сомневаюсь

Правильно делаешь, иначе они бы давно стали пользоваться спросом smile

Это просто был пример, из личной жизни.

Цитата(MAKCim @ 28.2.2008, 15:04

)

по поводу примера, может я туплю, но я не вижу в чем проблема
поясни

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

Цитата(MAKCim @ 28.2.2008, 15:04

)

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

Верно, только замечу, что это для программ не сложнее Hello World!. Или приходится капитально ограничивать функционал программы. Например, возьмем сокеты. Не секрет, что можно написать программу, которая будет работать как под никсами, так и под виндой. И все бы хорошо, если бы не тот факт, что под виндой это будет работать, мягко говоря, отвратительно. У нее слишком другая архитектура, под которую мягкотелые разработали значительно более мощные методы работы с сокетами. Причем разница по производительности, между никсовским и виндозным методами, будет в десятки раз! Уже один этот факт заставляет писать сервера в двух вариантах smile

Или возьми те проблемы, что возникли у Сишников, при переносе своих программ под 64-х битную архитектуру. Проблемы то возникли на ровном месте - неверная типизация данных. И это показало все "кроссплатформенность" во всей ее красе smile

В этом и есть ответ, почему HLA не пользуется популярностью - ассемблерщикам не нужна полная кроссплатформенность, у них другие задачи. Если кто-то нанял асмовщика, то понятно, что под определенную архитектуру. Ну может еще условие поставят - под никсы и винды, что вполне реально, тем более либ пруд пруди.
Собственно я только и хотел упомянуть, что асм может быть отчасти кроссплатформенным, пускай и с ограничениями по аппаратной части, но в остальном вполне реально. Но кому это нужно?

Автор: MAKCim 28.2.2008, 18:09

Цитата(AndNot @ 28.2.2008, 17:15

)

Используя эту возможность Сишник сознательно отказывается от аппаратной кроссплатформенности, в пользу производительности (а выигрыш не малый).

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

Цитата(AndNot @ 28.2.2008, 17:15

)

И все бы хорошо, если бы не тот факт, что под виндой это будет работать, мягко говоря, отвратительно. У нее слишком другая архитектура, под которую мягкотелые разработали значительно более мощные методы работы с сокетами

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

Цитата(AndNot @ 28.2.2008, 17:15

)

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

Автор: AndNot 28.2.2008, 20:52

Цитата(MAKCim @ 28.2.2008, 18:09

)

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

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

Цитата(MAKCim @ 28.2.2008, 18:09

)

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

А кто мешает использовать их ассемблерщику? Но ты же сам подразумевал, что это еще не кроссплатформенность ;) Вообще не мешало бы поточнее определиться, что понимать под термином "кроссплатформенность".

Автор: MAKCim 28.2.2008, 22:17

Цитата(AndNot @ 28.2.2008, 20:52

)

Раз язык поддерживает некоторые типы данных, то почему программист не должен их использовать

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

Цитата(AndNot @ 28.2.2008, 20:52

)

Вообще не мешало бы поточнее определиться, что понимать под термином "кроссплатформенность".

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

Автор: dumb 29.2.2008, 09:25

Цитата(AndNot @ 28.2.2008, 20:52

)

Вообще не мешало бы поточнее определиться, что понимать под термином "кроссплатформенность".

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

Автор: AndNot 1.3.2008, 20:36

Цитата(MAKCim @ 28.2.2008, 22:17

)

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

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

Цитата(MAKCim @ 28.2.2008, 22:17

)

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

Так в чем вопрос то? Я и не утверждал, что можно на всех, но под две-три вполне реально, было бы желание.

Цитата(dumb @ 29.2.2008, 09:25

)

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

Да ничего удивительного ;) Ведь это понятие довольно расплывчатое, каждый понимает его по своему.

Автор: overmet 27.10.2009, 10:48

Модератор: Сообщение скрыто.