nedoPC.org

Чего-то не могу тут на форуме найти свои мысли на тему программирования на Си для троичного компьютера, которые я изложил в 2008 году - вобщем создаю новый топик
Короче что изменится для программиста при использовании языка Си для троичного компьютера?
Да собственно ничего не изменится - разве что INT_MIN и INT_MAX будут другими (обычные типы данных char, short, int, long, long long, а также float и double будут охватывать чуть более широкие диапазоны)
Трюки беззнаковой арифметики перестанут работать (и вообще любые трюки с переполнениями - но при желании их можно сымитировать программно) - скорее всего char и unsigned char будут представлять один и тот же 6-тритный тип данных, а int для начала может быть 12-тритным
Для троичных сдвигов можно завести новые операторы <<< и >>> которые будут реализованы аппаратно, в отличие от двоичных << и >> которые будут заменяться при компиляции на *2^n и /2^n соответственно
А если надо будет иметь потритные операции, то видимо надо создавать какие-то макросы

P.S. Вот нашёл где обсуждали по английски: http://www.nedopc.org/forum/viewtopic.php?f=62&t=97

char / unsigned char -> 6 тритов (трайт)
short / unsigned short -> 12 тритов (трорд)
int / unsigned int для начала может быть равен short, как в старых 16-битных компиляторах
для представления 32-битного целого достаточно было бы 21 трита, хоть это и не кругло
а 64-битное целое (long long) влезет в 41 трит, но видимо надо будет брать 24 трита и 48 тритов соответственно (для единообразия)

P.S. с другой стороны можно сразу сделать int 24-тритным, а long 48-тритным (равным long long как в современных 64-битных компиляторах)

Зачем это надо? А затем, чтобы можно было существующие программы компилировать под троичный процессор без существенной переделки (в идеале - вообще без переделки)

Ну "вообще без переделки" однозначно не получится - тогда все прелести, привнесенные троичностью,
не имеют никакого эффекта.

Ничто из стандарта не является невыполнимым на абстрактном троичном компе. Не забываем только нюансы типа того, что инт это минимум 16 бит, и при этом такого размера, манипуляции с которым являются самыми быстрыми на данной архитектуре

Кстати, начиная с этого года стандарт-таки предписал дополнительный код для хранения знаковых целых (но оставил переполнение UB ).

Для "эффекта" надо писать троичные программы с нуля

Ну и потом арифметика ведь будет идти через троичное АЛУ - так что кое какие прелести таки будут "автоматически"

Совершенно не надо! Троичные "прелести" просто позволят сократить существующие программы.

Этого никто не заметит. Для рядового пользователя как складывались числа (или вычитались) - так оно и будет.
А дополнительные фишки троичности не будут доступны из существующих программ - их же там не было!

Вот нашёл где обсуждали по английски: http://www.nedopc.org/forum/viewtopic.php?f=62&t=97

Также вставил линк в первый пост

Остается вопрос с побитовыми операциями...

Это что же, на чистой магии интерпретации, какие-нибудь двоичные 32х разрядные инты ПОБИТОВО переводить в троичные лонги(чтоб разрядов хватило) имеющие в разряде только -1 и 1, и применять логические потритовые операции? Но тогда мы не сможем совершать побитовые операции над двоичными лонгами, так как не хватает троичного целочисленного типа с количеством разрядов покрывающим этот лонг.

Или городить какие нибудь сложные структуры данных с булевыми массивами и циклами... И это я уже в ООП укатился...

Ну двоичные сдвиги будут выполняться через умножение на 2 и деление на 2

Это лучше делать как сумму с самим числом.

А вот тут так просто не получится...

А зачем вобще нам ДВОИЧНЫЕ сдвиги?

Многие программы их используют - если мы хотим полной переносимости, то надо поддержать

А вот кстати про маскирование битов и битовые поля я как-то не подумал

У нас ведь будут "тритовые" поля, которые будут маскироваться вовсе не побитовым AND (который в троичном мире есть MIN), а логическим троичным умножением MUL (см. подробнее тут). По-видимому надо иметь тип данных, который будет покрывать 32-позиционное битово-тритовое поле - по видимому это будет 48-тритовое слово - и все битовые константы из переносимой программы (если они там будут) надо "преобразовать" в троичный вид на уровне компиляции...

Автор Тунгуски сделал себе си-подобный компилятор 3CC, в котором он ушёл несколько в сторону:


Ну допустим с появлением оператора знака я согласен, но вот в остальном - например он убрал сдвиги вовсе, посчитав что теперь можно использовать умножение и деление на степень тройки, добавил универсальную операцию задаваемую 6 тритами (см. FFUUTT-code), а также изменил то, как работают сравнения. По мне так последние совсем-совсем не логично - сравнение должно сравнивать, выдавая ок или неок, т.е. никакого третьего в данном случае не дано!

Обычное условие if-else выполняет блок else, если выражение возвращает 0, и выполняет блок if, если выражение возвращает что-то другое - наверное так и надо оставить по умолчанию. Однако наверное можно добавить вариант "троичного" if-а, когда у нас не 2, а 3 блока:
На самом деле ровно того же самого можно достичь с помощью использования switch с оператором знака:
но оно выглядит немного тяжеловато...

Ну и наряду с тройственным оператором надо будет завести "четвёрственный"

expression???negative:neutral:positive

P.S. Ещё один возможный вариант 3-блочного if:
И наверное надо разрешить else, объединяющий 2 оставшихся условия:
При этом обычный сишный if-else наверное также будет допустим:


P.P.S. Возможно вместо "четвёрственного" оператора надо прям этот новый if и использовать в выражениях (как например давно делается с if-then-else в некоторых функциональных языках):
(тут я подсократил positive/neutral/negative т.к. длинновато выглядит, если без сокращений писать)

P.P.P.S. А для троичных сравнений, которые возвращают больше-равно-меньше, можно просто использовать вычитание