Re: Компиляция Refal6 для Linux (commens on data striucrture


Subject: Re: Компиляция Refal6 для Linux (commens on data striucrture
From: Arkady Klimov (klark@bagirra.net)
Date: Thu Nov 01 2001 - 17:32:47 MSK


Посылаю ответ также в группу refal для архива, так как здесь содержится
полезная информация о структурах данных реализации Рефала-6 и
ее использовании на уровне С.

----- Original Message -----
From: <dmsidorov@mtu-net.ru>
To: Arkady Klimov <klark@bagirra.net>; Andrey Slepuhin <pooh@msu.ru>
Sent: Wednesday, October 31, 2001 9:30 PM
Subject: Re: Компиляция Refal6 для Linux

| On Sun, Oct 28, 2001 at 06:24:25PM +0300, Arkady Klimov wrote:
| > matherr - это, как говорят, callback-функция для перехвата арифметических ошибок
| > (типа деления на 0). Она должна иметь определенный заголовок.
| > Можете попробовать поставить тот, который тут написан (вероятно, нижний,
| > поскольку используется С, а не С++).
|
| On Mon, Oct 29, 2001 at 01:13:00PM +0300, Andrey Slepuhin wrote:
| > То есть использовать эту функцию не рекомендуется. Вместо этого
| > предлагается использовать стандартные механизмы обработки сигналов -
| > при исключительных ситуациях во время операций с плавающей точкой
| > вырабатывается сигнал SIGFPE.
|
| Замена в строке 252 _exception на exception позволила скомпилировать файл,
| но хотелось бы знать, что Вы думаете насчет предложения Andrey Slepuhin
| о перехвате сигнала ошибки арифметической операции вместо использования
| matherr? Насколько я понимаю, в DOS сигналов нет. Но, может, в компиляторах
| DOS есть функция назначения обработчиков сигналов signal, тогда какой у нее
| интерфейс?

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

|
| On Mon, Oct 29, 2001 at 01:13:00PM +0300, Andrey Slepuhin wrote:
| > > Сообщение об ошибке в rfarm.c совершенно непонятно:
| > >
| > > rfarm.c: In function `rf_cgetnumb':
| > > rfarm.c:289: Unable to generate reloads for:
| > > (insn 45 43 47 (parallel[
| > > (set (reg:SI 0 %eax)
| > > (fix:SI (fix:SF (reg/v:SF 0 %eax))))
| > > (clobber (mem:HI (plus:SI (reg:SI 6 %ebp)
| > > (const_int -2 [0xfffffffe])) 0))
| > > (clobber (mem:HI (plus:SI (reg:SI 6 %ebp)
| > > (const_int -4 [0xfffffffc])) 0))
| > > (clobber (mem:SI (plus:SI (reg:SI 6 %ebp)
| > > (const_int -8 [0xfffffff8])) 0))
| > > (clobber (scratch:HI))
| > > ] ) 145 {fix_truncsfsi2+1} (insn_list 92 (nil))
| > > (expr_list:REG_EQUIV (mem:SI (reg/v:SI 3 %ebx) 0)
| > > (expr_list:REG_DEAD (reg/v:SF 0 %eax)
| > > (expr_list:REG_UNUSED (scratch:HI)
| > > (nil)))))
| > > make: *** [rfarm.o] Error 1
| > >
| >
| > Здесь однозначно ошибка компилятора, который не смог справиться с перегрузкой
| > значений регистров (в силу малого их количества в x86 архитектуре). В качестве
| > воркэраунда вокруг таких ситуаций обычно достаточно немного потасовать код
| > функции, не меняя ее смысл. Хотя лично я посоветовал бы переходить на
| > gcc-3.0.2. По крайней мере многие вещи там сделаны идеологически намного более
| > правильно.
|
| Функция rf_cgetnumb оказалось весьма интересной. Посмотрев определения
| использованных в ней макросов IS_REF, IS_REAL, IS_SNUMB, CVAL, CTYPE
| CREF00 в refelem.h, я не понял, что они делают. Наверно, тут виновато
| мое плохое знание C, но каков смысл выражения типа
| int t = ((unsigned short) (unsigned) (cc))
| в отношении нетипизированной ссылки cc? Какое назначение у всех
| этих макросов и у rf_cgetnumb? Без этого непонятно, как ее нужно
| перекраивать, чтобы скормить компилятору.

Аргумент здесь - значение звена (терма) типа cvalue, которое представляет собой упакованное
в одно слово размеченное объединение, включающее указатели (скобки или символы ссылки),
числа, слова, литеры, ... .В качестве дискриминанта используются последние два бита, которые
в указателях на звено всегда нулевые. Отсюда мнемоника CREF00 - взять (из cvalue) значение указателя,
с обнулением младших двух битов. Вышенаписанное выражение, похоже, использовано для
извлечения младшей (содержащей тег) двухбайтной части значение (CTYPE(cc)).
Функция rf_getnumb проверяет, что терм есть символ-число
и вырабатывает значение этого числа (типа long, то есть с усечением до 32-разрядов). Применяется
в системе обычно для извлечения значений, которые заведомо невелики - номера каналов,
индексы элементов и т.п.
elemptr p - указатель на звено (типа elem или elemstr), содержащее 32-разрядное значение info
и пару ссылок вперед и назад.
DATA(p) выдает значение info, типизированное как cvalue.
Абстрактно, значение cvalue состоит из типа и собственно значения.
TYPE(p), CTYPE(c) выдают типовую часть t значения в виде short.
Перечисленные макросы вида IS_...(t) служат для распознания категорий символов, запакованных
в значении.
VAL(p), CVAL(c) выдает само значение в виде short, при условии, что оно туда помещается
(например, короткое целое - IS_SNUMB).
Более крупные значения извлекаются специфическими макросами, типа CREF00, SWDBODY,
или функциями, типа rf_cgetnumb.
Важно заметить, что система допускает генерацию с несколькими различными вариантами
представления звена и адреса звена, поэтому, чтобы не нарушить этого свойства, ковыряться
в звеньях нужно только через упомянутые макросы и функции. К сожалению, компилятор С
не защищает от ошибок в этом деле. Фактическое расположение частей значения зависит
также от архитектуры компьютера - big endian или little endian.

Обращаю внимание, что большие числа с произвольной разрядностью представляются
в системе как массивы коротких 16-разрядных чисел (short) - макроцифр: x[0]- младшая часть,
x[l-1] - знак (0 или -1), где l- длина массива (l>=1). Учитывая зависимость от архитектуры,
следует заметить, что пара младших макроцифр не обязательно образует вместе
младшую часть типа long, но ее всегда можно получить выражением x[1]<<16+x[0], которое
и используется при реализации функции rf_cgetnumb (для длинных чисел).

Аркадий

|
| Дмитрий



This archive was generated by hypermail 2b25 : Mon Oct 25 2004 - 21:24:59 MSD