SF CVS stats

20 messages Options
Embed this post
Permalink
Yuriy Zhilovets

Re: SF CVS stats

Reply Threaded More More options
Print post
Permalink
Привет всем!

>Юра Жиловец недавно взялся за доведение до ума LinuxSPF.
>
Пока никаких результатов нету. Я до сих пор думаю.
Вот сейчас не могу понять, нужна ли библиотеке libc инициализация через
_init и _fini.

Ю. Жиловец



yGREK Heretix

SF CVS stats

Reply Threaded More More options
Print post
Permalink
Всем привет!

 У SF появилась статистика по CVS Activity [1].

 Предложение - выложить на SF последнюю версию SPF/Linux т.к. по
статистике скачиваний [2] видно что до сих пор качают linux.8, тогда
как последняя вроде linux.10

[1] http://sourceforge.net/project/stats/detail.php?group_id=17919&ugn=spf&mode=60day&type=cvs
[2] http://sourceforge.net/project/stats/detail.php?group_id=17919&ugn=spf&type=prdownload&mode=60day&package_id=141388&release_id=0

--
ygrek


attachment0 (187 bytes) Download Attachment
Andrey Cherezov

Re: SF CVS stats

Reply Threaded More More options
Print post
Permalink
Добрый день, ygrek!

Ваше сообщение от 04.04.2007 20:46:
>  Предложение - выложить на SF последнюю версию SPF/Linux т.к. по
> статистике скачиваний [2] видно что до сих пор качают linux.8, тогда
> как последняя вроде linux.10
>  
spf-mp8 была последней, которая может компилироваться как под Linux, так
и под Cygwin.
Последующие - нет. Поэтому я их считаю "временно немножко поломанными" и
не беру
на себя ответственность по выкладыванию на sf.net.

Юра Жиловец недавно взялся за доведение до ума LinuxSPF. Наверное стоит его
результаты тоже присовокупить к linux.10, потом потестировать под cygwin
(виндовый
RedHat Linux :), и может быть под другими x86-юниксами, и уже потом
выкладывать
на замену хорошо потестированной spf-mp8.


Yuriy Zhilovets

Re: LinuxSPF & libc

Reply Threaded More More options
Print post
Permalink
In reply to this post by Andrey Cherezov
Привет, Андрей!

 > Что тут думать, трясти надо :) Простейший пример:

Да там не так все просто. В этот момент (когда сработала main) все эти
_init уже вызваны.
Их вызывает код, слинкованный с исполняемым файлом.
А вот в новом файле они откуда возьмутся?

В общем, пребываю в раздумьях.

Юра





Yuriy Zhilovets

Re: LinuxSPF & libc

Reply Threaded More More options
Print post
Permalink
In reply to this post by Andrey Cherezov
Andrey Cherezov пишет:

>Т.е. отменить обязательную инициализацию libc (для проверки) нельзя?
>  
>
Отменить можно путем хаков, но неизвестно, в каком месте и каком боком
эта отмена потом вылезет.

>>А вот в новом файле они откуда возьмутся?
>>
Да они там не просто вызываются, к сожалению.
При запуске вызывается код из некого слинкованного файла gcrt1.o,
который вызывает

int __libc_start_main(int *(main) (int, char * *, char * *), int argc,
char * * ubp_av, void (*init) (void), void (*fini) (void), void
(*rtld_fini) (void), void (* stack_end));

А вот эти самые init и fini тоже берутся из слинкованного файла. Черт
знает, что в них содержится. По-моему, это какой-то аналог фортовского ;..
И что еще хуже - этот самый gcrt1 на разных платформах разный. А хочется
все-таки совместимость по POSIX хотя бы для всех 386.
Пока склоняюсь к мысли, что при SAVE надо делать объектный файл и
слинковывать его с gcrt и libc. У Максимова вроде бы тоже так сделано.

Ю. Жиловец


Andrey Cherezov

Re: LinuxSPF & libc

Reply Threaded More More options
Print post
Permalink
In reply to this post by Yuriy Zhilovets
Добрый день, Yuriy Zhilovets!

Ваше сообщение от 04.04.2007 19:47:
> Пока никаких результатов нету. Я до сих пор думаю.
> Вот сейчас не могу понять, нужна ли библиотеке libc инициализация через
> _init и _fini.
>  
Что тут думать, трясти надо :) Простейший пример:

: TEST
  S" /lib/libc.so.6" DLOPEN ?DUP DUP H.
  IF S" strlen" ROT DLSYM ?DUP DUP H.
     IF S" forth" DROP >R 0 SWAP EXECUTE . RDROP THEN
  THEN
; TEST

Выполняю на FC6:

2A8658 4ACD82A0 5  Ok

Т.е. в libc.so.6 вызывать _init не нужно, работает и так.


Andrey Cherezov

Re: LinuxSPF & libc

Reply Threaded More More options
Print post
Permalink
In reply to this post by Yuriy Zhilovets
Добрый день, Yuriy Zhilovets!

Ваше сообщение от 08.04.2007 18:57:
> Да там не так все просто. В этот момент (когда сработала main) все эти
> _init уже вызваны.
> Их вызывает код, слинкованный с исполняемым файлом.
>  
Т.е. отменить обязательную инициализацию libc (для проверки) нельзя?
> А вот в новом файле они откуда возьмутся?
>  
Если действительно нужны, то почему бы не вызывать и в новом файле?


Andrey Cherezov

Re: LinuxSPF & libc

Reply Threaded More More options
Print post
Permalink
In reply to this post by Yuriy Zhilovets
Добрый день, Yuriy Zhilovets!

Ваше сообщение от 08.04.2007 21:13:
> Да они там не просто вызываются, к сожалению.
> При запуске вызывается код из некого слинкованного файла gcrt1.o,
> А вот эти самые init и fini тоже берутся из слинкованного файла. Черт
> знает, что в них содержится.
Если черт знает, то стоит попробовать без них. Когда для виндов делал
SPF тоже
много чего дизассемблировал, чесал репу. Особенно много непонятностей
было для WinCE.
Везде какая-то си-специфичная инициализация. Тем не менее минимальный
exe (не вызывается
ничего из этого непонятного тот stub.exe начальным размером байт 700)
заработал, и потом
его доращивал до форта. Единственная полезная "сишная" часть, которую в
SPF 3.0 упустил -
это инициализация SEH (регистр FS), что позже добавил.
>  По-моему, это какой-то аналог фортовского ;..
> И что еще хуже - этот самый gcrt1 на разных платформах разный. А хочется
> все-таки совместимость по POSIX хотя бы для всех 386.
> Пока склоняюсь к мысли, что при SAVE надо делать объектный файл и
> слинковывать его с gcrt и libc. У Максимова вроде бы тоже так сделано.
>  
Ну, он пользуется стандартным сишным компилятором, поэтому, возможно там
что-то лишнее добавляется. Надо пробовать. Я давал ссылку на минимальный ELF
(с DLOPEN) - можно попробовать дописать туда, например, функцию печати
строки -
и посмотреть, как сработает. Зачем заранее бояться. Как раз для
максимально широкой
совместимости стоит отсекать как можно больше. Скорее всего базовый форт
может
вообще без использования libc работать.

Хотя в том lnxstub dlopen/dlsym берутся из  libdl.so.2 - тоже достаточно
специфичная
зависимость. И вообще есть юниксы, в которых не поддерживаются *.so.
Так что по большому счету в Unix есть только один способ получения реально
"независимого" кода - это компилировать ядро не в бинарник, а в сишный
текст.
Тогда gcc можно считать JIT-компилятором :)


Yuriy Zhilovets

Re: LinuxSPF & libc

Reply Threaded More More options
Print post
Permalink
Andrey Cherezov пишет:

>Скорее всего базовый форт может вообще без использования libc работать.
>  
>
libc - это фактически местный API, поэтому ориентируюсь на него.

Все-таки хочу сделать по-своему. Сразу возникают такие вопросы по WinSPF:

1) Новая форт-система собирается на вершине старой. Ее начало будет в
районе 0x8400000 +  размер старой системы ?
2) Модуль новой форт-системы перемещаем или нет? Какие у него свойства -
RW + Exeс ?
3) Выполняется ли при запуске какая-то специфичная инициализация в
машинных кодах или управление сразу передается на форт-код?

Ю. Жиловец



Andrey Cherezov

Re: LinuxSPF & libc

Reply Threaded More More options
Print post
Permalink
Добрый день, Yuriy Zhilovets!

Ваше сообщение от 12.04.2007 19:06:
> Все-таки хочу сделать по-своему. Сразу возникают такие вопросы по WinSPF:
>
> 1) Новая форт-система собирается на вершине старой. Ее начало будет в
> районе 0x8400000 +  размер старой системы ?
>  
Новая форт-система SPF4 обычно собирается из (JPF375C.EXE). Соответственно
IMAGE-BASE новой системы будет близок к числу HERE в JPF + размер ЦК.
C:\spf4>JPF375C.EXE
HEX HERE
 Ok ( 51B4FC )
C:\spf4>spf4.exe
HEX IMAGE-BASE .
540000  Ok
> 2) Модуль новой форт-системы перемещаем или нет? Какие у него свойства -
> RW + Exeс ?
>  
Не перемещаем. Да, на соотв. страницы полные права.
> 3) Выполняется ли при запуске какая-то специфичная инициализация в
> машинных кодах или управление сразу передается на форт-код?
>  
В машкодах выполняется тот же код, что для WNDPROC и прочих колбэков,
потом PROCESS-INIT и (INIT), см. spf_init.f.


Ruvim Pinka

Re: LinuxSPF & libc

Reply Threaded More More options
Print post
Permalink
In reply to this post by Andrey Cherezov
Привет!

А как описать (представить) в языке Си статические данные, в которых
участвуют адреса? Например цепочку (односвязный список) точек входа в
примитивы (пусть, они представлены функциями или асмовыми вставками).
Примерчик бы :)

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

On 4/9/07, Andrey Cherezov <[hidden email]> wrote:
> Хотя в том lnxstub dlopen/dlsym берутся из  libdl.so.2 - тоже достаточно
> специфичная
> зависимость. И вообще есть юниксы, в которых не поддерживаются *.so.
> Так что по большому счету в Unix есть только один способ получения реально
> "независимого" кода - это компилировать ядро не в бинарник, а в сишный
> текст.

--
Ruvim
Aleksej Saushev

Re: LinuxSPF & libc

Reply Threaded More More options
Print post
Permalink
  Здравствуй!

"Ruvim Pinka" <[hidden email]> writes:

> А как описать (представить) в языке Си статические данные, в которых
> участвуют адреса? Например цепочку (односвязный список) точек входа в
> примитивы (пусть, они представлены функциями или асмовыми вставками).
> Примерчик бы :)

int this(){return 1;}
int that(){return 2;}
static void *list[] = {this, that};

Односвязный список делать тоже можно, хотя и заколебёшься.
Ruvim Pinka

Re: LinuxSPF & libc

Reply Threaded More More options
Print post
Permalink
День добрый!

On 4/14/07, Aleksej Saushev <[hidden email]> wrote:

> int this(){return 1;}
> int that(){return 2;}
> static void *list[] = {this, that};
>
> Односвязный список делать тоже можно, хотя и заколебёшься.

static void *element1[] = { this, NULL };
static void *element2[] = { that, &element1[0] };

примерно так?
я бы его автоматом сгенерил :)

--
Ruvim
Aleksej Saushev

Re: LinuxSPF & libc

Reply Threaded More More options
Print post
Permalink
  Здравстуй!

"Ruvim Pinka" <[hidden email]> writes:

> On 4/14/07, Aleksej Saushev <[hidden email]> wrote:
>
>> int this(){return 1;}
>> int that(){return 2;}
>> static void *list[] = {this, that};
>>
>> Односвязный список делать тоже можно, хотя и заколебёшься.
>
> static void *element1[] = { this, NULL };
> static void *element2[] = { that, &element1[0] };
>
> примерно так?

Да. Только "&element1[0]" это одно и то же, что и "element1",
за исключением того, что "&element1[0]" не является l-value.

> я бы его автоматом сгенерил :)

Да это-то понятно.
Но таблица перемещения будет офигительнейших размеров.
Yuriy Zhilovets

POSTPONE в целевом компиляторе

Reply Threaded More More options
Print post
Permalink
In reply to this post by Andrey Cherezov
Привет всем!

Заметил, что попытка определить в целевом компиляторе что-то вроде

: aaa POSTPONE . ;

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

Это нормальное поведение?

Ю. Жиловец



Andrey Cherezov

Re: POSTPONE в целевом компиляторе

Reply Threaded More More options
Print post
Permalink
Добрый день, Yuriy Zhilovets!

Ваше сообщение от 15.04.2007 15:08:
> Заметил, что попытка определить в целевом компиляторе что-то вроде
>
> : aaa POSTPONE . ;
>
> вызывает эту точку в какой-то момент компиляции, причем с GPF по
>  
В какой момент?

: aaa POSTPONE . ;
 Ok
: bbb 5 [ aaa ] ;
 Ok
bbb
5  Ok



Andrey Cherezov

Re: POSTPONE в целевом компиляторе

Reply Threaded More More options
Print post
Permalink
In reply to this post by Yuriy Zhilovets
Добрый день, Yuriy Zhilovets!

Ваше сообщение от 15.04.2007 15:08:
> Заметил, что попытка определить в целевом компиляторе что-то вроде
>
> : aaa POSTPONE . ;
>  
Пардон, упустил слова "в целевом компиляторе".
Но все равно нужен более подробный репорт - со сбойным куском.


Yuriy Zhilovets

Re: POSTPONE в целевом компиляторе

Reply Threaded More More options
Print post
Permalink
Andrey Cherezov пишет:

Если вставлять в файл spf.f вот такое определение (после HERE TC-CALL,)
и собирать новую систему

: aaa POSTPONE . ;

то в зависимости от места вставки можно получать разные эффекты:

1) Нормальный вывод, правда на стеке потом остается какой-то мусор
2) Нормальный вывод, но не срабатывает BYE и после нажатия ENTER получаем GPF
3) Сразу GPF

Если эту строку написать в отдельный файл и пробовать INCLUDE, то

получаем GPF тоже сразу. Кроме того, в этом файле почему-то перестает работать ELSE.

Такое впечатление, что POSTPONE компилирует куда-то не в то место.

Ю. Жиловец



Andrey Cherezov

Re: POSTPONE в целевом компиляторе

Reply Threaded More More options
Print post
Permalink
Some javascript/style in this post has been disabled (why?)
Добрый день, Yuriy Zhilovets!

Ваше сообщение от 15.04.2007 22:48:
Если вставлять в файл spf.f вот такое определение (после HERE TC-CALL,) 
и собирать новую систему

: aaa POSTPONE . ;
  
Сразу после "HERE TC-CALL," , конечно, нельзя, там же еще не определены
ингридиенты - вызов такого aaa будет "постпонить" точку инструментального
словаря, а не целевого.
то в зависимости от места вставки можно получать разные эффекты:

1) Нормальный вывод, правда на стеке потом остается какой-то мусор
  
Это адрес точки (см. ниже про LIT,)
2) Нормальный вывод, но не срабатывает BYE и после нажатия ENTER получаем GPF
3) Сразу GPF
  
Разумеется, от места вставки зависеть должно. Там ведь есть места, где
неопределен ".", или переопределен POSTPONE и т.п.
ЦК - это такая штука, что нужно держать в голове инструментальный и
целевой контексты...
Чтобы сработал конкретно : aaa POSTPONE . ; , нужно найти точку, где в целевом
словаре уже определены COMPILE, и ".", и в контексте ЦК-шный POSTPONE, т.к.
: aaa POSTPONE . ;
это
: aaa ['] . COMPILE, ;
Такое впечатление, что POSTPONE компилирует куда-то не в то место.
  
Старая (моя из ЦК spf3) реализация POSTPONE,

: POSTPONE ALSO TC-WL POSTPONE POSTPONE PREVIOUS ; IMMEDIATE

вообще не предусматривала применение "POSTPONE слово_НЕ_немедленного_исполнения"
внутри ЦК. Попытка использования в таком виде приведет к компиляции ссылки на
старый (инструментальный) COMPILE, которого в целевом словаре после SAVE, конечно, не будет.

Димина новая реализация POSTPONE (в ЦК spf4) хотя явно и задумывалась для обхода
этого ограничения, но не испытана с "ненемедленными" словами тоже (используется
только в виде POSTPONE \ , POSTPONE ; , POSTPONE LITERAL и POSTPONE [ ,
как и в моем spf3, т.е. можно было и не усложнять. По-моему, там забыто слово LIT,.
Если добавить в ветку ELSE:
: POSTPONE \ 94
  ALSO TC-WL
  ?COMP
  PARSE-NAME SFIND DUP
  0= IF -321 THROW THEN
  1 = IF COMPILE,
      ELSE LIT, S" COMPILE," TC-FINDOUT COMPILE, THEN
  PREVIOUS
; IMMEDIATE

то можно ставить твой "aaa" в spf.f в нужное место:
S" src\compiler\spf_words.f"         INCLUDED
: aaa POSTPONE . ;

И это работает в полученном exe, как ожидалось:
: TEST [ aaa ] ;
 Ok
5 TEST
5  Ok
Yuriy Zhilovets

Re: POSTPONE в целевом компиляторе

Reply Threaded More More options
Print post
Permalink
Andrey Cherezov пишет:

> По-моему, там забыто слово LIT,.
> Если добавить в ветку ELSE:
> : POSTPONE \ 94
>   ALSO TC-WL
>   ?COMP
>   PARSE-NAME SFIND DUP
>   0= IF -321 THROW THEN
>   1 = IF COMPILE,
>       ELSE *LIT,* S" COMPILE," TC-FINDOUT COMPILE, THEN
>   PREVIOUS
> ; IMMEDIATE

Да, в таком виде работает.

Просьба ygrek исправить определение в исходном тексте (tc_spf.f)

Ю. Жиловец