Чего Вам не хватает в С ?

Booster
Портабельность и правда смешная причина. Для своих задач асм подходит идеально. Проблема в том, что круг этих задач весьма узок по сравнению с общим кругом задач, решаемых программистами. Но это не есть недостаток асма, это просто особенность. Поэтому в асе для решения _его_ задач всего хватает в достатке.
Я вот частенько юзаю асм вставки в Си в системных программах - очень удобно, и низкоуровневость асма и гибкость Си в одном флаконе.
(Я не написал еще ни одной программы на чистом ассемблере кроме, разве что, hello world и аналогов, когда только изучал асм. И не считаю это необходимым.)

 

Ursus

вне всякого сомнения. однако, расстояние между С и алголом (пример взят отсюда)

Код (Text):

1. procedure Absmax(a) Size:(n, m) Result:(y) Subscripts:(i, k);
2.     value n, m; array a; integer n, m, i, k; real y;
3. comment Максимальный элемент матрицы a, размера n на m
4.  передаётся в виде результата в y, а его индексы — в параметры i и k;
5. begin integer p, q;
6.     y := 0; i := k := 1;
7.     for p:=1 step 1 until n do
8.       for q:=1 step 1 until m do
9.         if abs(a[p, q]) > y then
10.         begin y := abs(a[p, q]);
11.           i := p; k := q
12.         end
13. end Absmax

, всеже, больше, чем между С и тем же С++, где главная техническая особенность - значительно расширенная идея структуры.
те, если в С часто приходится писать так

Код (Text):

1. typedef structure {
2. //...................................
3. } contextA;
4.  
5. void SomeProcOfA(contextA *A){
6. //....
7. }

этот момент и был выделен. ну и некоторые небольшие мета-возможности (операторы/шаблоны). причем, С++ не был единственным предложенным решением. был еще обжективС, алеф. после того, как беллабс обанкротились и пошли по рукам, развитием этих лангов занялись фирмы их купившие. обжективС отошел к эпплу, С++ купили сразу борланд и мс. от их совместной массированой рекламы и воен и возникло мнение, что с++ это наше все, хотя алеф был прогрессивнее. например, кроме объектов, шаблонов и наследования (на мой взгляд более красивого в записи, чем в С++) он изначально поддерживал на уровне языка оба варианта многопоточности, содержал развитую поддержку синхронизации и каналов. умел обращаться с множествами. был полностью основан на уникоде. еще некоторые фичи. при этом был полным компилятором.
не пошел, скорей всего, толи потому что подобные возможности в то время (win3.1) были лишними и могли только скомпрометировать ось. толи потому, что белы заломили за него слишком много, не скажу. но и сейчас он выглядит очень привлекательно. умеет делать 386 код.
его прямой внук - go. кое что потерял, кое что получил. кстати, если чегото сильно не хватает в С, то можно активно потребовать этого в го, которого счас как раз активно делают

 

Booster

если не использовать в коде специфические инструкции, то, думаю, легко.
Для етого небходим транслятор asm кода для интеловских процов на arm/mips. Например, на основе llvm.
mov он и в африке mov, даже если будет называться как то иначе(st, store ).

 

Great
И правда смешная, если всё ограничивается только одной платформой. В 64 битной винде имеется набор 32 и 64 библиотек, подумаешь немного разжирела. По слухам майкрософт отказывается от асм вставок в студии, только интристики.

Clerk

Тут как бы речь не совсем про линукс. Проблема несколько шире. Вот вы написали драйвер для 32 бит на масме, для 64 бит вам придётся переписывать поболее, нежели бы Вы написали его на Си.

 

смена архитектур происходит не так уж и часто

 

Booster
Не придётся. Можно это дело автоматизировать, написав простенький транслятор, это jabocrack имел ввиду. Собственно сишный скрипт это и делает, но можно сделать тоже для бинарного кода. Тупо по таблицам заменить поток инструкций на их аналоги, отделив код от данных с поправкой ветвлений. Для бинарника несколько сложнее конечно чем в сурцах, но по сути это морфинг. Если возникнет необходимость конвертации в x64 именно так и поступлю.

 

Кагбе, во всем цивилизованном мире принято за аксиому, что код на асме обходится (написание, отладка, поддержка, портирование) на порядки дороже, чем аналогичный код на ЯВУ.
Хотите начать обсуждать это по второму кругу?

 

Ursus

я с этим не спорю. но речь то шла о портировании кода.

 

Clerk

Здорово, но проблема в том, что у вас по определению архитектурозависимый код. Использовать преимущества другой архитектуры он не в состоянии. К тому же транслировать ассемблер в общем случае не возможно или сверх геморно. Пример: у вас в 32 битном регистре число, вы сделали арифметическую операцию, произошло переполнение. Если тупо перенести это дело на 64 бит регистр, то переполнения не будет или будет, но тогда другой код будет работать не верно. Как Вы собираетесь в анализаторе решать подобные проблемы?

 

qqwe а можно ссылки на язык Алеф? Я чего-то не нашел, а языки программирования - мое увлечение. Твое описание заинтересовало, хочу почитать что это такое.

 

Booster

LLVM Language Reference Manual

 

jabocrack
Вообще-то LLVM это не ассемблер.

 

Booster
но для наших задач подходит идеально

 

Booster

 

jabocrack
В общем-то выделять не обязательно. С таким же успехом си тоже ассемблер. Ассемблер это когда листинг и дизасм совпадают, иначе это hll.

 

xcode
http://en.wikipedia.org/wiki/Alef_(programming_language)
там есть ссылки на доки. читать их. сорцы алефа времен развала белы раздают бесплатно. есть пару портов на современные планы.
в свое время, я пробовал спортировать его на вин. он полностью совместим с линейкой кен-цц. (это компилерная линейка плана, го, нативной инферно). частично удалось, но на полную проработку многозадачности не хватило времени. в принципе, я представляю где я ошибся, но сейчас времени нет. так что, если есть желание, то можете включиться.

размер самого компилера без препроцессора около 300кб. таким образом, он вполне может использоваться для встраиваемых целей.
ну и кен-цц само по себе содержит несколько расширенное ансиС и асм с линкером.

 

xcode
+ (есть описалова еще и в пс/пдф формате. но я их прямо счас не нашел)

 

jabocrack
есть еще ACK.
http://ru.wikipedia.org/wiki/Amsterdam_Compiler_Kit
http://tack.sourceforge.net/
http://www.cs.vu.nl/ack/
он меньше llvm. ансиС компилер у меня собрался в ~200кб. пипхол оптимайзер в ~50кб, транслятор в 386 as ~50кб. причем, код довольно приличный. моментов наподобие

mov [ebp-8], eax
mov ebx,[ebp-8]

практически не наблюдается

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

 

qqwe а язык-то супер! жаль что он мне раньше не попадался

 

baldr

Всё-таки исходный текст программы в UNICODE, который можно прямиком засунуть в компилятор и всякие албанские шифровки из циферок после \u- это две большие разницы. Хотя бы потому, что во втором случае я не могу в файл-менеждере попросить найти мне все сишные исходники со словом まんこ, а в первом - мог бы. Ведь исходник программы, по идее, всего лишь текстовый файл, не так ли? Тогда почему бы этим текстовым файлам не перейти, наконец, из эпохи дикости к более современным кодировкам? Правда, случись такое - изначально дефективная сучность консоли вылезла бы во весь рост, а юниксвэйные копролиты сосали бы в турборежиме.