LINUX.ORG.RU
Форум — Development  

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


0

0

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

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


 ← 1 2 3 →
Ответ на: комментарий от koTuk

> Не пиши на том что удобно а пиши на том что знаю я

Ты не специалист. Откуда тебе знать, что удобно, а что нет?

> Давно ли знание assembler стало позорным ?

Не знание, а неуместное использование.

> Пишу я на том что лучше знаю

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

> и что мне больше нравится

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

И, как бы, для Си, да и для ассемблера, дебаггер тоже практически не нужен. Как-то эту тему ты обтёк, а зря. Попробуй понять такую простую истину.

anonymous
()

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

D ?

anonymous
()
Ответ на: комментарий от anonymous

>И, как бы, для Си, да и для ассемблера, дебаггер тоже практически не нужен. Как-то эту тему ты обтёк, а зря. Попробуй понять такую простую истину.

Создалось стойкое ощущение что ты понятия не имеешь о чем говоришь.

koTuk ☆
()
Ответ на: комментарий от koTuk

> Создалось стойкое ощущение что ты понятия не имеешь о чем говоришь.

У меня давно такое ощущение в отношении тебя.

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

>У меня давно такое ощущение в отношении тебя.

Мнение человека основные сообщения которого в разделе Talks меня не особо заботят. Хоть бы по теме что сказал.

koTuk ☆
()
Ответ на: комментарий от koTuk

По теме я тебе, дебилушка, сказал вторым сообщением в этой теме. А если ты не в состоянии въехать, когда тебе говорят разумные вещи - лечи ФГМ.

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

>По теме я тебе, дебилушка, сказал вторым сообщением в этой теме. А если ты не в состоянии въехать, когда тебе говорят разумные вещи - лечи ФГМ.

Что ты сообщил полезного в своем посте кроме того что слышал про существование такого языка как Форт ?

koTuk ☆
()
Ответ на: комментарий от koTuk

1) Ещё - чтобы ты это своё желание полечил.

2) Пойми наконец, что в подавляющем большинстве случаев использование дебаггера - ошибка.

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

> что в подавляющем большинстве случаев

какие ещё случаи? Конкретику гони, любитель общих фраз.

anonymous
()
Ответ на: комментарий от koTuk

> Создалось стойкое ощущение что ты понятия не имеешь о чем говоришь.

Чувачок, твои быдлоощущения говна не стоят. Я прекрасно понимаю, о чём говорю. Попробуй сам попользоваться unit tests, asserts и logging вместо быдлодебага, сам поймёшь, в чём разница.

anonymous
()
Ответ на: комментарий от koTuk

Дебаггер нужен таким, как я, кто разрабатывает компиляторы. Иногда. Очень редко. Всем остальным он не нужен. Все остальные, когда пользуются дебаггером - лохи.

anonymous
()
Ответ на: комментарий от koTuk

> И, как бы, для Си, да и для ассемблера, дебаггер тоже практически не нужен.

дебаггер для С нужен, поэтому С и не стоит использовать. Нужно использовать языки, обеспечивающие Referential transparency, например Haskell, и дебаггер будет ненужен. Есть более интересные способы потратить свое время, чем дебаг...

imp ★★
()
Ответ на: комментарий от koTuk

> Я не могу себя заставить изучать некоторые вещи - regexp, sendmail.cf, интерфейс gdb :)

Жесть. Каким ты там программированием хочешь заниматься? Низкоуровневым?

Hint: ифейс gdb просто и удобен. Ну и открой для себя C-x A

Bohtvaroh ★★★★
()
Ответ на: комментарий от imp

> дебаггер для С нужен

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

anonymous
()
Ответ на: комментарий от Bohtvaroh 

>Жесть. Каким ты там программированием хочешь заниматься? Низкоуровневым?

Я не только хочу но и занимаюсь в отличие от некоторых:

#include <avr/io.h>
#include <util/delay.h>
#include <stdio.h>

#define VCC PC0
#define RESET PC1
#define RDY PC2
#define OE PC3
#define WR PC4

#define BS2 PB0
#define BS1 PB1
#define XTAL1 PB2
#define XA0 PB3
#define XA1 PB4
#define PAGEL PB5

#define nop __asm__ volatile ("nop");

int main(void)
{
	char i;

	DDRB = 0xFF;
	DDRC = 0xFF & ~(1<<RDY);
	DDRD = 0xFF;

	PORTC = (1<<VCC)|(1<<RESET);
	PORTB = 0;
	PORTD = 0;
	_delay_ms(3);
	PORTC &= ~(1<<VCC);
	_delay_ms(3);

	for(i=0; i<10; i++)
	{
		PORTB |= (1<<XTAL1);
		nop
		PORTB &= ~(1<<XTAL1);		
	}

	PORTC &= ~(1<<RESET);
	_delay_ms(3);

	PORTC |= (1<<WR)|(1<<OE);
	_delay_ms(3);

// low byte
	PORTB |= (1<<XA1);
	PORTD = 0x40;
	nop
	PORTB |= (1<<XTAL1);
	nop
	PORTB &= ~(1<<XTAL1);
	nop

	PORTB |= (1<<XA0);
	PORTD = 0xE2;
	PORTB &= ~(1<<XA1);
	nop
	PORTB |= (1<<XTAL1);
	nop
	PORTB &= ~(1<<XTAL1);
	nop

	PORTC &= ~(1<<WR);
	nop
	PORTC |= (1<<WR);
	nop
	while (!(PINC & (1<<RDY)));
	_delay_us(100);	

// high byte
	PORTB |= (1<<XA1);
	PORTD = 0x40;
	PORTB &= ~(1<<XA0);
	nop
	PORTB |= (1<<XTAL1);
	nop
	PORTB &= ~(1<<XTAL1);
	nop

	PORTB |= (1<<XA0);
	PORTD = 0xDF;
	PORTB &= ~(1<<XA1);
	nop
	PORTB |= (1<<XTAL1);
	nop
	PORTB &= ~(1<<XTAL1);
	nop

	PORTB |= (1<<BS1);
	nop

	PORTC &= ~(1<<WR);
	nop
	PORTC |= (1<<WR);
	nop
	while (!(PINC & (1<<RDY)));
	_delay_us(100);	

	PORTB &= ~(1<<BS1);
	nop
	PORTC |= (1<<VCC)|(1<<RESET);
}

Объясни - зачем мне для написания подобного кода нужен regexp ?
Отладить без симулятора не имея целевого кристалла тоже сможете ? Усилием разума...

PS кому интересно - это было написано для сброса fuse в atmega48 в
режиме параллельного программирования. Частота генератора 1 мГц. 
Компилятор avr-gcc v.4.2.2

koTuk ☆
()
Ответ на: комментарий от koTuk

Всё с тобой ясно. Тот же код можно написать на порядок более читабельно, всего лишь применив пару-тройку #define-ов. Ты же сам создаёшь себе трудности, которые потом героически преодолеваешь.

anonymous
()
Ответ на: комментарий от anonymous

>Всё с тобой ясно. Тот же код можно написать на порядок более читабельно, всего лишь применив пару-тройку #define-ов. Ты же сам создаёшь себе трудности, которые потом героически преодолеваешь.

Основная трудность не в #define а заставить подобное работать. Код я не прилизывал для публичного использования а поместил как есть рабочий вариант. Тут все элементарно. Хотел бы я посмотреть как ты пишешь, прежде чем говорить.

koTuk ☆
()
Ответ на: комментарий от anonymous

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

За мою 30-летнюю жизь я ниразу не летал на самолете, может они нафик никому не нужны ? Для программиста с 15 летним стажем вы слишком примитивно рассуждаете

koTuk ☆
()
Ответ на: комментарий от koTuk

> Основная трудность не в #define а заставить подобное работать

Чтоб заставить код работать, код надо сразу писать просто и понятно. Тогда не останется мест, где можно ошибиться. Для этого есть множество техник, одна из мощнейших - литературное программирование.

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

Вот об этом я и говорю. Если ты для себя так криво пишешь, то понятно, зачем тебе дебаггер и прочие глупости. Нормально писать надо не для "публичного использования", а для себя же, чтобы избежать даже потенциальной возможности ошибиться. Чем короче и проще код, чем чётче видна тождественность кода и заявленной спецификации (пусть даже русским языком написанной рядом с кодом), тем меньше вероятность ошибки (и проще отладка - видя спецификацию ты можешь вывести граничные условия, на которых несоответствие легко верифицируется).

anonymous
()
Ответ на: комментарий от koTuk

Чудак ты человек. До тебя никак не доходит, что если ты пишешь правильно, то дебаггер не нужен просто по определению. Если ты пишешь плохо, то ты ССЗБ, и дебаггер не очень то и поможет, только создаст иллюзию возможности отладки говнокода. Если тебе приходится работать с чужим плохим кодом, то дебаггер может быть уместен, но в особых и исключительных случаях, тогда как во всех иных ситуациях следует применять более надёжные и корректные методики отладки.

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

anonymous
()
Ответ на: комментарий от anonymous

Очень правильные слова, полностью согласен с вами - не могли вы на конретном примере который выше научить меня как более правильно написать ?

koTuk ☆
()
Ответ на: комментарий от anonymous

> если ты пишешь правильно, то дебаггер не нужен просто по определению

А ты всегда пишешь правильно?

> чем спорить с профессионалами

Разне проофессионалы имеют разные мнения по этому вопросу. Или те, кто считает отладчики полезными инструментами, не попадают под твое определение профессионала?

tailgunner ★★★★★
()
Ответ на: комментарий от koTuk

Не могу, конечно же. Я не знаю предметной области, и из кода её восстановить невозможно. Твой код паршив в первую очередь тем, что информационно не полный. Имена флагов такие, что легко запутаться. Сам способ записи установки флага такой, что легко опечатку сделать и потом три дня её последствия дебаггером искать. Вместо банального set_flag(очень-длинное-подробное-имя) ты явным образом пишешь все эти (1<<флаг)|(1<<другой-флаг).

Почитай книги умные (даже тот же нелюбимый тут Code complete), почитай про literate programming. Посмотри на код, написанный настоящими мастерами (например, код TeX и Metafont).

anonymous
()
Ответ на: комментарий от tailgunner

> А ты всегда пишешь правильно?

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

> Разне проофессионалы имеют разные мнения по этому вопросу.

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

> Или те, кто считает отладчики полезными инструментами, не попадают под твое определение профессионала?

Именно. Не попадают. Так считают любители, не имеющие промышленного опыта, студенты, которые ещё ничему не научились и неудачники от индустрии.

anonymous
()
Ответ на: комментарий от anonymous

>Не могу, конечно же. Я не знаю предметной области, и из кода её восстановить невозможно.

Об этом и речь - как можно вообще судить не зная предмета обсуждения ?

>Имена флагов такие, что легко запутаться.

Имена флагов как раз такие чтобы не запутаться - они четка описаны в спецификации на программирование данного микроконтроллера. Для этого они и были переопределены в начале.

koTuk ☆
()
Ответ на: комментарий от anonymous

>> А ты всегда пишешь правильно?

> Всегда.

Ты есть БОХ!

> мои ошибки выявляются ассертами и тестами

Нет, нихрена не бох :(

>> Или те, кто считает отладчики полезными инструментами, не попадают под твое определение профессионала?

>Именно. Не попадают.

Тогда вопросов нет.

tailgunner ★★★★★
()
Ответ на: комментарий от koTuk

> Об этом и речь - как можно вообще судить не зная предмета обсуждения ?

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

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

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

anonymous
()
Ответ на: комментарий от tailgunner

> Нет, нихрена не бох :(

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

Дебаггер ведь проблему ошибок не решает. Дебаггер - лечение симптомов, что далеко не всегда равнозначно лечению причины проблемы. Часто ad hoc исправление ошибки, выявленной дебаггером приводит к паре-тройке новых ошибок, на этот раз не столь явных, которые дебаггером вообще не увидишь.

Так что тесты, ассерты и чёткие спецификации на человекочитабельном языке, внедрённые в код - это обязательное требование. Без его выполнения ошибки будут, всегда, в больших количествах, и никакие дебаггеры не спасут.

anonymous
()
Ответ на: комментарий от anonymous

Сидят как-то дедушка с внучкой на берегу речки, тут мимо них гавно проплывает!
Внучка говорит- Дедушка, а от куда здесь гавно??
Дедушка- Это древняя легенда внучка,- давным-давно на берегу этой речки стоял огромный, красивый замок, и жила там принцесса-красавица! Принцесса эта влюбилась в воеводу, и он тоже её любил! Но Король отправил этого воеводу на войну где он героически погиб, принцесса узнав об этом с горя скинулась со скалы прямо в эту речку!
- Дык Дедушка, от куда здесь гавно?
- Я е**у, насрал кто-то!

koTuk ☆
()
Ответ на: комментарий от koTuk

> Объясни - зачем мне для написания подобного кода нужен regexp ?

Хз, тебе виднее. Я только хочу сказать, что надо быть полным дауном, чтобы не осилить gdb. Извини за грубость, наболело.

Bohtvaroh ★★★★
()
Ответ на: комментарий от Bohtvaroh

>Я только хочу сказать, что надо быть полным дауном, чтобы не осилить gdb.

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

Кроме gdb в linux я так понимаю альтернативы нет, поэтому осиливать его все же пришлось.

koTuk ☆
()
Ответ на: комментарий от anonymous

> Правильно писать - вообще не проблема, любой дурак может

Но при этом ты (по крайней мере, иногда) пишешь неправильно? И кто ты после этого, по своему же определению?

> Дебаггер ведь проблему ошибок не решает.

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

> Часто ad hoc исправление ошибки, выявленной дебаггером приводит к паре-тройке новых ошибок

Аха, и в таком кривом исправлении ошибок тоже виноват дебагер.

> тесты, ассерты и чёткие спецификации на человекочитабельном языке, внедрённые в код - это обязательное требование

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

А я иногда использую дебаггер, чтобы лучше разобраться с программой или библиотекой, степаясь по ней. :) Вот.

Bohtvaroh ★★★★
()
Ответ на: комментарий от tailgunner

> Но при этом ты (по крайней мере, иногда) пишешь неправильно?

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

> но дебагер часто (не всегда) удобнее всего.

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

> Аха, и в таком кривом исправлении ошибок тоже виноват дебагер.

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

> И что, это противоречит использованию дебагера?

Это делает использование дебаггера абсолютно ненужным.

> Странно, 15 лет опыта (если это ты сказал) - и такой юношеский максимализм..

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

Если правильно подобрать определение термина "юноша", (все, кто пользуется дебагером больше "anonymous (*) (25.04.2008 16:19:07)", являются юношами), тогда конечно.

Вот как искали баги в EGCS: "the way we will find the bug is by running a single example under the debugger with breakpoints, not by pure deduction from a series of examples". Они тоже "юноши"?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

Понимаешь ли, гражданин ламер, дебаггер ничего связанного с непосредственно ошибкой тебе и не показывает. И все существующие методики отладки НЕ ГАРАНТИРУЮТ обранужения причины ошибки.

> Вот как искали баги в EGCS

Ты вообще читать умеешь? Разработку компиляторов я в отдельную категорию вынес. Для этой цели и я использую дебаггер - и то, практически никогда не интерактивно, а как часть автоматизированной системы тестов (и тут ничего кроме gdb вообще не подошло бы, поскольку гуйня не автоматизируется и не скриптуется).

anonymous
()
Ответ на: комментарий от anonymous

>Ты реально невменяемый.

>Код - говно, потому что error prone. Точка. Остальное нерелевантно.

error prone - это потому что вы так решили дедушка ? Код 100% рабочий, отладить его если честно даже на симуляторе не получится - тут я немного слукавил но вы конечно про это не поняли потому что понятия не имеете о чем речь. Здесь гораздо важней натурные испытания в реальном времени это всего лишь часть - основа, чтобы на основе этой отлаженной процедуры сделать полнофункциональный программатор в режиме параллельного программирования и вот тут все о чем вы говорите уже реально понадобится.

koTuk ☆
()
Ответ на: комментарий от koTuk

> error prone - это потому что вы так решили дедушка ?

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

anonymous
()
Ответ на: комментарий от anonymous

> Понимаешь ли, гражданин ламер

Объясняешь плохо, гражданин хакер.

> все существующие методики отладки НЕ ГАРАНТИРУЮТ обранужения причины ошибки.

А если не гарантирует, не достойно использования. Ну я же говорю - юношеский максимализм.

>> Вот как искали баги в EGCS

>Ты вообще читать умеешь? Разработку компиляторов я в отдельную категорию вынес.

Компилятор ничем не качественно не отличается от обычной программы. Кроме самомнения разработчиков, разве что.

> гуйня не автоматизируется и не скриптуется

это оффтопик, но 4.2

</thread>

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Компилятор ничем не качественно не отличается от обычной программы.

Я говорю об отладке кода, который компилятор генерит.

> это оффтопик, но 4.2

Попробуй оторвать GUI от дебаггера в MSVS, умник. Так, чтоб он из юнит тестов запускался молча.

anonymous
()
Ответ на: комментарий от anonymous

> Я говорю об отладке кода, который компилятор генерит.

А я запостил фрагмент об использовании gdb при отладке самого компилятора.

> Попробуй оторвать GUI от дебаггера в MSVS, умник. Так, чтоб он из юнит тестов запускался молча.

Зачем? Существуют специальные программы, которые умеют скриптовать вещи типа "нажми на эту кнопочку" и "введи вот это в поле ввода". Да и вообще : меня MSVS не интересует, а "под капотом" Eclipse - gdb.

"Ты вообще читать умеешь?" (c)

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

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

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

koTuk ☆
()
Ответ на: комментарий от tailgunner

> А я запостил фрагмент об использовании gdb при отладке самого компилятора.

Компилируемого самим этим компилятором, между прочим. Боюсь, во времена EGCS ты ещё в его разработке поучаствовать не успел.

> Существуют специальные программы, которые умеют скриптовать вещи типа "нажми на эту кнопочку" и "введи вот это в поле ввода".

Я же сказал - без GUI. Тестирование автоматическое, GUI там вообще нет. Надо выполнять последовательность действий вида "поставить brakepoint на такую-то строку" (хрен ты это автоматизируешь в гуйне паршивой), "выполнить", "проинспектировать такие-то переменные", сравнивть вывод с требуемым, подняться на уровень выше в стеке вызовов, проинспектировать, сравнить вывод, и т.д.

Башка у тебя оторвётся писать сотни таких тестов поверх гуйни.

anonymous
()
Ответ на: комментарий от koTuk

> было гораздо проще и нагляднее написать на assembler

Если это макроассемблер - то поверю. Иначе - пошлю тебя на хер, по причине твоей невменяемости.

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

anonymous
()
Ответ на: комментарий от anonymous

> Боюсь, во времена EGCS ты ещё в его разработке поучаствовать не успел.

Ну, меня-то компиляторы никогда не интересовали. Ни тогда, ни сейчас :D

> Я же сказал - без GUI

Ты сказал: "гуйня не автоматизируется и не скриптуется". Это не так :-P

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

>Re: Низкоуровневый язык программирования
>И вообще, зря ты прицепился к железу, мы обсуждаем программирование под линукс.

Я ценю ваше стремление отстаивать свою точку зрения до конца - но наверно всему есть предел.

http://www.atmel.com/products/AVR32/
http://www.avrfreaks.net/wiki/index.php/Documentation:AVR32_Linux_Development...

казалось бы - причем тут linux...

koTuk ☆
()
Ответ на: комментарий от anonymous

>И все существующие методики отладки НЕ ГАРАНТИРУЮТ обранужения причины ошибки.

man delta debugging. Уж куда больше автоматизировать.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 →
Development