Низкоуровневый язык программирования

gas (в составе binutils), nasm, fasm

http://www.wasm.ru/publist.php?list=28

Форт.

> Просто я хочу заняться низкоуровневым кодингом под Linux

Полежи, пройдёт.

>Просто я хочу заняться низкоуровневым кодингом под Linux

А чего конкретно хочется? Если прямого доступа к железу - то либо ядро ковырять либо дос.

еще:
man iopl
man ioperm

из ассемблеров есть gas (с AT&T синтаксисом) и nasm (с интелевым синтаксисом; сильно похож на tasm, но, имхо, лучше и прозрачнее)

> Какие есть низкоуровневые языки программирования под Линь(Кроме Си)?

Ди :) с inline-asm'ом :)

>Кто-нить пользовался? Как ощущения?

Одна из проблем - нет нормального отладчика, gdb - никуда не годится. 
Не советую начинать вообще писать на assembler под linux кроме отдельных
частей в составе высокоуровневых языков.

> gdb - никуда не годится.

Почему? Багу в gcc я им когда то нашёл, больше ничего серьёзного не отлаживал, но вроде всё, что нужно, там есть.

>> gdb - никуда не годится.

>Почему? Багу в gcc я им когда то нашёл, больше ничего серьёзного не >отлаживал, но вроде всё, что нужно, там есть.

При всех недостатках windows у нее есть один неоспоримый плюс 
(по крайней мере был раньше :) - интуитивно понятный интерфейс. То же 
самое можно сказать о продуктах которые под нее пишутся. Очень сложно 
сосредоточиться на отладке когда надо помнить сочетание и жать кучу 
клавиш чтобы увидеть на экране то что тебе хочется. Все фронтенды 
которые я пробовал не решили для меня этой проблемы. Некоторые говорят
 - для чего нужен хороший отладчик - надо писать правильный код :) Не 
всегда так получается к сожалению. Показательный пример - попросили 
меня как то посмотреть почему не работает программа со сторонней 
библиотекой  опенсурсной - пример работает а свой код практически один
 в один из примера - нет. Причем внутри самой библиотеки результат 
правильный судя по дебаг мессагам а на выходе - полная ерунда. Изначально было неправильное направление поиска - думали во всем виноваты threads. Оказалось всего лишь config.h был включен не в том 
месте - внутри библиотеки и в самой программе где получали результат в
 виде объемной структуры оказались разные объявления типа size_t , в 
результате поля структуры которые имели этот тип смещались.
 Сомневаюсь что без отладчика быстро удалось бы найти ошибку.

> Очень сложно > сосредоточиться на отладке когда надо помнить сочетание и жать кучу > клавиш чтобы увидеть на экране то что тебе хочется.

Это всего лишь дело привычки. Да и классический windbg.exe не слишком дружественен :)

>Это всего лишь дело привычки. Да и классический windbg.exe не слишком дружественен :)

Привычка это одно, совсем другое лень - двигатель прогресса :) Я не могу себя заставить изучать некоторые вещи - regexp, sendmail.cf, интерфейс gdb :)
Вот уж чего нельзя назвать классикой так это windbg.exe.

C++ и php

Второе потому что это глобально и надёжно? По теме: C, gas.

>> gdb - никуда не годится.

> Почему? Багу в gcc я им когда то нашёл, больше ничего серьёзного не отлаживал, но вроде всё, что нужно, там есть.

А его уже научили отлаживать также все форкнутые процессы?

Соглашусь с Miguel'ем. Для общего развития Форт полезно глянуть. Этакий Лисп наоборот, никаких скобок, постфиксная нотация, низкий уровень - полшага от ассемблера.

> Какие есть низкоуровневые языки программирования под Линь
Под что?

>Под что?

Неважно :) Если под это есть языки программирования, под него есть язык ассемблера и тривиально портируется форт.

> А его уже научили отлаживать также все форкнутые процессы?

да

// wbr

Дык линь этож "корабельный трос толщиной меньше одного дюйма по окружности". Получится ли портануть туда форт? Или линь это рыба такая? Тогда вопрос про форт остаётся открытым :-/

дебаг в линуксе - это одно из узких мест , кои нужно расширять

Мышевоз?

Ну уж регулярные выражения должен знать каждый уважающий себя программист...

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

http://members.aon.at/vormayr/spd.c.bz2 - программа для чтения и 
интерпретации spd ram. В начале spd.c есть такое:

const char translation_table[6][16]......

Мне стало интересно для чего это, потом когда посмотрел и разобрался - 
посмеялся. Человек преобразует ascii код самого в себя через таблицу 
преобразования :) Можно до посинения оттачивать алгоритм но все смазать 
подобными вещами.

Расширяйте лучше дальше своё сознание, в линуксе с отладкой всё в порядке. Если в вашем любимом ide нет гламурно выглядещего отладчика, это не значит, что gdb, strace, valgrind, oprofile, systemtap и другие тулзы исчезли.

Не помню чтобы говорил что я программист. Скорее наоброт :)

Платформ, куда нельзя в натуральном виде портануть Форт - очень и очень мало :) Обычно это всякие однокристаллки, где нельзя писать в ПЗУ, а ОЗУ составляет только сотни байт.

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

правда родной интерфейс гдб мне как-то больше нравится.

Сейчас даже однокристалки многие поддерживают self-programming.

Давно всё сделано. Называется gdb/mi - machine interface

немножко не, то это скорее интерфейс, а вот библиотечки для работы с ним я чего-то не видел. А тут скорее интересно что-то вроде аннотаций(как в emacs'е), хотелось бы совместить интерфейс и родную гдбшную консоль с автодополнениями и прочим. gdb/mi этого к сожалению не умеет, есть такая глава GDB/MI Compatibility with CLI.

Молодец, только изучив ассемблер можно по-настоящему понимать Си.

хотя нет, вы правы gdb/mi самое то, но вопрос о библиотечке остается.

дополнения решаются так же как и в emacs'е, с помощью команды complete.

да но похоже некоторые команды придется транслировать в gdm/mi

такие как break например

b foo if bar

-break-insert -c bar foo

Совсем забыл про один замечательный инструмент который есть и под linux - IDA, у него появился олтадчик в последних версиях, правда я им не пользовался - неизвестно свой он или фронтенд к gdb.

>Мышевоз?

Мышелов :)

> интуитивно понятный интерфейс

Интуитивно понятный интерфейс только у сиськи. Всё остальное надо изучать.

> Сомневаюсь что без отладчика быстро удалось бы найти ошибку.

Учись писать корректные тест-кейсы.

> Я не могу себя заставить изучать некоторые вещи - regexp

Тогда ты не программист вообще, ни разу.

> интерфейс gdb

Что там изучать? Пять комманд, больше не надо. Интерфейс любой гуёвой хреновины гораздо сложнее.

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

>Тогда ты не программист вообще, ни разу.

см. выше

>Просто у тех, кто начинал с виндовса

начинал я с клона cp/м на robotron 1715, виндовс использую регулярно так же как и linux

>Что там изучать? Пять комманд, больше не надо.

Перечисли если не трудно эти пять команд которых тебе в gdb достаточно для отладки ?

> см. выше

Что выше? Ты не объяснил, как "программист" может не знать регулярных выражений.

> начинал я с клона cp/м на robotron 1715, виндовс использую регулярно так же как и linux

Ну, досятник, какая разница. Всё равно background неправильный, не юниксовый/мейнфреймный.

> Перечисли если не трудно эти пять команд которых тебе в gdb достаточно для отладки ?

info stack (самая часто используемая)

disas display print break

Ну и совсем тупые команды run/step*, где совсем нечего запоминать.

Нагугли себе gdb cheatsheet, распечатай и повесь на стену, если пальцы к быдломышке приросли и команды запоминать разучились.

> Ну, досятник, какая разница. Всё равно background неправильный, не юниксовый/мейнфреймный.

Какие-то левые штампы вешаешь.

> Что выше? Ты не объяснил, как "программист" может не знать регулярных выражений.

Там ясно сказано что я не программист

>info stack (самая часто используемая)
>disas display print break
>Ну и совсем тупые команды run/step*, где совсем нечего запоминать.

Если ты программист то хотя бы арифметике научись. Состояние регистров и сегментов данных конечно тебя не интересует, а уж то что их надо иногда видеть как в числовом так и в символьном виде одновременно тем более, то что существуют thread и их тоже неплохо видеть. Да у одной info только больше 40 подкомманд. Интересно было бы взглянуть хоть на один проект сделанный тобой.

> Там ясно сказано что я не программист

Даже тупо power user обязан знать регэкспы.

> Если ты программист то хотя бы арифметике научись.

Я назвал несколько больше чем обычно использую. То, что использую редко - поглядываю в cheatsheet.

> Состояние регистров и сегментов данных конечно тебя не интересует

Угодал. Абсолютно не интересует. Это при том, что я компиляторы разрабатываю.

> Да у одной info только больше 40 подкомманд.

Не помню, сколько лет назад я использова в последний раз что либо отличное от info stack.

self-programming форту на однокристалке не поможет.

> Угодал. Абсолютно не интересует. Это при том, что я компиляторы разрабатываю.

Дело конечно ответственное, если не секрет - под какую архитектуру и компилятор какого языка ?
Конечно я не силен в linux и программы пишу очень редко - в качестве хобби, это меня и привлекает в linux - не будучи профессиональным программистом можно делать что-то полезное для себя на основе открытых исходников. Но интерфейс у gdb мне совсем не понравился:)

> Но интерфейс у gdb мне совсем не понравился:)

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

> под какую архитектуру и компилятор какого языка ?

ARM, x86, x86-64. Всякая экзотика + JITы и AOTы для виртуальных машин.

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

А зачем, не будучи профессиональным программистом, писать на Си? Есть много хороших, удобных, безопасных языков, со своими средствами отладки.

> Но интерфейс у gdb мне совсем не понравился:)

Не профессиональному программисту в дебаггере вообще делать нечего. Абсолютно. Дебаггер - орудие для паталогоанатома, а не для разработчкика. Мне ещё куда ни шло, обычному прикладному программисту - на фиг не надо.

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

>красноглазики опять повылезали и начали галдеть , что гдб - это рулез

Очень многие анонимусы любят повторять крылатые фразы - их тут было сазано достаточно про то что вы никто и учились не на том а в linux все есть и все намного лучше :) Но когда начинаешь касаться конкретики то как-то быстро склеиваются... Разве это не крута когда для отладки человеку достаточно видеть только стек :)

> интерфейс гдб сильно ограничивает круг пользователей

Ты не поверишь, но у дебаггеров и без того очень ограниченный круг пользователей.

> приличную массу программеров отталкивает от линукса то , что тут нет ничего подобного

Это не программеры. Они не нужны.

> вот над чем надо работать клепателям линуксовых ide

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

> Разве это не крута когда для отладки человеку достаточно видеть только стек :)

Это крайняя мера, кстати. Когда корка упала и надо с ней разобраться. До момента падения в кору отладчики не нужны вообще.

> А зачем, не будучи профессиональным программистом, писать на Си? Есть много хороших, удобных, безопасных языков, со своими средствами отладки.

Потому что с давних пор увлекаюсь электроникой. Раньше писал только на assembler, С - потому что ядро linux и львиная доля прикладного ПО написано на С, появилось очень много библиотек на С для однокристалок. Интерпретируемые языки меня абсолютно не привлекают.

хм, например gdb-mode в emacs весьма приятен. да, он не добавляет гуйни, розовых соплей и прочих перделок, зато весело прыгает по брейкпоинтам в сорце.

> Потому что с давних пор увлекаюсь электроникой.

Ну пиши на Lava. Не вижу связи Си и электроники.

> Раньше писал только на assembler

Тише, тише, не позорься так. Такие факты биографии лучше скрывать.

> появилось очень много библиотек на С для однокристалок

Однокристаллки ты и дебажить не сможешь нормально.

> Интерпретируемые языки меня абсолютно не привлекают.

1) Тебе шашечки или ехать

2) Есть не только интерпретируемые. Посмотри на OCaml, например.

>Ну пиши на Lava. Не вижу связи Си и электроники.

Не пиши на том что удобно а пиши на том что знаю я - специалист linux ?

>> Раньше писал только на assembler

>Тише, тише, не позорься так. Такие факты биографии лучше скрывать.

Давно ли знание assembler стало позорным ? Хотя для специалистов linux х.з...

>Однокристаллки ты и дебажить не сможешь нормально.

Странно слышать такое от специалиста linux :)
http://www.oshec.org/articles/otladka-avr-pod-linuh/otladka-avr-pod-linuh

Пишу я на том что лучше знаю и что мне больше нравится и как это ни странно звучит - я не одинок в своем выборе.