Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Вт мар 19, 2024 06:05

...
Google Search
Forth-FAQ Spy Grafic

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




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

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

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

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

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


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

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


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

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

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


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

Зарегистрирован: Сб дек 17, 2016 23:03
Сообщения: 60
Благодарил (а): 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. ;-)


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7958
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
HughAguilar писал(а):
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.


Yes, indeed, interpreter engine should be carefully described and made extensible as much as possible. Words like vectored LITERAL are simple and gives a great flexibility. There are no reasons to limit usage of Forth by innatural rules.

HughAguilar писал(а):
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.

I'm agreed with this idea in general, but in practive I use separate F+ and other floaing-point words. An approach looks simple - if we have a hardware of certain type, Forth should support it as close to it's model as possible. So, since we have FPU it is good to support FPU formats and operations. Maybe with another higher level, but I feel programmers will dig into CPU/FPU sooner or later when limited by operations. Anyway, we must implement commands like + for different formats before adding higher-level words.

For + (and other words like this) we can have a slightly crazy thing like vectors :) When base low-level words are explicitly defined by prefixes (D+ for 32-bits integer, F+ for double floating etc.), + may be vectorized and set to 'base format' by default.

HughAguilar писал(а):
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!


Yes! Tex processing is very probably to use in scripting, where Forth is strong. I think words like <# # #> are just temporarily solution that accepts when no other adequate way was studied. It is not clear for me now how exactly this should be solved, by it definitely should be solved. At least, a set of string-supporting words must exist.

HughAguilar писал(а):
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.

I have a rule for including such capabilities into the Forth engine. We must add a feature if it depended on the internal, hided algorithm inside Forth and cannot be added without deeply invasion to source code. Vectored LITERAL is an example of such thing - we must think about this, because cannot make LITERAL vectored after Forth is started.

I think quotations is a kind of this features. This should be described and changes to the engine must be stated clearly.

HughAguilar писал(а):
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.


Yes*2. See above - these features requires a certain changes in the engine, so must be described in the standard.

HughAguilar писал(а):
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.


Oh, going a way of 'cool words' we will fall into another Forth-religion :)) Indeed, we need to focus on the necessary words and leave other at the libraries level.

HughAguilar писал(а):
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 wonder how stubborn they are standing at their swampy ground.

Btw, we meet Forth one more time in the product our customer wants to replace :) The device originated from UK and use high-level scripting language transformed to the .FTH file, with Forth code inside, of course. It is too old and the device has very limited capabilities, so completely rewriting this part of the project is in progress. I just wonder, why nobody of ANS hear about such brilliant application? :) Maybe nobody of practical programmers cares about that company of self-claimed experts?

HughAguilar писал(а):
I am hoping that Russians are smarter.

Hmm... a tons of flame took place here :) Anyway, it is a challenge indeed.

HughAguilar писал(а):
I just had an idea: instead of calling it Straight Forth, it could be called Adequate Forth.


! :)


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

Зарегистрирован: Сб дек 17, 2016 23:03
Сообщения: 60
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
Hishnik писал(а):
HughAguilar писал(а):
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.

I'm agreed with this idea in general, but in practive I use separate F+ and other floaing-point words. An approach looks simple - if we have a hardware of certain type, Forth should support it as close to it's model as possible. So, since we have FPU it is good to support FPU formats and operations. Maybe with another higher level, but I feel programmers will dig into CPU/FPU sooner or later when limited by operations. Anyway, we must implement commands like + for different formats before adding higher-level words.

I want Straight Forth to be simple, like the Lua language.
Lua uses double-precision IEEE-754 floating-point numbers for everything. In some cases, the code is optimized internally to use fixed-point (such as for loop indices), but the user doesn't concern himself with this. The user just assumes that all numbers are floating-point.
This is very convenient. If the compiler doesn't do optimization internally however, it would be inefficient.

Ilya Vasilyev suggested that the implementation of "number" not be defined. Only the behavior would be defined. The range of allowed numbers would be left undefined because this would be implementation-dependent. Doing this allows several possible implementations:
1.) (slow) a ratio made of 64-bit fixed-point numerator (signed) and denominator (unsigned)
2.) (fast) double-precision IEEE-754 floating-point
3.) (fastest) a 64-bit fixed-point value with unity assumed to be 2^32

There may be some programs that require a specific implementation:
#1 is required if high precision is needed
#2 is required if the data have a wide range
Any program that works with #3 will also work with #1 or #2 because #1 is the most limited (very narrow range and low precision).

Hishnik писал(а):
For + (and other words like this) we can have a slightly crazy thing like vectors :) When base low-level words are explicitly defined by prefixes (D+ for 32-bits integer, F+ for double floating etc.), + may be vectorized and set to 'base format' by default.

I don't think this is a good idea, because in your code you would be switching from one kind of number to another too often --- the source-code could become bloated and confusing --- also, you may have two kinds of numbers being given to an operator such as + and so you still have to do an explicit conversion of one type of number into another type of number.

We could just define #3 above (64-bit fixed-point with 2^32 as unity) as the standard.
If people want floating-point then they get an extension code-library and use F+ F- F* etc..
If people want ratios then they get an extension code-library and use R+ R- R* etc..
If people want vectors then they get an extension code-library and use V+ V- V* etc..
This would be easy to describe and easy to implement. The source-code becomes somewhat bloated because numbers have to be explicitly converted from one format to another. This is not a big problem though.

How numbers are defined is not very important to me. I don't want this debate to delay the design of the standard. My primary concern is to support cross-compilation. I'm not a mathematician anyway, so numerical programs aren't very important to me. I might write a program to generate gcode for CNC machines (milling machines, lathes, etc.) --- #3 would be fine for that --- I don't have any difficult requirements of my own.
I do think that ANS-Forth numbers (64-bit with 1 as unity) are inadequate --- there is no fractional part, so the numbers can't be used for CNC or anything else.

Hishnik писал(а):
HughAguilar писал(а):
I am hoping that Russians are smarter.

Hmm... a tons of flame took place here :) Anyway, it is a challenge indeed.

It is not really a question of whether Russians are smart or not, because Forth is a simple language that can be understood by anybody. When I started programming in Forth in 1984 I was attracted to Forth because it was simple and easy to understand.

The question is whether Russians are practical or not. For a standard to succeed, it is necessary to keep it simple. I gave a schedule in which the standard is designed before next summer and a first implementation is available before next winter. To succeed at this schedule, we need to focus on making the design simple and practical. Avoid getting mired in tedious debates about questions that are ultimately unimportant. I am willing to compromise on most of the design decisions (including the definition of a number) in order to get a consensus quickly. My goal primarily is to design a Forth standard that supports cross-compilation --- ANS-Forth fails to support cross-compilation, and Forth-200x is worse than ANS-Forth --- I'm not willing to compromise on cross-compilation support, which is why I have abandoned ANS-Forth and Forth-200x.

Forth-200x is mired in years of tedious debate on the "recognizer" idea that Alex McDonald promotes. This is an attempt to give Forth a syntax. Each recognizer would recognize a word as having some syntax and it would compile it in a special way. This is contrary to Forth tradition in which there is no syntax --- traditionally, words are delimited by white-space --- this is the only syntax, and it very simple. The various Forth-200x systems may have different recognizers, so they behave differently. If they have the same set of recognizers, but in a different order, then they will behave differently. So, if you have 10 recognizers, then you have 3,638,800 possible syntax. You don't have to be smart to immediately understand that this is a dumb idea!

Hishnik писал(а):
HughAguilar писал(а):
I just had an idea: instead of calling it Straight Forth, it could be called Adequate Forth.

! :)

I like the name Adequate Forth because it implies that we are focusing on making the Forth standard simple and practical --- adequate is adequate!

To succeed, we need to avoid wild ideas that have no practical purpose --- our goal is not to impress the world with our genius --- our goal is to quickly design a Forth standard that is adequate for cross-compilation, and also adequate for basic numerical and text programs.


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

Зарегистрирован: Сб дек 17, 2016 23:03
Сообщения: 60
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
Hishnik писал(а):
Ну тут можно ругаться с ANS-комитетом. Это если есть желание пообщаться с малоадекватными лузерами :D Там уже засилье Forth Inc с Единственно Правильным Фортом. И Антон Эртл как главный защитник, он же организатор Еврофорт. Которая скатилась до уровня местечкового семинара. На широкие массы выходить попросту боятся, и правильно делают, поскольку у не-фортеров наверняка того пиетета не окажется. А совершенно честный вопрос "не расскажете ли, что вы делаете на Форте" в комитете считают провокационным. Так что ситуация в Форте в целом соответствует мировой - США пытается доминировать, Европа послушно кивает и ничего сделать не может, Россия предлагает равноправное партнерство, но попадает под ругань от бессилия как-то повлиять. :))

Google Translate converts clever Russian into muddled English. Please try to avoid metaphors and obscure language --- allow Google Translate to convert simple Russian into simple English! :-)

Anton Ertl was the chairman of the Forth-200x committee for a long time. He has now lost his job. Stephen Pelc is the new chairman.

Anton Ertl is a college professor. When he was chairman, this caused Forth-200x to appear to be an academic project. The truth is that Forth-200x was a corporate project. Stephen Pelc and his employee Peter Knaggs were both on the committee, so MPE had two votes. Similarly, Leon Wagner and his employee Andrew Haley were both on the committee, so Forth Inc. had two votes. Anton Ertl was a figurehead.

Now that Stephen Pelc is the chairman, the appearance of Forth-200x being an academic project has been abandoned. Forth-200x is now obviously a corporate project. Stephen Pelc is only interested in maximizing profit for his company MPE --- Stephen Pelc considers Forth programmers such as myself and Ilya Tarasov to be the enemy --- we have not paid for a copy of VFX, and we are not helping him to sell VFX, so he has no use for us.

I think Anton Ertl lost his job because he was moving too slowly. In his effort to make Forth-200x appear to be an academic project, he allowed any wild idea to be debated. The result was years of tedious debate about obviously dumb ideas. No progress was being made. As I mentioned earlier, Forth-200x was originally supposed to be completed shortly after the year 2000 --- we are now approaching the year 2020 and we are not near to completion --- the sluggish progress of Forth-200x became ridiculous, so Anton Ertl lost his job.

Now that Stephen Pelc is the chairman of Forth-200x, we can expect much faster progress to be made. Stephen Pelc will declare VFX to be the new Forth Standard --- anybody who competes against MPE will be declared to be non-standard --- Forth-200x is a speedboat, and common Forth programmers have been thrown overboard to swim!

I can guarantee you that Stephen Pelc is not going to listen to opinions expressed by Russians. Anton Ertl pretended to listen to opinions expressed by anybody, including Russians, but then he would do what Stephen Pelc and Leon Wagner commanded. This pretense is gone now.


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

Зарегистрирован: Пн янв 07, 2013 22:40
Сообщения: 2141
Благодарил (а): 8 раз.
Поблагодарили: 74 раз.
HughAguilar

Какой полезный дизайн можно рассматривать в существующих Форт системах. В частности начав, например, с Win32Forth, SPF4 ...
What useful design can be considered in existing Forth systems. In particular, starting with, for example, Win32Fortn, SPF4 .... (translate)

HughAguilar писал(а):
How numbers are defined is not very important to me. I don't want this debate to delay the design of the standard. My primary concern is to support cross-compilation. I'm not a mathematician anyway, so numerical programs aren't very important to me. I might write a program to generate gcode for CNC machines (milling machines, lathes, etc.) --- #3 would be fine for that --- I don't have any difficult requirements of my own.
I do think that ANS-Forth numbers (64-bit with 1 as unity) are inadequate --- there is no fractional part, so the numbers can't be used for CNC or anything else.


? Novice Forth & Slide-rule.4th


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

Зарегистрирован: Сб дек 17, 2016 23:03
Сообщения: 60
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
KPG писал(а):
HughAguilar

Какой полезный дизайн можно рассматривать в существующих Форт системах. В частности начав, например, с Win32Forth, SPF4 ...
What useful design can be considered in existing Forth systems. In particular, starting with, for example, Win32Fortn, SPF4 .... (translate)

I don't understand your question. Are you asking me if there is anything of value in existing Forth systems? Yes, of course there is --- but everything of value is non-standard.
For example, in VFX we have a LITERAL that is vectored --- this is not documented in the VFX manual though --- when I complained about LITERAL not being vectored, Stephen Pelc told me that it is vectored in VFX and said that I should have disassembled VFX to figure this out myself.

I want to design a Forth standard that supports cross-compilation --- ANS-Forth fails to do this --- this is actually easy though!
I upgraded UR/Forth in 1994 to do this, and I only needed one small file of assembly-language code --- I had extensively studied UR/Forth already --- I knew how to do this, which is why Testra hired me.
I don't know enough about the internal workings of VFX, SP-Forth, Win32Forth to do this upgrade today --- also, these Forth systems are in active development so the internal workings might change in the next release --- I don't think it is a good idea to rely on knowledge of internal workings of any Forth compiler if the compiler-writer has not given you permission to modify his compiler.

I'm mostly interested in Quark Forth because Ilya is agreeable to Quark Forth being used as a reference compiler for the Forth standard --- he won't pull the rug out from under my feet. ;-)
(I don't know if that translates into Russian. In English we have a saying about pulling the rug out from under somebody's feet. This means, to tell somebody that he is on solid footing, then betray him with an unexpected change).


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

Зарегистрирован: Пн янв 07, 2013 22:40
Сообщения: 2141
Благодарил (а): 8 раз.
Поблагодарили: 74 раз.
Yes!
Мой, в основном, опыт кросс-компиляции Форт был при использовании ff303 от Бреда для PDP-11.

P.S. SPF4 используется многими из RUFIG сообщества, но его строение не так просто для понимания и также имеется форк от mOleg.
SPF4 портирован также для KolibriOS. ( Интересно, что В ДНК записали «Прибытие поезда» и операционную систему KolibriOS
Код:
LICENSE

You can modify and/or redistribute the core SP-Forth system (i.e. all files in src) under the terms of GNU GPL as published by FSF. All other files, including contrubuted code in devel, are licensed under GNU LGPL by default (if not stated otherwise).

Shortly speaking it means that :

    You are prohibited to modify core SPF system and distribute the result of this modification without providing full sources.

    You are allowed to compile and distribute closed-source projects with original SPF.

    You are allowed to use unmodified code from devel in combination with your own code in closed-source projects.

    You are obliged to contribute back your modifications to original code from devel if you modified and used it in closed-source project, but you may leave your own code closed.

AUTHORS

Russian Forth Interest Group with the help of many contributors.

Started by Andrey Cherezov in 1992


Win32Forth
Код:
GNU Library or Lesser General Public License version 2.0 (LGPLv2), Public Domain


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7958
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
HughAguilar писал(а):
I want Straight Forth to be simple, like the Lua language.
Lua uses double-precision IEEE-754 floating-point numbers for everything. In some cases, the code is optimized internally to use fixed-point (such as for loop indices), but the user doesn't concern himself with this. The user just assumes that all numbers are floating-point.
This is very convenient. If the compiler doesn't do optimization internally however, it would be inefficient.


There are some approaches hiding low-level data representation. Instead of floating point we can assume strings everywhere. However, Forth is too low-level to hide data. Programmer implementing Forth in any case will start from registers and will use 32 or 64 bits integer numbers. Operations with this numbers will exist at low level and sooner or later will be accessible through Forth words.

HughAguilar писал(а):
How numbers are defined is not very important to me. I don't want this debate to delay the design of the standard.

Any addition data representation should be allowed in Standard. This looks far more better than trying to define all possible data formats and hope programmers will join it. I think if we have 'native' numbers and a well-described way to add any other formats, this is easy to start and flexible enough to extend Forth by floating point, rational numbers, strings etc.

HughAguilar писал(а):
When I started programming in Forth in 1984 I was attracted to Forth because it was simple and easy to understand.


Exactly. The fact Forth is simple is very smart point and I wonder why after starting to use Forth many programmers desire to make it more complex.

HughAguilar писал(а):
The question is whether Russians are practical or not

Indeed. Being an 'author of Standard' is a sweet dream, and many non-practical forthers in Russia, unfortunately, makes a lot of noise. The right and natural way to write a Standard is summarizing practical experience. An important difference in engineer's psychology for Russia is a stronger focusing to more creaitve process and more understanding rather than just using standards. Following the standard may be considered as a kind of surrender :) 'Professionals can write their own Forth alone!'

HughAguilar писал(а):
Forth-200x is mired in years of tedious debate on the "recognizer" idea that Alex McDonald promotes. This is an attempt to give Forth a syntax.

I think it is waste of time. All of these may be solved by making 'hooks' in the Forth engine and letting programmers to extend or replace any part, not only entire interpreter.

HughAguilar писал(а):
To succeed, we need to avoid wild ideas that have no practical purpose --- our goal is not to impress the world with our genius

I like your words! :)


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7958
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
HughAguilar писал(а):
I'm mostly interested in Quark Forth because Ilya is agreeable to Quark Forth being used as a reference compiler for the Forth standard


Reference Forth is a good thing. I'm not pretending to be a leading expert here, but can start to write a simple and easy to understand engine. However, I predict a tons of tactical critics, proposals to make it ANS-compatible, calls to not to waste time and join another 'serious' team. Nevermind :)

The chapter of forum with 'Open Forth' already exist. It was more an attempt to reveal main organization problems, with predictable results. If needed, materials may be placed there.
viewforum.php?f=55


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7958
Благодарил (а): 25 раз.
Поблагодарили: 144 раз.
Ok, I did setup for the reference project under Eclipse IDE. About 2500 lines of code from my previous researches are imported, it covers about 180 words from Forth core, some math and file operations. I don't want to throw it somewhere to Internet deeps without a certain discussion and stting up goals, rules and workflow.


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

Зарегистрирован: Сб дек 17, 2016 23:03
Сообщения: 60
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
Hishnik писал(а):
HughAguilar писал(а):
How numbers are defined is not very important to me. I don't want this debate to delay the design of the standard.

Any addition data representation should be allowed in Standard. This looks far more better than trying to define all possible data formats and hope programmers will join it. I think if we have 'native' numbers and a well-described way to add any other formats, this is easy to start and flexible enough to extend Forth by floating point, rational numbers, strings etc.

I said that I want to have a consensus. Lets start with some basic definitions and then ask if anybody disagrees:
------------------------------------------------------------------------------------------------------------

1.) A "cell" (data-stack element) is 64-bit.

2.) A single-precision number is a 64-bit fixed-point value with unity = 2^32. The operators + - * / etc. operate on these.

3.) A double-precision number is a 128-bit fixed-point value with unity = 2^64. The operators D+ D- D* D/ etc. operate on these. There is a double-stack distinct from the data-stack. Doubles are an optional extension.

4.) A ratio is a 64-bit numerator (signed) and a 64-bit denominator (unsigned). If the numerator is zero, the value is zero. If the denominator is zero, the value is either positive infinity, zero or negative infinity depending upon if the numerator is positive, zero or negative. Ratios are on the double-stack along with the double-precision numbers. Ratios are an optional extension.

5.) A float is a 64-bit IEEE-754. The operators F+ F- F* F/ etc. operate on these. There is a float-stack and it is only 8 elements deep. Floats are an optional extension.

6.) A pointer is a 32-bit value in the top half of a cell (the lower 2GB is the dictionary and the upper 2GB is the heap). The low half of the cell is not used, but is usually zero.

7.) An xt (execution token) is a cell that contains two 32-bit pointers. The top half is a pointer to the code for the word. For a colon word, the low half is zero. For a quotation, the low half is a pointer to the local-frame of the parent function.

8.) A string is a cell that contains two 32-bit pointers. The top half is a pointer to the string. The low half is the count. The user never manually unpacks a string into pointer and count and never works with these explicitly. When a string is moved to the string stack it is unpacked. All work with strings is done on the string stack using standard operators that work with the pointer and count internally. The string stack is not optional --- it is part of the core standard and is used by core words such as: WORD <# #> etc..

------------------------------------------------------------------------------------------------------------

I have a lot of this already written in FASM assembly-language for the x86, but I don't have a system ready for release. Some of it (STRING-STACK.4TH) are written in ANS-Forth. Some of it (selectively smudging words) were written in UR/Forth.

Note that this has 32-bit pointers, but it runs on a 64-bit machine. This would make it difficult to implement an STC (subroutine-threaded-code) system.
The code I've written is ITC (indirect-threaded-code). The 32-bit pointers are not actually addresses in memory --- they are offsets from the base of a 4GB block of memory.
I like 32-bit pointers because the threaded code is 1/2 the size that it would be given 64-bit pointers. Most of the time, 4GB is adequate --- there are very few applications (mostly games with a lot of graphical images) that need more than 4GB.


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

Зарегистрирован: Сб дек 17, 2016 23:03
Сообщения: 60
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
This is a typical conversation on comp.lang.forth:

On Tuesday, December 19, 2017 at 4:44:15 PM UTC-7, Elizabeth D. Rather wrote:
> On 12/18/17 4:53 PM, dxforth@gmail.com wrote:
> > On Sunday, December 10, 2017 at 8:57:15 PM UTC+11, a...@littlepinkcloud.invalid wrote:
> >> Elizabeth D. Rather <erather@forth.com> wrote:
> >>
> >>> For the most part, at least the ones I'm in contact with are in the "if
> >>> it ain't broke, don't fix it" camp. They don't see much value in the
> >>> issues being debated. I can't speak for him, but I suspect that the
> >>> reason Leon participates is to try to minimize breakage.
> >>
> >> I don't speak for him either, but I'm pretty sure that's not the omly
> >> reason, even though it's surely a very big part of it.
> >>
> >> Andrew.
> >
> > Can you even pretend to have a 'Forth Standard'
> > without Forth Inc. Seems to me FI is there to
> > save friends from embarrassment. FI is stuck
> > 'between a rock and a hard place'.
>
> The major vendors are certainly necessary for a meaningful standard.
> FORTH, Inc. is committed to the process.
>
> Cheers,
> Elizabeth

This is why I have abandoned ANS-Forth and Forth-200x --- these standards have no purpose except to help sell the major vendor's products.

The good thing about Russians is that none of you are representing any "major vendor" --- a standard developed by Russians would represent Forth programmers, not sales-people.


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

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


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

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


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

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