Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: GCC + Eclipse комментарии к коду
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > GNU/OpenSource средства разработки
ZiB
May 22 2009, 05:07
Случайно заметил.
Что если комментировать код так (по умолчанию в Eclipse именно так):
Код
/*
* Test
*/
void test(void)
{
}

то при просмотре asm листинга комментарии иногда теряются, но если использовать вот такую конструкцию, то остаются:
Код
//------------------------------------------------------------------------------
/// Test
//------------------------------------------------------------------------------
void test(void)
{
}

Есть ли какие либо правила комментирования кода для GCC?

P.S. Использую связку gcc + Ecplise.
MrYuran
May 22 2009, 07:16
Эклипс имеет встроенный doxygen, /// - это doxy-стайл.
Подозреваю, что аналогичный эффект будет с /*! ... */ и //!
также можно вставлять спец. тэги (типа \brief)
alx2
May 22 2009, 10:31
Цитата(ZiB @ May 22 2009, 10:07) *
Случайно заметил. Что если комментировать код так (по умолчанию в Eclipse именно так):
то при просмотре asm листинга комментарии иногда теряются,
Что подразумевается под "иногда"? В каком случае теряется?
ZiB
Jun 4 2009, 08:53
Цитата(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;
    }

как видим полное не соответствие действительному коду.
alx2
Jun 4 2009, 14:01
Цитата(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
Обратите внимание, насколько сильно различается формат этих листингов...
Сергей Борщ
Jun 4 2009, 15:59
Цитата(alx2 @ Jun 4 2009, 17:01) *
Чуть внимательнее посмотрел на этот листинг. Что за странный формат у него?
Это формат вывода avr-objdump. В первой колонке не номера строк, а адреса. А несовпадение с исходником - результат действий оптимизатора.
ZiB
Jun 5 2009, 08:34
да, это вывод avr-objdump
Код
avr-objdump -h -S AVR.elf  >"AVR.lss"

уже начинаю привыкать smile.gif
alx2
Jun 5 2009, 11:35
Цитата(ZiB @ Jun 5 2009, 13:34) *
да, это вывод avr-objdump
Код
avr-objdump -h -S AVR.elf  >"AVR.lss"

уже начинаю привыкать smile.gif
То есть вывод дизассемблера? А надо ли к этому привыкать? Не лучше ли пользоваться именно листингом, который создает ассемблер? Там все-таки показан код в том виде, как его сгенеририл компилятор. А после ассемблирования и последующего дизассемблирования потери, наверное, неизбежны...
Сергей Борщ
Jun 5 2009, 20:28
Цитата(alx2 @ Jun 5 2009, 14:35) *
Не лучше ли пользоваться именно листингом, который создает ассемблер?
У всего есть плюсы и минусы. В этом листинге видно что именно, куда именно и в каком виде попало в конечную прошивку - там видны конечные адреса, можно посмотреть что линкер выкинул по --gc-sections и что он натворил по --relax. Нет кучи меток на одну команду (в вашем листинге это LM0, LFBB1 и LBB2, а в армовых листингах их бывает порой на полэкрана через команду).
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.