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

...
Google Search
Forth-FAQ Spy Grafic

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




Начать новую тему Ответить на тему  [ Сообщений: 13 ] 
Автор Сообщение
 Заголовок сообщения: F:) как универсальная VFM
СообщениеДобавлено: Ср июл 12, 2006 21:56 
Не в сети

Зарегистрирован: Ср июл 12, 2006 21:41
Сообщения: 8
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
С вашего позволения (позволение Дмитрия уже есть) открою тему постом личного письма к нему:
__________________________________________________________
Добрый день, Дмитрий!

Так получилось, что наткнулся я на твой (ничего, что я на "ты" по старой
фидошной привычке? ;) ) проект F (нынче F:)). Я довольно давно знаком с
фортом, но серъезно его не использую - это что-то вроде одного из моих
многочисленных хобби. Он мне нравится, скорее, эстетически ;). Так вот. Мне
нравится твой энтузиазм и я даже немного им заразился (чуть не дошел до
грани написания варианта FVM для PalOS) ;) Но более внимательно изучив
материалы проекта несколько призадумался. Начал мететься между "напишу" и
"зачем это нужно". Позволь я поделюсь возникшими вопросами.
Как мне кажется существующая концепция FVM по большому счету не очень хорошо
ориентирована на другие (кроме ПиСи) архитектуры. Вообще не совсем понятно
на что она "заточена". Изначальное ориентирование на минимальные требования
(ч/б экран, 320*200 и т.д.) мне кажется не совсем верным. ИМХО, нужно сделать
что-то вроде таблицы (структуры) с описанием системной конфигурации, которая
возвращается конкретной FVM и видна из программы. В ней отражены такие
параметры системы, как размер экрана, глубина цвета, поддержка звука
(хрюкалка, миди, вав и т.д.), другая перефирия. Тогда программист сможет либо их учитывать и в
программе либо выдавать сообщение о недостаточной конфигурации. Более того,
может имеет смысл подобную конфигурацию хранить в неком заголовке файла с
кодом для FVM и функции неприятия кода возложить на саму FVM.
Второй момент "непереносимости" - 16/32. Аналогично имеет смысл в заголовек
файла с кодом для FVM хранить разрядность кода, а в функции FVM заложить
либо адаптацию под конкретную разрядность, либо неприятие этого кода.
Далее. Специфика архитектуры. В ПальмОС (да и в некоторых телефнах.
насколько я знаю) память делится на блоки по 64К. Для 16-разряных программ
это нормально, на как быть с данными. Например бмп и вав. В пальОС,
насколько я понял, выделяемый блок вне 64К блока не всегда кратен
какому-либо значению, а значит адревация в виде segment+offset не подойдет,
нужна "чисто" 32-разрядна адресация. При этом размер блока не может превышать 64К.
Следующие сомнения возникают по скорости. Например вывод бмп. В существующей
реализации это надо будет делать поточечно, в то время, как, например, в
ПалмОС уже есть функции для адаптивного вывода спрайта (причем не надо
заботится о разрядности цвета и размерах экрана - ОС сама выбирает нужный
спрайт из нескольких), а прямой вывод в экранный буфер как таковой
отсутствует (слишком много устройств с различной организацией экранной
памяти). Т.е. FVM в подобных вопросах даст заведомо "сильные" тормоза. А с
другой стороны расширение системы команд FVM тоже не бесконечно (надо будет
вводить префиксы и т.д.).
Следующее сомнение - язык. Очередной клон форта. Но не стандарт. Согласись,
что в этом есть существенные минусы (например с компиляцией сторонних
стандатных исходников).
Собственно на этом этапе я и стал на развилку. У меня для пальмы есть
dragon-forth (тяжелый, медленный, и не документированный, но зато
32-разрядный и бесплатный) и есть quartus-forth (16-разрядный с хорошей
поддержкой, шустрый (прямой код), но коммерческий). В обоих системах хорошая
инеграция с функциями ПальмОС, задач переносимости не стоит. Стоит ли делать
некую FVM, которая заведомо будет проигрывать по скорости и требует
"извратов" для организации ее рабочего пространства и не сможет на полную
катушку дать (пусть потенциальную) возможность использовать все ресурсы
ПальмОС (например IRDA и т.п.)?
Я понимаю, что FVM только в начале своего развития, но все равно...
изначальная концепция и продуманность, ИМХО, хромают. Не принимай на личный
счет, я и вправду восхищен твоим энтузиазмом и правда хочу, чтобы он дал
ощутимые плоды.
Да, еще позволь тебе дать пару советов (я ни в коем случае не хочу тебя этим
оскорбить) по реализации:
ИМХО мизер скорости даст, если вместо
T[task].delay=ms*CLK_TCK/1000; // save delay in clock ticks
T[task].start=clock(); // save current clock value
использовать
T[task].end=clock()+ms*CLK_TCK/1000;
И, соответствено вместо
if (clock()>T[t].start+T[t].delay)
использовать
if (clock()>T[t].end)

А вот если вмето case в процедуре step использовать что-то вроде (я не силен
в Си, поэтому приведу аналог на форте)
create Itable ' NOP , ' JMP , ' CALL , ... ' GR_XSZ ,
: STEP ( I -- ) CELLS Itable + @ execute ;
то скорость должна стать равномернее (хотя я не знаю как это компилится на
сях).

Да, еще. Может имеет смысл оптимизировать по размеру и ввести двухбайтные
команды? Например jmp и call в диапазоне +-127 байт?
Или даже sjmp+ и sjmp- c адресацие вперед и назад соответственно в диапазоне 256 шагов.
ИМХО для форта таких переходов будет много, а это сокращение размера части кода примерно на треть ;)

На самом деле много чего хотел сказать, но как-то все сумбурно получается.
Вот, например, размышления про устройства ввода:
Не везде есть клавиатура. Не везде есть мышка/тачпад.
Эмулировать? Внутри программы или внутри FVM?
Если посмотреть на многообразие современных устройств,
то можно условно выделить 3 вида устройств вода:
а) "джойстики" на наладонниках, некоторых телефонах и "стрелки" на PC-клавах (на старых пальмах - урезанные, но реализуемые);
б) цифровые клавиатуры (могут эмулировать "джойстик")на телефонах, PC и, возможно на некоторых экзотических моделях программируемых калькуляторов;
в) символьные клавиатуры на некоторых смартфонах и PC (иногда совмещенные с цифровыми);
г) "мышки" на PC (их можно эмулировать "джойстиком");
д) "тачпад" на наладонниках (от мышки отличается отсутствием видимого курсора и кнопок. Можно сказать, что в принципе они эдентичны).
Плюс почти у всех устройств есть некоторое количество, скажем так, "функциональных" клавиш.
К чему это я? К тому, что при программировании FVM лучше всего ориентироваться
на джойстик ( с учетом, что он же 2 4 6 8 на цифровой клавиатуре)
и мышку ( с учетом, что она же тачпад или джойстик),
а про "буковки" вспоминать лишь в крайнем случае
(в конце концов учитывать, что это может быть виртуальная клава,
графити, всякие Т9 или ввод букв а-ля "Дэнди").


С уважением,
Юрий Шаповалов.

______________________________________________________


Собственно народ!
Кто с какими симтемами "носимых устройств" знаком, какие у них ограничения и особенности и что, по вашему мнению, нужно сделать (и как это сделать) с F:), чтобы вывести его (ее? ;) ) на... на... Н у в общем, на хороший такой серьезный уровень? ;)


Uri


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

Зарегистрирован: Пт май 12, 2006 00:52
Сообщения: 88
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
Цитата:
Кто с какими симтемами "носимых устройств" знаком


Программировал под PVOS, знаком с PocketPC, имею общее представление о PalmOS.

Цитата:
какие у них ограничения и особенности


Это абсолютно разные системы. Аппаратно, архитектурно, на уровне процессора. Даже алгоритмические решения под них разные.

_________________
... чтобы понять рекурсию, нужно сперва понять рекурсию ...


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

Зарегистрирован: Ср июл 12, 2006 21:41
Сообщения: 8
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
[quote]
Это абсолютно разные системы. Аппаратно, архитектурно, на уровне процессора. Даже алгоритмические решения под них разные.[/quote]

Палм и Покет? Это понятно. Я имел в виду - какие проблемы возникнут при реализации FVM для того же покета и что нужно сделать, чтобы их решить без ущерба для других архитектур?

Кстати совсем забыл упомянуть еще одну особенность ПальмОС, как то, что она событино-ориенированная. Т.е. по идее проц пальмы "спит" до тех пор, поке не произойдет какое-либо событие (как то нажатие клавиши). Так что если в программе на FVM будут какие-либо "циклы ожидания" - для носимых устройств это может оказаться критичным если не в в плане реализации, то в плане энергосбережения.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Чт июл 13, 2006 12:44 
Не в сети
Аватара пользователя

Зарегистрирован: Пт май 12, 2006 00:52
Сообщения: 88
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
Цитата:
Я имел в виду - какие проблемы возникнут при реализации FVM для того же покета и что нужно сделать, чтобы их решить без ущерба для других архитектур?


FVM на низком уровне должна быть совершенно разной. Абсолютно. :)

Цитата:
Кстати совсем забыл упомянуть еще одну особенность ПальмОС, как то, что она событино-ориенированная. Т.е. по идее проц пальмы "спит" до тех пор, поке не произойдет какое-либо событие


Потому я и говорю, что машинки - идеологически разные.

Ближе всех к вашим привычкам PVOS. Ибо x86, классическая архитектура (сегменты кода, сегменты данных, обычная одноадачная работа процессора с вызовами системных функций ОС). В общем, к DOS - ближе всего.

PalmOS - совершенно непривычная среда исполненния.

PocketPC - совершенно непривычный ARM-процессор (32 РОН, отсутствие задаваемых в явном виде констант (константа - всегда часть опкода), возможность выполнения/невыполнения любой команды в зависимости от фоагов процессора и т.п.), хотя и привычный WinAPI.

_________________
... чтобы понять рекурсию, нужно сперва понять рекурсию ...


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

Зарегистрирован: Ср июл 12, 2006 21:41
Сообщения: 8
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
[b]FVM на низком уровне должна быть совершенно разной. Абсолютно. :)[/b]

И именно про это я и поднял тему ;)
Как обеспечить совместимость кода+данных для FVM для разных платформ?
На уровне кода - все более-менее понятно и прозрачно. А на уровне "донесения" кода до VFM конкретного устройства? Учет окружения (железа) конкретного устройства? И т.д.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пт июл 14, 2006 00:16 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
Мне кажется, что ВМ не должна сильно отличаться в зависимости от используемой операционной системы или процессора - на то она и ВМ.
А вот тот же цикл ввода-обработки сообщений будет другим, но это, согласитесь уже форт-система, а не виртуальная ФМ. Конечно возможны заморочки с адресацией памяти в процессоре, но это уже давно и многократно было решено, раз уж смогли сделать более-менее удобные форты под ту же гарвардскую модель8)


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

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


Мне всегда казалось, что гарвардская модель как раз удобнее во всех отношениях... :?


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

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


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


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

Зарегистрирован: Сб май 06, 2006 18:43
Сообщения: 400
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
oleg писал(а):
Хищник писал(а):
Мне всегда казалось, что гарвардская модель как раз удобнее во всех отношениях...


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


для Форта необходима возможность записи кода, а вот словарную структуру и переменные можно и в памяти данных прекрасно держать

_________________
http://akps.ssau.ru/forth/


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7960
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
oleg писал(а):
Форт по сути своей хранит код в области данных, или как хотите данные и код очень тесно друг с другом перемешаны, так что раздельное хранение данных и кода представляет некоторые неудобства. Ну и еще мне всегда казалось, что гораздо легче работать с плоской моделью памяти.


Модели памяти (фон-неймановская/гарвардская) в принципе слабо зависят от языка. Физическая организация шин - вопрос электроники. В память кода обычно тоже можно писать, но это будет в итоге медленнее, чем при раздельном доступе. От плоской модели сейчас как раз отходят (см. например Disable Execution Bit, который не дает "выполнить данные как код"). Наконец, аппаратный стек данных можно рассматривать как своего рода третье адресное пространство, доступ к которому возможен в то же самое время, что и к программе, и к данным.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: F:) как универсальная VFM
СообщениеДобавлено: Пт июл 14, 2006 20:55 
Не в сети

Зарегистрирован: Сб май 06, 2006 18:43
Сообщения: 400
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
добрался наконец до спокойного интернета

Цитата:
Я довольно давно знаком с
фортом, но серъезно его не использую - это что-то вроде одного из моих
многочисленных хобби. Он мне нравится, скорее, эстетически ;).


Мне -- абсолютно то же самое, и плюс избавиться от старой блажи написать Форт-ОС.

Цитата:
Так вот. Мне
нравится твой энтузиазм и я даже немного им заразился


где нашел энтузиазм ? скажи -- удалю, у меня по поводу Форта никакого энтузиазма давно нет, чистое хобби, типа наладки карбюраторных двигателей, написания стихов или выжигания по дереву

Цитата:
чуть не дошел до грани написания варианта FVM для PalOS :) Но более внимательно изучив
материалы проекта несколько призадумался. Начал мететься между "напишу" и "зачем это нужно".


если бы не метался, давно бы уже сделал

Цитата:
Как мне кажется существующая концепция FVM по большому счету не очень хорошо ориентирована на другие (кроме ПиСи) архитектуры.


вполне возможно, но реально это покажут только попытки портирования движка и проверки работы программ

Цитата:
Вообще не совсем понятно на что она "заточена".


встраиваемые системы (управляющие компьютеры встроенные в оборудование), портативные "бюджетные" (low-end ?)устройства

базовый набор команд (без пометок extension в исходниках) обязан работать на чем угодно с размером памяти от нескольких Кб (учитывая стеки)

расширения опциональны, я их ввел по необходимости для своих программ, но и набор команд расширений, и их семантика (поведение и передача данных) скорее всего поменяются при портировании на разные системы

Цитата:
Изначальное ориентирование на минимальные требования
(ч/б экран, 320*200 и т.д.) мне кажется не совсем верным.


согласен, размеры экрана очень завышены. типичное 64х128 (графические ЖКИ), 160х160 (старые палмы), и естественно текстовые 1-4 строчные ЖКИ (клинический случай -- просто отсутсвие вывода, ну и типовая терминалка на UART-порту)

Цитата:
ИМХО, нужно сделать
что-то вроде таблицы (структуры) с описанием системной конфигурации, которая
возвращается конкретной FVM и видна из программы. В ней отражены такие
параметры системы, как размер экрана, глубина цвета, поддержка звука
(хрюкалка, миди, вав и т.д.), другая перефирия.


это можно сделать в виде двухбайтных команд, первый байт из опкодов, например 0xEF, за ним следует второй опкод

но я специально зажал возможности но самого минимума, возможного на ПК под DOSом -- с одной строны, это не так далеко до ebedded железа, с другой -- легко запускается под любой современной ОС с минимальными телодвижениями (эмуляторов DOS сейчас полно)

Цитата:
Тогда программист сможет либо их учитывать и в
программе либо выдавать сообщение о недостаточной конфигурации.


вот именно этого я и хотел избежать -- если у кодера есть возможность использовать его Dual Xeon с Quanta FX 4500, фиг ты его заставишь сделать обрезанную версию программы, которая могла бы полноценно работать на старом Палме или ТВ-приставке

только кто ж запрещает взять мою версию за основу, и развить до несовместимости в нужном направлении ?

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

Цитата:
Более того,
может имеет смысл подобную конфигурацию хранить в неком заголовке файла с
кодом для FVM и функции неприятия кода возложить на саму FVM.


эта функция возлагается на того, кто не читает сопроводительную документацию к программам перед тем как скачивать, и на того удода, который ее не пишет

Цитата:
Второй момент "непереносимости" - 16/32.


с этим очень просто -- ко всем типам данных в сишных исходниках добавляется квалификатор short :)

если серьезно -- именно поэтому и появились два режима при запуске целевого компилятора, программно имитировать переполнение при имитации 16-битных операций мне показалось слишком сложно

Цитата:
Аналогично имеет смысл в заголовек
файла с кодом для FVM хранить разрядность кода, а в функции FVM заложить
либо адаптацию под конкретную разрядность, либо неприятие этого кода.


это получается автоматически -- при запуске с вероятностью 90% аварийно вылетаем из-за некорректного кода (неизвестные опкоды, убийство стека данных случаными командами), остальные 10% приходятся на случайную запись на data storage (файл MEDIA) ;)

Цитата:
Далее. Специфика архитектуры. В ПальмОС (да и в некоторых телефнах.
насколько я знаю) память делится на блоки по 64К.
Для 16-разряных программ
это нормально, на как быть с данными. Например бмп и вав.


самое веселое, если памяти вообще только 32К. ну и ?

для 16-битных систем с большй памятью hint: многозадачность будет поддерживать не только нити (общая память для всех задач), но и процессы (под каждую задачу выделяется своя память до 64К)

в этом случае программа просто делится на процессы

и кроме того -- есть старый добрый свап

еще у меня была задумка добавить возможность выделять блоки данных все адресного пространства форт-машины, и команды для блочного переноса данных туда/сюда в тч и со свапом, пока не понадобилось

_________________
http://akps.ssau.ru/forth/


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: F:) как универсальная VFM
СообщениеДобавлено: Пт июл 14, 2006 21:33 
Не в сети

Зарегистрирован: Сб май 06, 2006 18:43
Сообщения: 400
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
Цитата:
нужна "чисто" 32-разрядна адресация.


очень удобным может оказаться работа с блоками памяти вне адресного пространства форт-системы (такого я пока ни в одном Форте не видел), и операции как блочной пересылки между блоками, так и побайтного чтения/записи, и своппинг очень легко и прозрачно добавляется

Цитата:
Следующие сомнения возникают по скорости. Например вывод бмп. В существующей
реализации это надо будет делать поточечно, в то время, как, например, в
ПалмОС уже есть функции для адаптивного вывода спрайта


соласен, для спрайтов нужна поддержка на уровне ВМ, а в идеале и на уровне железа, если реальное железо (например Amiga) позволяет, особенно если превращать F:) в платформу для игровых программ в стиле игр для старых 8-битных компьютеров

Цитата:
(причем не надо
заботится о разрядности цвета и размерах экрана - ОС сама выбирает нужный спрайт из нескольких),


частный случай

Цитата:
а прямой вывод в экранный буфер как таковой
отсутствует (слишком много устройств с различной организацией экранной памяти).


тоже частный случай, контроллер ЖКИ вообще отдельное устройство с последовательным или малоразрядным параллельным интерфейсом и своей системой команд

Цитата:
Т.е. FVM в подобных вопросах даст заведомо "сильные" тормоза.


тормоза -- плата за переносимость, создание команды ВМ на каждый чих раздувает объем глубоко платформенно-зависимого кода и на порядок ухудшает портируемость и легкость чтения исходника

Цитата:
А с другой стороны расширение системы команд FVM тоже не бесконечно (надо будет вводить префиксы и т.д.).


так и должно быть, причем число префиксов (т.е. и полная длина команды) не ограничено

Цитата:
Следующее сомнение - язык. Очередной клон форта. Но не стандарт.


почему ? я всего лишь развил стандартный Форт до диалекта, на котором и пишу программы

вот то, что словари не использую -- да, на 100% нестандартно, и работает только в SPF

Цитата:
Согласись,
что в этом есть существенные минусы (например с компиляцией сторонних
стандатных исходников).


где они ?!! ну взял я тетрис для ANS терминала, подсовывал всем форт-системам, которые у меня были, результат -- "не знаю такого слова, иди нафиг" или просто вылетает с GPF

Цитата:
Стоит ли делать некую FVM, которая заведомо будет проигрывать по скорости


только если нужна реальная портабельность

Цитата:
и не сможет на полную
катушку дать (пусть потенциальную) возможность использовать все ресурсы ПальмОС (например IRDA и т.п.)?


принцип -- найти общую часть множеств всех возможностей, доступных на всех платформах, на которых есть желание запускать F:) ные программы

Цитата:
изначальная концепция и продуманность, ИМХО, хромают.


c этим не ко мне, а к http://www.sun.com

Цитата:
ИМХО мизер скорости даст, если вместо
Код:
     T[task].delay=ms*CLK_TCK/1000;          // save delay in clock ticks
     T[task].start=clock();                  // save current clock value
использовать
Код:
     T[task].end=clock()+ms*CLK_TCK/1000;
И, соответствено вместо
Код:
                         if (clock()>T[t].start+T[t].delay)
использовать
Код:
                         if (clock()>T[t].end)


другими словами -- не считать в каждой итерации цикла дельту, исправлю в ближайшее время

Цитата:
А вот если вмето case в процедуре step использовать что-то вроде


это называется jump table, массив указателей на функции, которые запускаются по их индексу

да, конечно это быстрее, но jump table не во всех языках можно реализовать без грязных хаков, поэтому я пожертвовал скоростью для читабельности теми, кто хочет ВМ написать не на си

кроме того, оптимизирующий компилятор говорят должен сам такие конструкции конвертировать в таблицы указателей

Цитата:
Да, еще. Может имеет смысл оптимизировать по размеру и ввести двухбайтные команды? Например jmp и call в диапазоне +-127 байт?


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

Цитата:
а) "джойстики" на наладонниках, некоторых телефонах и "стрелки" на PC-клавах (на старых пальмах - урезанные, но реализуемые);


те же кнопки, на ПК просто младший байт кода нулевой

Цитата:
б) цифровые клавиатуры (могут эмулировать "джойстик")на телефонах, PC и, возможно на некоторых экзотических моделях программируемых калькуляторов;


кнопки

Цитата:
в) символьные клавиатуры на некоторых смартфонах и PC (иногда совмещенные с цифровыми);


не годятся даже для набора СМС

Цитата:
г) "мышки" на PC (их можно эмулировать "джойстиком");
д) "тачпад" на наладонниках (от мышки отличается отсутствием видимого курсора и кнопок. Можно сказать, что в принципе они эдентичны).


это уже отслеживаю, пришлось ввести команды для включения/выключения курсора мыши

Цитата:
(в конце концов учитывать, что это может быть виртуальная клава, графити, всякие Т9 или ввод букв а-ля "Дэнди").


вот с этим настоящая ж, как бороться не представляю,

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

ну и для джойстика зарезерировать несколько специальных универсальных кодов клавиш

_________________
http://akps.ssau.ru/forth/


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: F:) как универсальная VFM
СообщениеДобавлено: Пн июн 22, 2009 20:20 
Не в сети

Зарегистрирован: Вс июн 21, 2009 20:49
Сообщения: 111
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
[quote="forth@km.ru"][/quote]
Какие новости?


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

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


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

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


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

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