Оберон-клуб «ВЄДАsoft»

Твердыня модульных языков
Текущее время: 21 ноя 2017, 16:01

Часовой пояс: UTC + 2 часа




Начать новую тему Ответить на тему  [ Сообщений: 26 ]  На страницу Пред.  1, 2, 3
Автор Сообщение
СообщениеДобавлено: 31 янв 2016, 18:02 
Не в сети

Сообщения: 26
Zorko писал(а):
Это ведь Си. И сборщику надо как-то дать знать, что это отслеживаемый указатель, а не простой.


Консервативному GC все равно - он тупо сканирует память, надеясь найти цепочку байт соответствующую указателю на выделенный блок памяти. Если такое совпадение есть - память не трогается, если нет - блок помечается как свободный. Поэтому работает это даже в случае С/С++. Но работает не совсем "точно" - если в памяти заваляется число, похожее на указатель, то такой блок не соберется GC. На этот факт, кстати, указывали info21 на небезызвестном форуме (GC у BB как раз консервативный), когда говорили о недопустимости вешать какую-то логику на FINALIZE - потому что нет гарантии, что он вызовется (даже если с точки зрения программы указатель не существует). Но он так и не понял :)

Zorko писал(а):
Впрочем, там генерируется вызов функции EnumPtrs для указателей, они обнуляются, наверное как-то так попадают и во внутренние структуры сборщика.


Указатели обнуляются, чтобы не было всеми так критикуемых dangled pointers. GC (консервативный как в BB) тут не причем.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 02 фев 2016, 20:16 
Не в сети
Администратор
Аватара пользователя

Сообщения: 237
Откуда: Россия
Zorko писал(а):
2Saferoll: Олежек, есть мысль отказаться от опции "SDCC support". Ведь можно объявлять макрос для SDCC так:
Код: "C"
#define __COPYREC(d, s, n) memcpy((char*)(d),(char*)(s),n)
А для остальных компиляторов так:
Код: "C"
#define __COPYREC(d, s, n) d=s

Закоммитил

Да, согласен. И, вообще, вся эта тема возникла из-за недоработки SDCC. Если ее пофиксят, то и необходимость в трюках с присвоением записей отпадет.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 10 май 2016, 22:54 
Не в сети
Аватара пользователя

Сообщения: 843
Откуда: Днепропетровская обл.
Пришлось откатить модификацию с __COPYREC и изменёнными __GUARDEQR/__GUARDEQP из-за некоторых проблем этого решения. Пока (до исправления в SDCC) предлагаю оформлять подобное присваивание так:
Код: "OBERON"
  1. MODULE AsgnRec; (*$MAIN*)
  2. IMPORT SYSTEM;
  3.  
  4. TYPE
  5. Card = RECORD suit, rank: INTEGER END;
  6.  
  7. VAR
  8. a, b: Card;
  9.  
  10. BEGIN
  11. IF SIZE(SHORTINT) # 1 THEN
  12. a := b; (* error 48: cannot assign values to aggregates *)
  13. ELSE
  14. SYSTEM.MOVE(SYSTEM.ADR(b), SYSTEM.ADR(a), SIZE(Card));
  15. END;
  16. END AsgnRec.

Для платформ с таргетом SDCC (с размером типа SHORTINT в 1 байт) будет использовано системное копирование записи, которое на Си выглядит так:
Код: "C"
__MOVE((INTEGER)&AsgnRec_b, (INTEGER)&AsgnRec_a, 4);

Олежек, извини, но мне кажется, так будет правильнее. Лучше опять напомнить разработчикам SDCC об этой проблеме. Филипп Краузе, с которым я общаюсь, правда, говорил, что это надо фиксить во фронт-энде, а он туда не лезет.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 12 май 2016, 21:11 
Не в сети
Администратор
Аватара пользователя

Сообщения: 237
Откуда: Россия
Модификация __COPYREC предлагалась только для обхода ошибки SDCC по копированию записей. И самое лучшее ,если разработчики SDCC свою ошибку исправили бы. А если __COPYREC исправляет одну ошибку, но порождает другую, то действительно лучше эту модификацию убрать и использовать другие средства обхода. А вот если мы выясним, в чем именно проблема с __COPYREC, а в SDCC к тому времени ошибку не исправят, то можно будет к этому средству вернуться.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 13 май 2016, 10:14 
Не в сети
Аватара пользователя

Сообщения: 843
Откуда: Днепропетровская обл.
Согласен. Всё осталось в репозитории, легко вернуться.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 22 июн 2016, 08:22 
Не в сети
Администратор
Аватара пользователя

Сообщения: 237
Откуда: Россия
Вроде бы нашел в чем проблема с __COPYREC. Проблема выявилась с компиляцией node^.conval^ := obj^.conval^ из OfrontOPB
Код: "C"
 
__COPYREC(__GUARDEQP(node->conval, OfrontOPT_ConstDesc), *obj->conval, 24);
означает
Код: "C"
    __GUARDEQP(node->conval, OfrontOPT_ConstDesc)=*obj->conval
Здесь нет лишнего разыменования, здесь два разыменования -> и * в каждой из частей оператора присваивания:
Код: "C"
 if(__TYPEOF(node->conval)!=OfrontOPT_ConstDesc__typ)__HALT(-6);*(node->conval)=*obj->conval

У операции "->" приоритет выше ,чем у *, поэтому "*obj->conval" означает "*(obj->conval)". Это соответствует обероновскому node^.conval^ := obj^.conval^ из исходника, где тоже 2 разыменования слева и два справа.
Проблема не в лишних звездочках, а в том, что __HALT(n) это функция с типом значения void. Поэтому в новых макросах
Код: "C"
    #define __GUARDEQR(p, dyntyp, typ)	*((dyntyp!=typ##__typ)?__HALT(-6):p)
#define __GUARDEQP(p, typ) *((__TYPEOF(p)!=typ##__typ)?__HALT(-6):p)
производится попытка разыменовать void, что и вызывает сообщение об ошибке.

Предлагаю сменить макросы на
Код: "OBERON"
  1. #define __GUARDEQR(p, dyntyp, typ) *((dyntyp!=typ##__typ)?(__HALT(-6),p):p)
  2. #define __GUARDEQP(p, typ) *((__TYPEOF(p)!=typ##__typ)?(__HALT(-6),p):p)
тогда эта проблема должна пропасть. Правда тут есть небольшая избыточность кода, потому что компилятор генерирует лишнее ветвление и разыменование для p, хотя после HALT это и не имеет смысла. Но это избыточность небольшая.


Вернуться к началу
 Профиль  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 26 ]  На страницу Пред.  1, 2, 3

Часовой пояс: UTC + 2 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Тех.поддержка phpBB