| |
|
  |
 GCC + Eclipse комментарии к коду, Правильность офрмления |
|
|
|
|
 May 22 2009, 05:07
|
Частый гость
Группа: Свой
Сообщений: 122
Регистрация: 26-07-05
Из: Россия, Томск
Пользователь №: 7 109
|
Случайно заметил. Что если комментировать код так (по умолчанию в Eclipse именно так): Код /*
* Test
*/
void test(void)
{
} то при просмотре asm листинга комментарии иногда теряются, но если использовать вот такую конструкцию, то остаются: Код //------------------------------------------------------------------------------
/// Test
//------------------------------------------------------------------------------
void test(void)
{
} Есть ли какие либо правила комментирования кода для GCC? P.S. Использую связку gcc + Ecplise.
|
|
|
|
|
|
|
|
May 22 2009, 10:31
|
Местный
Группа: Участник
Сообщений: 340
Регистрация: 25-10-05
Из: Пермь, Россия
Пользователь №: 10 091
|
Цитата(ZiB @ May 22 2009, 10:07)  Случайно заметил. Что если комментировать код так (по умолчанию в Eclipse именно так):
то при просмотре asm листинга комментарии иногда теряются, Что подразумевается под "иногда"? В каком случае теряется?
--------------------
Всего наилучшего,
Alex Mogilnikov
|
|
|
|
|
|
|
|
Jun 4 2009, 08:53
|
Частый гость
Группа: Свой
Сообщений: 122
Регистрация: 26-07-05
Из: Россия, Томск
Пользователь №: 7 109
|
Цитата(alx2 @ May 22 2009, 17:31) Что подразумевается под "иногда"? В каком случае теряется? Добрался кое как. Вот пример: Код 00000422 <IO_init>:
Byte i = 0;
//
for (i = 0; i < KEY_NUMBER; i++)
{
Byte t = Count_Refrresh[i];
//
422: 90 9a sbi 0x12, 0; 18
424: 88 98 cbi 0x11, 0; 17
if (Get(i))
426: 91 98 cbi 0x12, 1; 18
428: 89 9a sbi 0x11, 1; 17
{
KEYBOARD_STAT[i] |= KEY_PRESS;
//
42a: c4 98 cbi 0x18, 4; 24
42c: bc 9a sbi 0x17, 4; 23
t++;
42e: c7 9a sbi 0x18, 7; 24
430: bf 98 cbi 0x17, 7; 23
//
432: c5 9a sbi 0x18, 5; 24
434: bd 98 cbi 0x17, 5; 23
if (t > 250) t--;
436: c6 9a sbi 0x18, 6; 24
438: be 98 cbi 0x17, 6; 23
}
else
{
43a: c3 9a sbi 0x18, 3; 24
43c: bb 9a sbi 0x17, 3; 23
KEYBOARD_STAT[i] = KEY_NOPRESS;
//
if (t > 20) KEYBOARD_STAT[i] = KEY_SHORTPRESS;
43e: dd 98 cbi 0x1b, 5; 27
440: d5 9a sbi 0x1a, 5; 26
if (t > 150) KEYBOARD_STAT[i] = KEY_LONGPRESS;
442: dc 98 cbi 0x1b, 4; 27
444: d4 9a sbi 0x1a, 4; 26
//
446: db 98 cbi 0x1b, 3; 27
448: d3 9a sbi 0x1a, 3; 26
t = 0;
} как видим полное не соответствие действительному коду.
|
|
|
|
|
|
|
|
Jun 4 2009, 14:01
|
Местный
Группа: Участник
Сообщений: 340
Регистрация: 25-10-05
Из: Пермь, Россия
Пользователь №: 10 091
|
Цитата(ZiB @ Jun 4 2009, 13:53) как видим полное не соответствие действительному коду. А где исходный код? Чуть внимательнее посмотрел на этот листинг. Что за странный формат у него? Какой версией gas он получен? Почему нумерация строк не подряд (после строки 422 сразу идет 424)? Почему некоторые строки не имеют номеров? Почему номера 16-ричные? Где имя файла в строках с исходником? Такое впечатление, что либо приведенное получено вообще не из gnu as, а каким-то совсем другим ассемблером, либо это вообще не листинг... Вот фрагмент листинга, который выдает мне GNU avr-as 2.18: Код 35 .global checkflags
37 checkflags:
38 .stabd 46,0,0
1:checkflags.c **** /*************************************************************
2:checkflags.c **** *
3:checkflags.c **** * checkflags.c
4:checkflags.c **** *
5:checkflags.c **** * Проверка различных флагов
6:checkflags.c **** * checkflags() периодически вызывается из основной нитки
7:checkflags.c **** * программы с максимально возможной частотой для проверки и
8:checkflags.c **** * обработки выставленных другими процессами флагов.
9:checkflags.c **** *
10:checkflags.c **** ************************************************************/
11:checkflags.c **** #include "pv110.h"
12:checkflags.c ****
13:checkflags.c **** extern char e_sent;
14:checkflags.c **** /*
15:checkflags.c **** * Комментарий
16:checkflags.c **** */
17:checkflags.c **** void checkflags(void)
18:checkflags.c **** {
40 .LM0:
41 .LFBB1:
42
43
44 .LBB2:
19:checkflags.c **** if(get_kflags() & send_ok_mask)
46 .LM1:
47
48 0000 812F mov r24,r17
49
50 .LBE2:
51 0002 87FF sbrs r24,7
52 0004 00C0 rjmp .L2
20:checkflags.c **** {
21:checkflags.c **** clear_register(kflags0, send_ok_mask|check_ack_mask);
54 .LM2:
55
56 0006 1F73 andi r17,~((1<<7)|(1<<6))
22:checkflags.c **** signal_scan[e_sent].flags &=~ fready;
58 .LM3:
59
60 0008 E091 0000 lds r30,e_sent
61 000c F0E0 ldi r31,lo8(0)
62 000e EE0F lsl r30
63 0010 FF1F rol r31
64 0012 EE0F lsl r30
.GAS LISTING page 2
65 0014 FF1F rol r31 Обратите внимание, насколько сильно различается формат этих листингов...
Сообщение отредактировал alx2 - Jun 4 2009, 14:28
--------------------
Всего наилучшего,
Alex Mogilnikov
|
|
|
|
|
|
|
|
Jun 5 2009, 08:34
|
Частый гость
Группа: Свой
Сообщений: 122
Регистрация: 26-07-05
Из: Россия, Томск
Пользователь №: 7 109
|
да, это вывод avr-objdump Код avr-objdump -h -S AVR.elf >"AVR.lss" уже начинаю привыкать 
|
|
|
|
|
|
|
|
Jun 5 2009, 11:35
|
Местный
Группа: Участник
Сообщений: 340
Регистрация: 25-10-05
Из: Пермь, Россия
Пользователь №: 10 091
|
Цитата(ZiB @ Jun 5 2009, 13:34) да, это вывод avr-objdump Код avr-objdump -h -S AVR.elf >"AVR.lss" уже начинаю привыкать То есть вывод дизассемблера? А надо ли к этому привыкать? Не лучше ли пользоваться именно листингом, который создает ассемблер? Там все-таки показан код в том виде, как его сгенеририл компилятор. А после ассемблирования и последующего дизассемблирования потери, наверное, неизбежны...
--------------------
Всего наилучшего,
Alex Mogilnikov
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
