wide-char
|
|
|
1
2
|
|
Привет,
На cvs ветка wide-char в src. Буду пытаться там сделать 2-байтные символы. На сейчас оно ещё даже не компилируется корректно. Вываливается на этапе подключения src\done.f PS Переключиться на ветку - cvs up -r wide-char Переключиться на trunk - cvs up -A -- ~ygrek ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Spf-dev mailing list Spf-dev@... https://lists.sourceforge.net/lists/listinfo/spf-dev |
||||||||
attachment0 (196 bytes)
|
|
||||||||
|
In reply to this post by ygrek-3
|
||||||||
|
|
|
||||||||
|
|
On Mon, 28 Jan 2008 14:01:46 +0300
Dmitry Yakimov <ftech@...> wrote: > Andrey Cherezov wrote: > > Добрый день, ygrek! > > > > По wide-char у Кости Тарасова большой опыт (т.е. на WinCE всё только в > > юникоде). > > > > Ваше сообщение от 27.01.2008 17:39: > > > >> На cvs ветка wide-char в src. Буду пытаться там сделать > >> 2-байтные символы. На сейчас оно ещё даже не компилируется корректно. > >> > > В принципе сложного там ничего быть не должно. > Добавить L" и вызов апи на W в конце переделать. CHARS будет умножать на > два. Ну и напильником это все :) ------------------------- Система работает, понимает ввод из консоли и подгружает файлы. Некоторые либы работают сразу, многие надо CHAR-корректировать. tester.f не проходится, потому что я ошибочно реализовал в counted строках один _байт_ под длину, а там один символ таки должен быть - исправлю. Макрооптимизатор работает (заменил все C слова на B). Почему это было не так просто сделать. - Во время сборки используются словари инструментальной и целевой системы вперемешку. Словарная статья меняется - байт NFA (кстати может тоже сделать два байта, как в counted строках?). Я это обошёл (с третей попытки) расширением SEARCH-WORDLIST инструментальной системы, так что в TC-WL списке слов используется свой поисковик который знает про эту особенность. Из-за этого компилируется сейчас только с помощью spf4, где SEARCH-WORDLIST - вектор. - Много ассемблерных примитивов работающих со строками, как результат пришлось их все условно компилировать WIDE-CHAR'ами. Некоторые временно (?) представлены форт-эквивалентами. - Напильником тоже хорошо поработать пришлось, но в многих местах были уже расставлены CHARS что было очень замечательно :) Общая картина ------------------- В продолжение дискуссии SPF5 strings [1]. Документы просмотрел по диагонали, но с общим выводом не согласен (не читал, но осуждаю :) ). По-моему в этом месте лучше следовать стандарту - байты это байты, а символы это символы. Считать длину строк в символах. Аргумент про то что utf8 не вписывается в эту картину - не принимается, по той причине что оперировать utf8 в памяти неудобно и расточительно по времени. utf8 не надо приводить к этому интерфейсу (CHAR+ CHAR- CHARS etc), а только фиксированные строки. А utf8 испольузуется обычно для ввода/вывода, общения системы с внешним миром. Т.е. я вижу так : - внутри - все строки широкие двух-байтные - в слова чтения/записи в консоль и подключения файлов добавляется вектор который отвечает за перекодировку. Да, файлы из внешнего мира никому ничего не должны и не обязаны быть в cp1251 :). Этот вектор обобщает ANSI><OEM. Или лучше два вектора - один для текущего ввода, один для вывода. Этот вектор должен уметь преобразовывать разные по длине варианты кодирования. В ядре же только минимальный - тождественное преобразование. - S" выбирает строку из внутреннего буфера, где она уже в двух-байтном виде, т.е. определяется преобразованием с помощью вектора ввода/вывода. Для случаев когда нужен однобайтный массив символов (это не строка!) - отдельное слово - например B" которое обрезает каждый символ из буфера до байта. - Вызовы АПИ - TWINAPI: CharLower смотрит чтобы слово было в dll-ке в двух вариантах - CharLowerA и CharLowerW (если нет - ошибка) и в зависимости от WIDE-CHAR подключает нужный вариант. Если надо чётко указать какую функцию использовать - WINAPI: Кривости ANS ----------------- Первый и самый неприятный - WRITE-FILE и другие файловые слова работают с символами, а не с байтами. ИМХО в ядре надо делать файловые операции байтовые - согласен с [1]. Нет примитивных слов для работы с байтами, только с символами. В wide-char для этого введены слова B@ B! B, (~pinka/lib/ext/basics.f). Предлагаю их считать частью минимального ядра (внести сейчас в основную ветку) и использовать сейчас и в однобайтном коде. Для многих слов нет байт-эквивалентов, например FILL COMPARE SEARCH, а в существующем коде они вполне используются для байт массивов... Грядут перемены --------------------- Что можно/нужно делать сейчас (и в однобайтной версии). Различать использование B@ и C@ и применять. Использовать CHARS - думать о символах как об абстрактных единицах данных, а не "один символ - один байт)". Не использовать COUNT для прохождения по массиву _байт_ Проверить подозрительные места - 2DUP *CHARS* + COUNT *CHARS* + *CHARS* OVER + SWAP ?DO все C@ проверить на предмет того что это именно исмвол, а не байт ( кстати тесткейсы в этом здорово помогают :) - been there, done that ) Литература -------------- [1] http://www.nabble.com/SPF5-strings-td12350159.html -- ~ygrek ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Spf-dev mailing list Spf-dev@... https://lists.sourceforge.net/lists/listinfo/spf-dev |
||||||||
|
|
In reply to this post by ygrek-3
Привет,
Опции в spf_compileoptions,f добавлены - WIDE-CHAR собственно включает широкие символы. UNIX-ENVIRONMENT - определяет какой режим LT LTL будет по умолчанию в новой системе, (т.к. во время компиляции вызывается уже новая полуготовая система которая подгружает файл - эта опция позволяет без правки исходников собирать под wine-ом - иначе приходилось перед S" src\done.f" INCLUDED делать UNIX-LINES). Кстати насчёт опций может имеет смысл сделать так же как и spf4.ini - ini-шку для опций - которая не будет лежать в cvs - чтобы можно было локально править как вздумается? -- ~ygrek ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Spf-dev mailing list Spf-dev@... https://lists.sourceforge.net/lists/listinfo/spf-dev |
||||||||
|
In reply to this post by ygrek-3
|
||||||||
|
In reply to this post by ygrek-3
|
||||||||
|
|
On Mon, 4 Feb 2008 23:53:31 -0800 (PST)
azekeProfit <azekeprofit@...> wrote: > > В src/compiler/spf_compile.f : > > : S", ( addr u -- ) > \ Разместить в пространстве данных строку, заданную addr u, > \ в виде строки со счетчиком. > DUP B, S, > ; > > и в src/noopt.f : > > : INLINE, > BEGIN COUNT DUP C3 <> > WHILE B, > REPEAT 2DROP ; > > То есть, это я так понимаю что (аналог на форте текущего асмового ядрёного > слова): > > : COUNT ( c-addr1 -- c-addr2 u ) DUP B@ SWAP 1+ SWAP ; > > так и будет? Или "не всё сразу"? И один из мотивов сохранения такого -- > нежеление/муторность менять структуру словарной статьи? counted строках отводится символ. Исправлю. Насчёт словарной статьи - навернео поменять не так просто будет - но это и необязательно - никто ведь не обещал что NFA это counted строка. > NB Кстати, этот COUNT можно заменить на фортовский (на тот что выше при > сохранении текущего положения дел или на CHAR-aware вариант). Оптимизатор > там делает маш. код по размеру таким же, а скорость -- лишь чуть хуже (в > ручном асм-коде out-of-order execution применён). ASCIIZ> кстати тоже фортовая версия не сильно проигрывает. Если применить трюк - использовать @ 0xFFFF AND, а не C@ т.к. похоже MOVZX медленная команда. -- ~ygrek ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Spf-dev mailing list Spf-dev@... https://lists.sourceforge.net/lists/listinfo/spf-dev |
||||||||
|
|
|
||||||||
|
|
In reply to this post by ygrek-3
|
||||||||
|
|
|
||||||||
|
|
On Tue, 5 Feb 2008 23:46:50 -0800 (PST)
azekeProfit <azekeprofit@...> wrote: > > Трюк использовать нельзя, на ARM будет AV data misalignment. > > Не только. На заурядном x86 при взятой из кучи памяти с невыровненным > размером, можно получить отказ доступа при попытке взять торчащие последние > 3-1 байта (не говоря уже о штрафах за невыровненность). : asciiz> ( c-addr -- c-addr u ) DUP BEGIN DUP 3 AND WHILE DUP C@ 0= IF OVER - >CHARS EXIT THEN CHAR+ REPEAT BEGIN DUP @ DUP 0xFF AND 0= IF DROP OVER - >CHARS EXIT THEN 8 RSHIFT DUP 0xFF AND 0= IF DROP CHAR+ OVER - >CHARS EXIT THEN 8 RSHIFT DUP 0xFF AND 0= IF DROP 2 CHARS + OVER - >CHARS EXIT THEN 8 RSHIFT 0xFF AND 0= IF 3 CHARS + OVER - >CHARS EXIT THEN CELL + AGAIN ; вот такой вот вариант на 20% быстрее перебора в лоб :) и если считать что менеджер памяти даёт куски с гранулярностью больше 4 байт (а это так) то AV не должно быть. ЗЫ COUNT исправил, пришлось в tc перенести ещё и HIDE/SMUDGE -- ~ygrek ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Spf-dev mailing list Spf-dev@... https://lists.sourceforge.net/lists/listinfo/spf-dev |
||||||||
|
|
|
||||||||
|
In reply to this post by ygrek-3
|
||||||||
|
In reply to this post by Andrey Cherezov
|
||||||||
|
|
In reply to this post by Andrey Cherezov
On Thu, 07 Feb 2008 01:30:44 +0200
Andrey Cherezov <andrey@...> wrote: > Зато на 400% некрасивее, чем в лоб. И где гарантия, что это оптимальнее > на всех > существующих и будущих процессорах? Может стоить оставить такие > редкоиспользуемые > С-интерфейсные функции неоптимальными? Жалко твоего времени, чесслово :) Я ни в коей мере не собирался такого монстра пихать в ядро :) -- ~ygrek ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Spf-dev mailing list Spf-dev@... https://lists.sourceforge.net/lists/listinfo/spf-dev |
||||||||
|
|
|