Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Пт мар 29, 2024 09:14

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 28 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Лилипутия и Блефуску, прикладная задачка ...
СообщениеДобавлено: Ср ноя 07, 2007 10:09 
Не в сети

Зарегистрирован: Пн окт 15, 2007 17:24
Сообщения: 164
Откуда: Бийск
Благодарил (а): 0 раз.
Поблагодарили: 2 раз.
Данные из разных источников приходится обрабатывать, поэтому возникают такие задачи:

1) В памяти находятся 16-тиразрядные целые числа со знаком в big-endian кодировке.
Необходимо реализовать аналоги операций "@", "!" и "+!", таким образом чтобы аргумент на стеке был
целым знаковым для 32-х разрядного форта, функционирующего на системе, где числа хранятся в little-endian кодировке.

2) Перекодировать big-endian > little-endian и обратно в 32-хразрядном форте:
a) одно значение на стеке данных
б) массив в памяти
i) 16-разрядных значений
ii) 32-разрядных значений

Критерий качества решения - быстродействие.

_________________
And so forth ...


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср ноя 07, 2007 13:34 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 13:19
Сообщения: 3565
Откуда: St.Petersburg
Благодарил (а): 4 раз.
Поблагодарили: 72 раз.
Варнак писал(а):
Перекодировать big-endian > little-endian


Oй, а можно объяснить по-русски для темных чайников, что это за кодировки такие?
А то у меня и предположений на счет этих "яиц" не появилось.

_________________
С уважением, WingLion
Forth-CPU . RuF09WE
Мой Форт
Отсутствие бана это не заслуга юзера, а недоработка модератора (с)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср ноя 07, 2007 13:38 
Не в сети

Зарегистрирован: Вт май 09, 2006 12:31
Сообщения: 3438
Благодарил (а): 5 раз.
Поблагодарили: 16 раз.
да-да, и как они выглядят в цифрах

_________________
понимаю некоторую бестолковость некоторых вопросов


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср ноя 07, 2007 13:48 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
Число 0x12345678 может лежать в памяти либо как 0x12345678 либо как 0x78563412. То есть либо "младший адрес - младший байт", либо "младший адрес - старший байт". Разница как между остроконечниками и тупоконечниками - то есть дело вкуса.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср ноя 07, 2007 14:02 
Не в сети

Зарегистрирован: Пн окт 15, 2007 17:24
Сообщения: 164
Откуда: Бийск
Благодарил (а): 0 раз.
Поблагодарили: 2 раз.
Хищник писал(а):
Число 0x12345678 может лежать в памяти либо как 0x12345678 либо как 0x78563412. То есть либо "младший адрес - младший байт", либо "младший адрес - старший байт". Разница как между остроконечниками и тупоконечниками - то есть дело вкуса.

Ну, не совсем вкуса (хотя решение проектировщиками когда-то принималось именно на уровне вкуса), т.к. x86, например, процессоры делают арифметику с данными в памяти исходя из того, что младший байт числа лежит по младшему адресу (little-endian), а, скажем, моторолловские - наоборот (big-endian). Форт, хотя бы при реализации @ и !, неявно эти соглашения должен учитывать.

И когда считан в память файл с числовыми данными, сохраненными в другом формате, то перед вычислениями приходится их преобразовывать. Данных много - преобразовывать надо быстро, либо заранее в массиве, либо перед вычислением на стеке. Когда и как именно лучше - пока неясно.

_________________
And so forth ...


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

Зарегистрирован: Вт май 02, 2006 13:19
Сообщения: 3565
Откуда: St.Petersburg
Благодарил (а): 4 раз.
Поблагодарили: 72 раз.
хм... в таком случае, самое быстрое преобразование должно быть - железное...
Код:
xchg al,ah
rol eax,16
xchg al,ah

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

На форте мне как-то попадалось определение для слова
>< (NNMM -- MMNN) которое переставляет байты в 16-битном слове.
для 32битного тоже можно придумать название, ну, скажем...
: >><< >< SWAP >< ;
но это имеет смысл только 16-битном форте, в 32-хбитном слово >><< - надо определять на ассемблере или железно, если использовать форт-процессор

_________________
С уважением, WingLion
Forth-CPU . RuF09WE
Мой Форт
Отсутствие бана это не заслуга юзера, а недоработка модератора (с)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср ноя 07, 2007 16:03 
Не в сети

Зарегистрирован: Пн окт 15, 2007 17:24
Сообщения: 164
Откуда: Бийск
Благодарил (а): 0 раз.
Поблагодарили: 2 раз.
WingLion писал(а):
хм... в таком случае, самое быстрое преобразование должно быть - железное...
...
надо определять на ассемблере или железно, если использовать форт-процессор

Согласен. Железное или ассемблерное, конечно, самое быстрое, но если речь идет о переносимости, или использовании уже готового форт-процессора, то хотелось бы его определить как форт-слово.
А задача 1 из первого поста имеет и еще один нюанс - распространение знакового бита ... на ассемблере тоже очень просто.
Это я к тому, что распространенный в этой теме подход, когда при обсуждении решения задач на форте аргументом является "а на ассемблере лучше, а в железе еще лучше" кажется странным (именно в этой теме).
Хотя в промышленных задачах я тоже так поступал: пишем чтобы как-нибудь работало, анализируем результат и узкие места переписываем в машкодах ...

_________________
And so forth ...


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср ноя 07, 2007 16:54 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 13:19
Сообщения: 3565
Откуда: St.Petersburg
Благодарил (а): 4 раз.
Поблагодарили: 72 раз.
Варнак писал(а):
Критерий качества решения - быстродействие.


Варнак писал(а):
Это я к тому, что распространенный в этой теме подход, когда при обсуждении решения задач на форте аргументом является "а на ассемблере лучше, а в железе еще лучше" кажется странным (именно в этой теме).


Так все-таки, важнее быстро или на форте?

_________________
С уважением, WingLion
Forth-CPU . RuF09WE
Мой Форт
Отсутствие бана это не заслуга юзера, а недоработка модератора (с)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср ноя 07, 2007 17:02 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 13:19
Сообщения: 3565
Откуда: St.Petersburg
Благодарил (а): 4 раз.
Поблагодарили: 72 раз.
Варнак писал(а):
А задача 1 из первого поста имеет и еще один нюанс - распространение знакового бита ... на ассемблере тоже очень просто.


А вот это совсем не понятно. Распространение знакового бита нужно при преобразовании 8->16 или 16->32, а при перестановке порядка байт в числе - расположение знакового бита не должно меняться.
Разве что речь идет о такой переделке представления чисел с одного процессора на другой, что у знаковый бит в другом месте... Но тогда задача не имеет смысла без спецификации на процессоры.

_________________
С уважением, WingLion
Forth-CPU . RuF09WE
Мой Форт
Отсутствие бана это не заслуга юзера, а недоработка модератора (с)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср ноя 07, 2007 17:40 
Не в сети

Зарегистрирован: Вт май 09, 2006 12:31
Сообщения: 3438
Благодарил (а): 5 раз.
Поблагодарили: 16 раз.
Автор имеет ввиду, что в одном случае порядок битов внутри байтов остаётся, в другом - тоже меняется?
А где это

_________________
понимаю некоторую бестолковость некоторых вопросов


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Ср ноя 07, 2007 22:11 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
смотри ассемблерную команду BSWAP

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт ноя 08, 2007 00:27 
Не в сети

Зарегистрирован: Вт май 09, 2006 12:31
Сообщения: 3438
Благодарил (а): 5 раз.
Поблагодарили: 16 раз.
Посмотрел (для пентиума)
в качестве операнда может быть задан только 32-регистр :shock:
и так и не понл, куда девается знаковый бит :D :D :)

_________________
понимаю некоторую бестолковость некоторых вопросов


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт ноя 08, 2007 00:51 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
Варнак писал(а):
Ну, не совсем вкуса (хотя решение проектировщиками когда-то принималось именно на уровне вкуса), т.к. x86, например, процессоры делают арифметику с данными в памяти исходя из того, что младший байт числа лежит по младшему адресу (little-endian), а, скажем, моторолловские - наоборот (big-endian). Форт, хотя бы при реализации @ и !, неявно эти соглашения должен учитывать.

Оно потому и названо "остроконечным" и "тупоконечным" подходом, что очень сильно смахивает на проблему Лилипутии и Блефуску. Оба подхода имеют массу аргументов за и против, но по сути речь идет только о способе прокладки соединительных линий. Современным x86 вообще все равно, поскольку реальная физическая память видится через контроллер, и экономия ресурсов от "правильного" порядка байт составляет ничтожно малую величину.Я еще понимаю, когда 32-битное число надо протащить через 8-битный интерфейс, тут младшие байты могут уже начать складываться, формируя бит переноса. Но сейчас-то память 32, а то и 64-битная. А решение для контроллера чисто аппаратное

Код:
q(31 downto 24) <= d(7 downto 0);
q(23 downto 16) <= d(15 downto 8);
q(15 downto 8) <= d(23 downto 16);
q(7 downto 0) <= d(31 downto 24);


Что по сути представляет собой "перепутывание" проводников.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт ноя 08, 2007 08:57 
Хищник писал(а):
Код:
q(31 downto 24) <= d(7 downto 0);
q(23 downto 16) <= d(15 downto 8);
q(15 downto 8) <= d(23 downto 16);
q(7 downto 0) <= d(31 downto 24);


Что по сути представляет собой "перепутывание" проводников.


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

P.S. Но если сразу это дело не учесть, в Форт системе, то могут быть
определенные трудности, что и проявилось при переносе Форта
на другой CPU ( в моем случае)


Вернуться к началу
  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт ноя 08, 2007 10:36 
Не в сети

Зарегистрирован: Пн окт 15, 2007 17:24
Сообщения: 164
Откуда: Бийск
Благодарил (а): 0 раз.
Поблагодарили: 2 раз.
Цитата:
Так все-таки, важнее быстро или на форте?

Максимально быстро (это критерий), но на форте (это ограничение) ... :)
Понятно, что при для оптимизации придется конкретизировать форт, пока использую SPF.

Цитата:
в одном случае порядок битов внутри байтов остаётся, в другом - тоже меняется?

Цитата:
Распространение знакового бита нужно при преобразовании 8->16 или 16->32, а при перестановке порядка байт в числе - расположение знакового бита не должно меняться.

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

Цитата:
Но если сразу это дело не учесть, в Форт системе, то могут быть
определенные трудности, что и проявилось при переносе Форта
на другой CPU ( в моем случае)

У меня проявилось просто при обработке числовых данных берущихся из файла, подготовленного на другой системе (файлы читать по байтам будет совсем медленно).

_________________
And so forth ...


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

Часовой пояс: UTC + 3 часа [ Летнее время ]


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

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


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

cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB