Перспективен ли asm?

Quantum

И все это хозяйство компилернозависимое.

=) ООП в Си тоже можно реализовать вручную, а какой прок.
А хотелось бы типа этого - bit - базовый тип, способный иметь два состояния. Далее плясать от всего этого, превратив все остальные типы в структуры. А кто хочет(из разработчиков компилера) поддерживать какой-нить тип данных на уровне компилера - пжлста, и заметьте, все будет более прозрачнее для рядового программера. Сами собой исчезнут половые проблемы (LSB/MSB). так как они имеют разную структуру. Вообщем при таком раскладе создателям компиляторов гимору будет предостаточно, а пользователям языка уже полегче.
Вот например. Полезу я щас в исходники ядра Линакса, поправлю там один дефайнчик связанный с битовыми полями или зависящий от размера машинного слова и можно уже предполагать, что ядро будет работать как минимум нестабильно.
То есть на данный момент утверждение что " Си - портабельный ассемблер", это полный гон (c) CyberManiac

 

Ну так Си же - язык системных программистов, а Java - уже более высокуровневый язык, более человечный.

 

вобщем несколько кусков из прог на Ц++ которые были собраны как мега оптимизация.

1. Такое видно очень часто:

Код (Text):

1. MOV DWORD PTR SS:[EBP-30],EAX
2. MOV EAX,DWORD PTR SS:[EBP-30]
3. MOV DWORD PTR SS:[EBP-2C],EAX

2. Попадается не меньше первого

Код (Text):

1. mov     eax, [ebp+var_20]
2. add     eax, 1
3. mov     [ebp+var_20], eax

3. Это вообще на оскар :

Код (Text):

1. movzx  ecx, WORD PTR _port
2. sar  ecx, 8
3. movzx  edx, WORD PTR _port
4. and  edx, 255        ; 000000ffH
5. shl  edx, 8
6. or  ecx, edx

4. Тоже ничего так:

Код (Text):

1. unknown_libname_2 proc near
2.  
3. var_4           = dword ptr -4
4.  
5.                 push    ebp
6.                 mov     ebp, esp
7.                 push    ecx
8.                 mov     [ebp+var_4], ecx
9.                 mov     eax, [ebp+var_4]
10.                 mov     eax, [eax]
11.                 mov     esp, ebp
12.                 pop     ebp
13.                 retn
14. unknown_libname_2 endp
15.  
16. и вызывается
17.                 lea     ecx, [ebp+arg_4]
18.                 call    unknown_libname_2 ; Microsoft VisualC 2-8/net runtime

5.Хз в какую сторону тут оптимизация

Код (Text):

1.                 mov     word [ebp+pvarg], 0
2.                 xor     edx, edx
3.                 mov     dword [ebp+pvarg+2], edx
4.                 mov     dword  [ebp+pvarg+6], edx
5.                 mov     dword [ebp+pvarg+0Ah], edx
6.                 mov     word [ebp+pvarg+0Eh], dx

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

 

Интересно, здесь есть сторонники писания на чистом асме? =)

 

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

 

2 FreeManCPM
Я имел ввиду разработку используя асм с макросредствами. Ещё вопрос: как с вакансиями? Есть ли? Я что-то особо не находил =)

 

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

 

censored

Нечто похожее я и использую вместо ROR/ROL, но большинство компиляторов не оптимизируют этот код. К примеру, GCC отказывается понимать, что перед ним банальный ROR/ROL. Раз уж во всех архитектурах существуют такие инструкции, почему же их не реализовали в стандарте C - мне не понятно.

char всегда занимает 1 байт, а сколько в этом байте бит стандартом не оговаривается.

MrHammer

Может, платформозависимое?

Портабельность C зависит от разработчика. Если бы портабельность обеспечивал сам язык, о системном программировании можно было бы забыть.

PaCHER
GCC?

 

Это банально был бы уже не системный язык ) Стоит только взглянуть на тот же PHP.

 

Сегодня посмотрел сырцы ядра linux (хоть линь и юзаю, но в сырцы ядра раньше не лез =) ), так вот: там почти всё на си, асма по минимому. Вывод: сейчас асм нужен только чтоб железо шить?

 

Quantum

Наверно, запас портабельности на будущие архитектуры.
Кстати, VC поддерживает циклические сдвиги.

 

Я пишу среду разработки (под Win32 API) для объектно-ориентированного ассемблера - пишу полностью на FASM.

 

В сорсах ядра тоже самое, "железный" код на асме, остальное на Си. Но это не повод говорить, что на асме только платформозависимый код пишут

 

kernel_mode
Встроенный в GCC ассемблер более-менее портабелен, но не до такой степени, чтобы его можно было свободно использовать в ядре, которое должно собираться под любую архитектуру. Зато в различных математических, криптографических, графических и т.д. библиотеках, где важна производительность, ассемблер встречается часто.

green

Но SHL/SHR/SAL/SAR то поддерживаются.

Да, есть такие стандартные функции, но это не портабельно.

 

А можно ссылочку?

 

Тут недалеко http://www.wasm.ru/srclist.php?list=11.
Кто ищет тот всегда найдет.

 

Сейчас нашёл это:
http://programarte.org/

А раньше видел почти то же самое, только на MenuetOS.

Dex4u пишет веб-сервер на фасме под DexOS, но сервер сейчас в оффлайне.

 

кстати, интересно, а почему не сделают конвертор асм кода одного проца в другой??

 

UbIvItS
> кстати, интересно, а почему не сделают конвертор асм кода одного проца в другой??
наверное, потому, что процессоры слишком разные... даже если попытаться сконвертировать x86-32 в x86-16, то будет полный облом, особенно с учетом того, что даже такую простую конструкцию как mov ecx,[eax] на x86-16 нельзя сконвертировать в принципе, т.к. регистр ax нельзя использовать для адресации памяти, а регистры bx,sp,bp,si,di могут быть уже заняты. так что конвертор по сложности приближается к эмулятору. написать эффективный компилятор асма нереально.
эффективная компиляция яву возможна только благодаря их "локальности", но функция типа f(int *x, int *n) {int a; for(a=0;a<*n;a++) *x=a;} уже заставляет компилятор клеить ласты, и он уже не имеет права помещать *n в регистр, поскольку, не уверен, что *x=a не может воздействовать на *n.
ассемблер же это... игра без правил. со всеми вытекающими отсюда...

 

Блин. Слов нет. Одни слюни.
Чтоб сказать такого чтоб коротко и ясно.

Для того чтобы программировать на ассемблере платформено независимый код.
Нужно:
1. Уйти от регистров, которых может быть разное количество, заменив их переменными. и переложим ответственность за сопоставления переменной регистру на компилятор.
2. Уйти от ограничений разрядности базовых типов, заменив их абстрактными, типа Integer, Float и т.д.
3. Возможности комманд разные, поэтому их тоже следует заменить на какие-то более абстрактные выражения.

И что мы получаем в итоге??? И где здесь ассемблер???

В силу своих рабочих обязанностей мне часто приходится создавать такие программные продукты, которые работают, то на Виндовс, то на Red Hat Linux. То с какой-нибудь специфической гремучей БД.

И Я ПРОГРАММИРУЮ НА АССЕМБЛЕРЕ.
И ВСЕ ПОЛУЧАЕТСЯ.

А сейчас я поясню почему. Я асолютно согласен с Крисом Касперски, в том, что ассемблер это игра без правил.
Но вот в этом то и фишка.

Пускай дан кирпич.

Из кирпичей можно строить.
Но ведь по жизни все далеко не так просто.
На кирпиче еще можно нацарапать свое имя или использовать его как орудие пусть не массового, но поражения

А высокоуровневому компилятору крайне трудно объяснить, что кирпичи летают при определенных условиях.

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

Я пишу на FASM и мои программы выглядят примерно следубщим образом

.Data
TFile fl
fl.Store

TAnsiString _Hello, 'Hello',\
_FileName, 'Check.txt'

.Code
proc Main
fl.OpenWrite _FileName
fl.Write _Hello, _Hello.Size
fl.Close
ret
endp

Тут я так полагаю даже комментариев не нужно. И для того чтобы портировать этот код на другую ОС достаточно внести коррективы в методы. Я считаю это разумным.
Это, конечно, спорный метод. почему бы просто не взять и не написать то же самое на ЯВУ?
Но ведь есть еще и другие примущества.

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

Часто трехдневное ковыряние в чужом коде экономит несколько месяцев работы.

По поводу того что специалисты ассемблерщики не востребованы, либо востребованы на специфических задачах. Это чушь, причем, полная.

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

Это качества хорошего программиста вообще, а не только ассемблерщика. Просто если при программировании на ЯВУ это проявляется четко при работе над достаточно большими проектами, то при программировании на ассемблере необходимость в этом проявляется уже при работе над мелкими задачами. И проявляется настолько ярко и четко, что глаза режет.