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

...
Google Search
Forth-FAQ Spy Grafic

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




Начать новую тему Ответить на тему  [ Сообщений: 79 ]  На страницу Пред.  1, 2, 3, 4, 5, 6
Автор Сообщение
 Заголовок сообщения: Re: Straight Forth
СообщениеДобавлено: Пн июл 10, 2017 15:01 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6098
Благодарил (а): 14 раз.
Поблагодарили: 96 раз.
Ethereal писал(а):
Так ведь никто и не говорил, что плавающая точка не нужна. Я например говорил, что она должна быть опциональна. Т.е. не обязательна. Ядро CORE без нее и стандартизованное опциональное расширение FLOAT.

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

Ethereal писал(а):
Двойные числа не потому, что Мур, а потому-что должно же быть в конце концов целочисленное умножение, которое всегда считает правильно. А считать правильно всегда оно будет только тогда, когда произведение будет иметь в два раза больще разрядов, чем множители. Аналогично двойные числа для делимого требует целочисленное деление. Если такое деление есть, то и деление целых любой разрядности организуется просто и красиво. Короче, двойные целые для умножения и деления это примерно то же, что перенос и заем для сложения и вычитания - способ перехода к целым операндам любой разрядности.

Такой подход далеко не везде используется на практике. Если мы где-то перемножаем int*int, то результат без особенных проблем записывается в такой же int. Действительно, можно возвращать и полный результат, но тогда числа двойной точности должны быть такими же опциональными, и никак не вылезать на замену FLOAT, поскольку они решают просто другие задачи.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения: Re: Straight Forth
СообщениеДобавлено: Ср июл 12, 2017 01:38 
Не в сети
Аватара пользователя

Зарегистрирован: Ср фев 23, 2011 20:42
Сообщения: 491
Откуда: Карелия
Благодарил (а): 3 раз.
Поблагодарили: 20 раз.
Почему-же на замену ? Если в Форте есть DOUBLE , автоматически порождающие FIXED, и еще есть FLOAT то это-же совсем хорошо. Выбирай что хош в зависимости от задачи.
Hishnik писал(а):
Однако довольно много "организационных" поползновений на замену плавающей точки, как чего-то "не в духе Форта".
Я тут не при делах. Хоть у прокурора спроси :D И потом, если есть какие-то неумные поползновения, это же не значит, что сами DOUBLE и FIXED в этом виноваты ?


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 6098
Благодарил (а): 14 раз.
Поблагодарили: 96 раз.
Ethereal писал(а):
Почему-же на замену ? Если в Форте есть DOUBLE , автоматически порождающие FIXED, и еще есть FLOAT то это-же совсем хорошо. Выбирай что хош в зависимости от задачи.

С коллегами уже обсуждали переход на 64 бита как на основную разрядность, для моделирования fixed. Двойные числа на стеке как-то неудобны.


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

Зарегистрирован: Сб дек 17, 2016 23:03
Сообщения: 19
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
I have not been reading this forum for a long time. I should have followed the discussion.

The discussion has become lengthy, and it has diverged from my original intention.

Hishnik писал(а):
Ну, ПК/embedded у меня наверное в соотношении примерно 30/70. Да и то на ПК много моделирования и кросс-трансляции для embedded. Но тут есть такой момент, что аппаратная платформа должна в целом соответствовать задаче. Если мы работаем на МК, то и задача должна быть на этом МК решаема. В верхнем сегменте МК плавающая точка вполне применяется. Это мало относится к задачам простого управления и DSP, но тогда и не надо так уж игнорировать плавающую точку как таковую.

Straight Forth is only for desktop computers, not micro-controllers. There is no need to worry about supporting ratios or floating-point numbers on an 8-bit PIC18.
These are the goals:

1.) Straight Forth should support a cross-compiler. It needs LITERAL etc. vectored so we can have literal numbers in TARG words. It needs to support words to fetch and store the vocabulary-number given an xt, and also fetch and store the immediate-flag. There are some other features needed, but they are all trivial. I wrote MFX the cross-compiler for the MiniForth processor in UR/Forth and I had only one page of assembly-language code that was specific to UR/Forth. Everything else was Forth-83. Straight Forth needs to be only a slight upgrade from Forth-83.

2.) Straight Forth should support numerical programs. It needs one kind of number. Instead of having + D+ F+ etc. for adding different kinds of numbers, we have only + for our one kind of number. This design is not necessarily going to be the most efficient --- this design is intended to be convenient --- we could use double-precision IEEE-754 floating-point numbers for the greatest convenience (the Lua language does this). I have written code in ANS-Forth for ratios, but they are 32-bit integers --- they need to be 64-bit integers to be useful --- the math required is easy.

3.) Straight Forth should support text-processing programs. A problem in ANS-Forth is that there is no where to put strings. <# #> WORD etc. all use the same memory, so they corrupt each other's data. The user needs a string-stack to hold strings temporarily. The user needs good pattern-matching capability. I have written STRING-STACK.4TH in ANS-Forth that does all of this --- this is some of the best Forth code that I have written in years!

4.) Straight Forth should support quotations that can access the parent function's local variables despite the fact that the HOF (the function that the parent function calls, and which executes the quotation) has local variables of its own. I have written rquotation code in VFX and SwiftForth that does this --- I didn't invent rquotations --- I just improved the idea and implemented them using tricky non-standard assembly-language.

5.) Straight Forth should allow automatic smudging of words from the dictionary. In the definition of a class, we can have private words that can't be referenced outside of the class. Also, in a file, we can have private words that can't be referenced outside of the file. I have written an OOP (object-oriented-programming) system in ANS-Forth that can easily be upgraded to smudge private words as described here. In MFX I wrote code in UR/Forth to smudge private words in a file. This is easy.

6.) Straight Forth should support "chains" as the primary data-structure. The users will be encouraged to use chains for their data unless chains don't work and a more complicated data-structure is needed (rare). The chains internally are self-balancing binary-trees with uplinks. I have extensive code written in ANS-Forth to support self-balancing binary-trees, although I don't have the uplinks done yet, so I'm reasonably close to having chains.

7.) Straight Forth should be simple and understandable. Fancy features will not be supported unless they are absolutely necessary. We are competing against C that was supposed to be simple and understandable but is actually complicated and confusing. To succeed, we need to focus on simplicity.

I am not just speculating on what could be done. I have written most of this code already. I don't have a compiler written --- I do have the important features written (some in UR/Forth, some in ANS-Forth, and some in tricky non-standard VFX or SwiftForth).

I have delayed writing a compiler myself because I want to get a consensus from Forth programmers. If I just go ahead on my own, the result will be yet another non-standard Forth system with one user, who is also the designer. The Forth-200x committee will continue to claim that they set the standard and all Forth programmers on all continents depend entirely upon their genius.

Forth-200x was supposed to be completed in the 2000 decade, but it wasn't, so the name should have been changed to Forth-201x. Soon the year 2020 will pass, so the name should be changed to Forth-202x. The Forth-200x promoters are mired in tedious debates that go on for years, typically debating an idea that could be dismissed with two minutes of thought (Alex McDonald's "recognizer" idea, for example). It is unlikely that Forth-200x will ever be complete. Every year it gets bigger and more complicated, and it still lacks basic features needed to support cross-compilation. Eventually the year 2100 will pass and the Forth-200x committee (perhaps their grand-children's grand-children) will still be mired in tedious debates about idiotic ideas.

I am hoping that Russians are smarter. Don't get mired in tedious debates about idiotic ideas. Focus your minds on designing a simple but viable Forth standard. This isn't going to be the best Forth that you can imagine. Adequate is adequate. If everybody strives to come to a conclusion reasonably quickly, and avoids tedious debates about subjects that are ultimately unimportant, I would expect the design to be complete before summer. Then it is necessary to write a compiler --- this would most likely be an existing compiler, such as Quark Forth, modified to be Straight Forth compliant --- I would expect this to be complete before next winter.

This is an opportunity for Russians to show that they can design a Forth standard in a short amount of time --- by comparison, the Forth-200x committee have taken decades designing Forth-200x and are not near to completion --- the Forth community has never had a simple but viable Forth standard since Forth was invented in 1974, but that is the goal.

I just had an idea: instead of calling it Straight Forth, it could be called Adequate Forth. ;-)


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

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


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

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


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

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