[lisp]32 разряда, int64

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

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

      ,`""',
      ;' ` ;
      ;`,',;
      ;' ` ;
 ,,,  ;`,',;
;,` ; ;' ` ;   ,',
;`,'; ;`,',;  ;,' ;
;',`; ;` ' ; ;`'`';
;` '',''` `,',`',;
 `''`'; ', ;`'`'
      ;' `';
      ;` ' ;
      ;' `';
      ;` ' ;
      ; ',';
      ;,' ';

Не уверен, что это проще, ведь получится в итоге bignum. Ладно, пошаманю при случае, сейчас некогда.

Представить как массив из двух 32-разрядных слов, считать каждое слово отдельно, вычислить, сколько это будет всего - так ведь получится?

Да, так и следует поступить. Хотя в одном из релизов lispworks (у вас ведь он, если я правильно понял) появилась частичная поддержка int64. Возможно, в CFFI эта поддержка уже есть, и ничего хитрого делать не придется; но если нет, то можно отписаться разработчикам CFFI - возможно, у них уже есть какое-нибудь решение.

Если вы используете cl-sqlite, то там надо доопределить всего 3 функции: sqlite3-column-int64, sqlite3-bind-int64 и sqlite3-last-insert-rowid (если вы это сделаете и решите поделиться, то с благодарностью приму патч). В принципе, можно даже не использовать сишную библиотеку-обертку, а напрямую использовать lispworks'овское FFI (там оно называется FLI)

int64_t, не?

ой, извиняюсь не увидел тег ЛИСП.

И эти люди нам говорят что лисп готов для десктопа?

> И эти люди нам говорят что лисп готов для десктопа?

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

>И эти люди нам говорят что лисп готов для десктопа?

Успокойтесь. Человек пользуется нетрадиционной реализацией лиспа, у которой есть вот такие вот проблемы. Почему он не использует православный SBCL — это, конечно, вопрос.

— Foreign Type: :int8
— Foreign Type: :uint8
— Foreign Type: :int16
— Foreign Type: :uint16
— Foreign Type: :int32
— Foreign Type: :uint32
— Foreign Type: :int64
— Foreign Type: :uint64

Foreign integer types of specific sizes, corresponding to the C types defined in stdint.h.

CFFI User Manual / Built-In Types

Это если нужно для FFI. Если же говорить о родных примитивах - на 64-битной машине fixnum и так 64-битный. А на 32-битной естественнее использовать bignum - это и так массив 32-битных чисел, так что если что-то будет укладываться в 64 бита, то будет представлено как два 32-битных числа, и соответсвующие арифметические операции будут производится с этими частями (также как uint64_t на 32-битной машине обсчитывается по чатсям).

> . А на 32-битной естественнее использовать bignum … если что-то будет укладываться в 64 бита, то будет представлено как два 32-битных числа, и соответсвующие арифметические операции будут производится с этими частями


Угу, и результат ( + INT64_T_MAX INT64_T_MAX) в них радостно уложится?

Угу, и результат ( + INT64_T_MAX INT64_T_MAX) в них радостно уложится?

Нет, там не арифметика по модулю, там натуральная арифметика. Т.е. обычный алгоритм для больших чисел (динамический). Суть в том, что то что делается в gcc для эмуляции uint64_t (на 32 битах) или uint128_t (на 64) примерно соответствует тому что делается при работе с большими числами. Качественно, конечно, - в одном случае вызывается алгоритм, в другом происходит emit инструкций. Так что понятно, что можно было бы потребовать ещё оптимизаций на тему преобразований:

1 -> 1 -> 2
2 -> 2 -> 4
4 -> 4 -> 8

a -> b -> c
a, b - длинна больших чисел аргументов
с - длинна большого числа результата

не в вызов этого алгоритма (generic-{+|-|...}) а в emit ассемблерных инструкций. Примитив для большого числа имеет поле length, соответственно при наличии деклараций ([un]signed-byte {64|128|256}) можно такое делать - по крайней мере в SBCL этого не делается.

Но это, согласитесь, частности касающиеся работы компилятора. При наличии в языке bignum особого смысла в разных числах фиксированной размерности нет - только fixnum как тип для машинного слова (ну и для FFI, что есть в CFFI). Все остальные типы, вроде (integer 5 7), это уже на тему бронирования кода (assertion).

> но в моём лиспе нет int64.

Если это lispworks 6.0.х, то вроде как-бы есть поддержка:

from readme-6-0.txt:

13.9.6.2 ISO C99 types New foreign types are defined for integers of particular sizes. These are equivalent to the types defined by ISO C99. For example, Lisp :uint8 is C99 uint8_t. The new foreign types are:

:int8 8-bit signed integer :uint8 8-bit unsigned integer :int16 16-bit signed integer :uint16 16-bit unsigned integer :int32 32-bit signed integer :uint32 32-bit unsigned integer :int64 64-bit signed integer :uint64 64-bit unsigned integer :intmax largest type of signed integer available :uintmax largest type of unsigned integer available :intptr signed integer the same size as a pointer :uintptr unsigned integer the same size as a pointer

это был lispworks 6.0 32bit

also

13.9.1 Using arbitrary Lisp integers in the FLI

A new mechanism allows you to convert any Lisp integer into a foreign array of bytes and to convert that array back to an equivalent Lisp integer. This would allow the integer to be stored in and retrieved from a database, for example.

See the section «Lisp Integers», the macro fli:with-integer-bytes and the functions fli:convert-integer-to-dynamic-foreign-object and fli:make-integer-from-bytes in the LispWorks Foreign Language Interface User Guide and Reference Manual

> Почему он не использует православный SBCL — это, конечно, вопрос.
А что, SBCL под офтопиком уже нормально работает в SLIME и с тредами?

>А что, SBCL под офтопиком уже нормально работает в SLIME и с тредами?

Да. Только пока не в официальной версии.

> Только пока не в официальной версии.
Мммм. Звучит не слишком обнадёживающие. Я, пожалуй, подожду ещё.