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

...
Google Search
Forth-FAQ Spy Grafic

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




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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7047
Благодарил (а): 17 раз.
Поблагодарили: 116 раз.
HughAguilar писал(а):
1.) A "cell" (data-stack element) is 64-bit.


Yes. Currently we have 32/64 bits, and 64 is more attractive.

HughAguilar писал(а):
2.) A single-precision number is a 64-bit fixed-point value with unity = 2^32. The operators + - * / etc. operate on these.


This may be uncommon for most programmers. We should not forget integers as format 'by default'. Just take a look on independent Forth authors - what they prefer to implement? However, your proposal is another example of real demand, so fixed point definitely should be kept.

For this and other data format like this I can suggest to review my idea about explicitly defined operation (with prefixes) and smart +-*/ words. Note + and - are the same for both integers and fixed point.

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


Additional formats are welcomed. For the standard, it should be a described use case how to add another format and additional stack to store data, if needed.

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


Nothing to add. 8 cells is a hardware feature of 80387 and higher FPUs. Having 6 elements free maybe useful since two more usually used for printing and string->float conversion. Anyway, 8 elements are defined by FPU architecture.

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


For all of these, I just see alternatives. For example, low/high parts may be swapped by someone (and this solution still remains working). Maybe we should better to fix possible operations with pointers and strings and let hide details. Also we may not to hide details, by require Forth implementation must provide the same algorithms to create, store data, use etc. for pointers and string. I ay add file operations here because different approaches are possible. Your solution will be standard-compatible in this case, because you can provide the way to create string and this identifier may be used by words dealing with strings.

Question about 32/64 bits for pointer is not easy. We may also hide this problem declaring it implementation-defined, but I feel it is better to try first.

Finally, I think it is time to create some tests.


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

Зарегистрирован: Сб дек 17, 2016 23:03
Сообщения: 59
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
Hishnik писал(а):
HughAguilar писал(а):
1.) A "cell" (data-stack element) is 64-bit.

Yes. Currently we have 32/64 bits, and 64 is more attractive.

HughAguilar писал(а):
2.) A single-precision number is a 64-bit fixed-point value with unity = 2^32. The operators + - * / etc. operate on these.

This may be uncommon for most programmers. We should not forget integers as format 'by default'. Just take a look on independent Forth authors - what they prefer to implement? However, your proposal is another example of real demand, so fixed point definitely should be kept.

If a program assumes that unity is 1, the code will still work if unity is 2^32 --- the only problem is that the range of integers is 2^32 rather than 2^64, but this won't affect most numerical programs because such large integers are rare.

If we are going to assume that the processor is 64-bit (and we should, as all computers sold in the last 10 years are 64-bit), then it is more useful to set
unity = 2^32 than unity = 1.

Hishnik писал(а):
For this and other data format like this I can suggest to review my idea about explicitly defined operation (with prefixes) and smart +-*/ words. Note + and - are the same for both integers and fixed point.

I gave some reasons why I didn't like that idea.
I think our standard should be kept simple. We don't want "smart" words whose behavior is dependent upon context --- Forth has always been a simple language in the sense that words' behavior does not depend upon the context in which the words are used --- the book, "Thinking Forth" said: "Let the dictionary do the deciding."

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

Nothing to add. 8 cells is a hardware feature of 80387 and higher FPUs. Having 6 elements free maybe useful since two more usually used for printing and string->float conversion. Anyway, 8 elements are defined by FPU architecture.

For the most part, I want to define behavior rather than implementation, and make the standard suitable for any 64-bit processor. OTOH, the x86 does have the 8 element limitation, so our standard is much more practical if we just put this in the standard.

If we allow the float-stack to grow to any depth then we would require ourselves to write a complicated compiler that can work with deeper stacks by moving data in and out of memory --- the float stack is unlikely to grow beyond 8 elements in practice --- we would be requiring a lot of work to solve a problem that we created ourselves with our liberal allowance of a float stack that can grow to any depth, when the problem would have been unlikely to arise and the user can easily avoid the problem by holding float data in local variables rather than on the float-stack.

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

For all of these, I just see alternatives. For example, low/high parts may be swapped by someone (and this solution still remains working). Maybe we should better to fix possible operations with pointers and strings and let hide details. Also we may not to hide details, by require Forth implementation must provide the same algorithms to create, store data, use etc. for pointers and string. I ay add file operations here because different approaches are possible. Your solution will be standard-compatible in this case, because you can provide the way to create string and this identifier may be used by words dealing with strings.

Question about 32/64 bits for pointer is not easy. We may also hide this problem declaring it implementation-defined, but I feel it is better to try first.

Yes --- the standard should define behavior, not implementation --- so which datum is in the high or low half shouldn't be explicitly defined.

OTOH, we can't hide this entirely, because we are defining the cell size as 64-bit. You can't get more than 64 bits of data in a 64-bit cell without magic, and we don't want to support magic! ;-) This means that, if an xt is going to be one cell (64-bit) then a pointer has to be 32-bit (so the xt can contain a pointer to the code and a pointer to the local-frame).

This limitation can be dodged by making an xt two cells in size and holding it on the double-stack rather than the single-stack. This would be a pretty big change from ANS-Forth though --- this would confuse a lot of Forth programmers (including myself) --- I think it is best to stick with a one-cell xt and just accept the limitation that pointers are 32-bit.

A 32-bit pointer is actually a good thing because it saves memory. For example, a binary tree has a left and right pointer in each node. If the pointers are 32-bit, then the two pointers can be packed into one 64-bit cell --- if the pointers are 64-bit, then the two pointers require two cells --- this could save a lot of memory if the tree is large. Saving memory is a good thing because it reduces data-cache thrashing --- also, of course, it allows more data to be held in memory, which might be an issue because we are limiting ourselves to 2GB for the heap (although I can't think of any application that has this much data).

BTW: What did you think of Elizabeth Rather's assertion that a standard isn't "meaningful" unless she approves it? LOL Quite arrogant!


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7047
Благодарил (а): 17 раз.
Поблагодарили: 116 раз.
HughAguilar писал(а):
If a program assumes that unity is 1, the code will still work if unity is 2^32 --- the only problem is that the range of integers is 2^32 rather than 2^64, but this won't affect most numerical programs because such large integers are rare.


Hmm, you point me to the specific implementation here.

For adding, subtraction and all bitwise operations fixed point may be ignored and results will be correct. For multiplication, say 32.32 * 32.32 = 64.64, and we need to ignore lowest 32 bits to get correct result. Ok then, let's add a parameter, determines how digits after binary point we have (or just use 32 as a constant). In this case word * will shift result 32 or BINARY-POINT-POSITION (choose name you want) right. For integers, this value is zero, for fied point values it is not zero. Integer or fixed may be determined by tags or invoking special words before the code block, like DECIMAL HEX etc.

Код:
INTEGERS

A @ B @ * C !

32 FIXEDPOINT

Afixed @ Bfixed @ * Cfixed !


This will not break existing code with no fixed point support but allows to use the same * / words for this format if needed.

HughAguilar писал(а):
For the most part, I want to define behavior rather than implementation

I think it is key component of Forth planning. Defining implementation will lead to vendor-lock and 'true Forth implementers'.

HughAguilar писал(а):
If we allow the float-stack to grow to any depth then we would require ourselves to write a complicated compiler that can work with deeper stacks by moving data in and out of memory --- the float stack is unlikely to grow beyond 8 elements in practice --- we would be requiring a lot of work to solve a problem that we created ourselves with our liberal allowance of a float stack that can grow to any depth, when the problem would have been unlikely to arise and the user can easily avoid the problem by holding float data in local variables rather than on the float-stack.


x86 FPU is too powerful thing to be ignored for PC. Supporting 'extensible floating point stack' will suffer FP performance significantly. Math operations are important enough to slightly force programmers to think about hardware features and don't ask for too much comfort, if this cause huge negative impact on performance. I have a lot of code with floating point and never met a situation of FPU stack overflow.

HughAguilar писал(а):
This means that, if an xt is going to be one cell (64-bit) then a pointer has to be 32-bit (so the xt can contain a pointer to the code and a pointer to the local-frame).


I think we need to call the man familiar with frames and locals (I mean not abstract person, but certain user of this forum).

HughAguilar писал(а):
A 32-bit pointer is actually a good thing because it saves memory. For example, a binary tree has a left and right pointer in each node. If the pointers are 32-bit, then the two pointers can be packed into one 64-bit cell --- if the pointers are 64-bit, then the two pointers require two cells --- this could save a lot of memory if the tree is large. Saving memory is a good thing because it reduces data-cache thrashing --- also, of course, it allows more data to be held in memory, which might be an issue because we are limiting ourselves to 2GB for the heap (although I can't think of any application that has this much data).


I understand this explanation, but this is not trivial and we can build Forth with no support for all of this, right? So do we need to fix this behavior, or rather just think is it not behaves against the Standard?

HughAguilar писал(а):
BTW: What did you think of Elizabeth Rather's assertion that a standard isn't "meaningful" unless she approves it? LOL Quite arrogant!


Oh, I just want to see this! :) She can claim this, of course, but HOW she can prevent me (for example) from using Forth? Seriously, is it a kind of hypnosis? In addition, woman from USA, familiar with Obama (as she wrote), trying to dictate Russians what to do??!! :) Damn it, where is my warbear? :))


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

Зарегистрирован: Сб дек 17, 2016 23:03
Сообщения: 59
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
Hishnik писал(а):
HughAguilar писал(а):
If a program assumes that unity is 1, the code will still work if unity is 2^32 --- the only problem is that the range of integers is 2^32 rather than 2^64, but this won't affect most numerical programs because such large integers are rare.

Hmm, you point me to the specific implementation here.

For adding, subtraction and all bitwise operations fixed point may be ignored and results will be correct. For multiplication, say 32.32 * 32.32 = 64.64, and we need to ignore lowest 32 bits to get correct result. Ok then, let's add a parameter, determines how digits after binary point we have (or just use 32 as a constant). In this case word * will shift result 32 or BINARY-POINT-POSITION (choose name you want) right. For integers, this value is zero, for fied point values it is not zero. Integer or fixed may be determined by tags or invoking special words before the code block, like DECIMAL HEX etc.

You are over-complicating --- not realizing how simple arithmetic is --- there is no need for a tag on each datum (as done in Scheme/Lisp etc.) or "special words" to change the context.
I said a cell is 64-bit and we assume that unity is 2^32.

Addition and subtraction work as usual.

Multiplication needs to have the product adjusted by dividing it by unity (this is true also when unity is 1, but does not need to be done explicitly because dividing by 1 returns the same number).

Division needs to have the quotient adjusted by multiplying it by unity (this is true also when unity is 1, but does not need to be done explicitly because multiplying by 1 returns the same number).

I've already written this in FASM assembly-language --- it is trivial.

32-bit ANS-Forth or Quark programs can be easily ported to Adequate Forth --- these programs assume integers in the range of [0,2^32) --- coincidentally, Adequate Forth has the same range!
Adequate Forth also allows a fractional part in the range of [2^-32,0] but this doesn't prevent the old ANS-Forth or Quark Forth code from running correctly.
It will actually run better because in ANS-Forth or Quark Forth the fractional part of every quotient got truncated, whereas in Adequate Forth it is kept (32 bits).
Adequate Forth still has some limitations. If you have a repeating decimal such as 1/7 you only get 32 bits of the fractional part --- still, that is better than nothing!

Hishnik писал(а):
HughAguilar писал(а):
If we allow the float-stack to grow to any depth then we would require ourselves to write a complicated compiler that can work with deeper stacks by moving data in and out of memory --- the float stack is unlikely to grow beyond 8 elements in practice --- we would be requiring a lot of work to solve a problem that we created ourselves with our liberal allowance of a float stack that can grow to any depth, when the problem would have been unlikely to arise and the user can easily avoid the problem by holding float data in local variables rather than on the float-stack.

x86 FPU is too powerful thing to be ignored for PC. Supporting 'extensible floating point stack' will suffer FP performance significantly. Math operations are important enough to slightly force programmers to think about hardware features and don't ask for too much comfort, if this cause huge negative impact on performance. I have a lot of code with floating point and never met a situation of FPU stack overflow.

We agree on this then --- keep it simple and require an 8 element maximum on the float stack, corresponding to the x87 --- don't exert ourselves in solving a non-problem.

Hishnik писал(а):
HughAguilar писал(а):
This means that, if an xt is going to be one cell (64-bit) then a pointer has to be 32-bit (so the xt can contain a pointer to the code and a pointer to the local-frame).

I think we need to call the man familiar with frames and locals (I mean not abstract person, but certain user of this forum).

Hishnik писал(а):
HughAguilar писал(а):
A 32-bit pointer is actually a good thing because it saves memory. For example, a binary tree has a left and right pointer in each node. If the pointers are 32-bit, then the two pointers can be packed into one 64-bit cell --- if the pointers are 64-bit, then the two pointers require two cells --- this could save a lot of memory if the tree is large. Saving memory is a good thing because it reduces data-cache thrashing --- also, of course, it allows more data to be held in memory, which might be an issue because we are limiting ourselves to 2GB for the heap (although I can't think of any application that has this much data).

I understand this explanation, but this is not trivial and we can build Forth with no support for all of this, right? So do we need to fix this behavior, or rather just think is it not behaves against the Standard?

Yes --- this is an example of standardizing implementation rather than behavior, which is usually a mistake --- in this case though, it simplifies the compiler-writer's job significantly.
This implementation (a threaded system running on a 64-bit processor with 32-bit pointers) is easy to implement and provides reasonably good performance.
Adequate Forth (as the name implies) is just intended to be adequate. This is not a Forth standard that is intended to last for a century --- it may get replaced by a bigger and better Forth standard in the future --- right now, it is better to have an adequate standard (32-bit pointers) that works, rather than a dream for a future (64-bit pointers) that may never come and may not be needed.

Hishnik писал(а):
HughAguilar писал(а):
BTW: What did you think of Elizabeth Rather's assertion that a standard isn't "meaningful" unless she approves it? LOL Quite arrogant!

Oh, I just want to see this! :) She can claim this, of course, but HOW she can prevent me (for example) from using Forth? Seriously, is it a kind of hypnosis? In addition, woman from USA, familiar with Obama (as she wrote), trying to dictate Russians what to do??!! :) Damn it, where is my warbear? :))

Well, this is what she said:

On Tuesday, December 19, 2017 at 4:44:15 PM UTC-7, Elizabeth D. Rather wrote:
> The major vendors are certainly necessary for a meaningful standard.
> FORTH, Inc. is committed to the process.
>
> Cheers,
> Elizabeth

Note that "Cheers!" is what Americans say when they are raising their whiskey glasses in a toast.
Elizabeth Rather always ends her posts on comp.lang.forth with: "Cheers!" I think she is alcoholic.
Here she is claiming that Forth is not meaningful without Forth Inc.. This is very arrogant! Typically, such bloated arrogance is fueled by alcohol --- people don't make such grandiose claims when they are sober...

It is my hope that the Russians will be sober enough to work together for a meaningful standard --- don't make grandiose vodka-fueled claims about ruling the world --- just focus on defining a simple and usable standard for Forth.

I don't claim that Adequate Forth rules the world, or that I have the authority to dictate to every Forth programmer everywhere.
I am only suggesting Adequate Forth as a stepping-stone into the future.
The Forth community has never had a meaningful standard in the past (Forth-83) or the present (ANS-Forth), and it won't in the future either (if Forth-200x ever gets completed).
Adequate Forth can be designed before summer and a reference compiler written before next winter --- this will be the first meaning Forth standard --- this can be the first stepping-stone on the path to success for the Forth community.


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7047
Благодарил (а): 17 раз.
Поблагодарили: 116 раз.
HughAguilar писал(а):
I've already written this in FASM assembly-language --- it is trivial.

I know, but it will be hard to explain to implementers they must work with integers like with fixed point numbers. From the first look, integers are most intuitive data type and any other types should be added as an option. If we lay fixed point as the base, this certainly will lead to misunderstanding. Just imagine test with 2 2 + (4 ok) and 2 2 * (0 because 2 goes to the fractional part of stack, otherwise you must put all numbers into high part of 64-bit number), Anyway, you provoking programmers to impelent only integers because it is simpler than fixed point. At least they can do this and still keep Forth common behavior, so it seems to be done sooner or later. Standard should be unavoidable and really makes life easier :)

HughAguilar писал(а):
This is not a Forth standard that is intended to last for a century --- it may get replaced by a bigger and better Forth standard in the future --- right now, it is better to have an adequate standard (32-bit pointers) that works, rather than a dream for a future (64-bit pointers) that may never come and may not be needed.

Since you provide a sample of behavior, both of this (fixed point and pointers) needs to be taken into account. This is a good example of compromise solution, when alternatives can exist both or mutually exclusive and overall effect still kept positive.

HughAguilar писал(а):
It is my hope that the Russians will be sober enough to work together for a meaningful standard --- don't make grandiose vodka-fueled claims about ruling the world --- just focus on defining a simple and usable standard for Forth.

There is a simple fact: Russia is HUGE. We have a biggest territory in the world. The first idea to get something for us is go to dig somewhere in our lands, not to take from others. Throughout the history, an easy answer to oppression was to leave deeper in forests, steppes (or in Syberia). So 'live and let us lives'. Idea about ruling Russians minds is futile. For programmers, the first reaction on the new proposal is 'how to write the same and demonstrate my skills', not 'how to get it'. This is a problem indeed, because too many independent persons can't form a team. Nevermind.


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

Зарегистрирован: Сб дек 17, 2016 23:03
Сообщения: 59
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
Hishnik писал(а):
I know, but it will be hard to explain to implementers they must work with integers like with fixed point numbers. From the first look, integers are most intuitive data type and any other types should be added as an option. If we lay fixed point as the base, this certainly will lead to misunderstanding. Just imagine test with 2 2 + (4 ok) and 2 2 * (0 because 2 goes to the fractional part of stack, otherwise you must put all numbers into high part of 64-bit number), Anyway, you provoking programmers to impelent only integers because it is simpler than fixed point. At least they can do this and still keep Forth common behavior, so it seems to be done sooner or later. Standard should be unavoidable and really makes life easier :)

Keep common behavior???

I explained above that the behavior is the same whether unity is 2^32 or 1.
The only difference is the range of values that you can use.
With 64-bit cells and unity = 2^32 you get a range for the integer part that is the same as you would have gotten with 32-bit cells and unity = 1. So, programs written assuming a 32-bit cell and unity = 1 (Quark Forth, VFX, SwiftForth, etc., which are all 32-bit) will behave the same as they did before (except that division will not truncate the quotient as before, but will provide a fractional part for better precision than before).

Hishnik писал(а):
There is a simple fact: Russia is HUGE. We have a biggest territory in the world. The first idea to get something for us is go to dig somewhere in our lands, not to take from others. Throughout the history, an easy answer to oppression was to leave deeper in forests, steppes (or in Syberia). So 'live and let us lives'. Idea about ruling Russians minds is futile. For programmers, the first reaction on the new proposal is 'how to write the same and demonstrate my skills', not 'how to get it'. This is a problem indeed, because too many independent persons can't form a team. Nevermind.

I'm not preventing independent persons from being creative and writing their own non-standard Forth with fancy features. Adequate Forth is intended to allow portable programs. You don't get fancy features --- you get a simple and useful Forth --- you get to write simple and useful Forth programs that are portable between various compliant Forth systems.

Here in America, we have a lot of Mexicans (many independent persons, just like the Russians). Almost all of the Mexicans own a Chevrolet Silverado pickup truck however. It is very versatile and can be used for almost any purpose. It is mostly a work truck though.
If you want to go to a fancy restaurant, it will get you there but will not impress people; you are better off with a Mercedes car.
If you want to drive off-road, it will do this but is not the best; you are better off with a Jeep or Toyota Tacoma.
If you want to drive fast, it will do this but is not the best; you are better off with a sports car.
If you want to transport a large family, it will do this but it will require some of them to ride in the back; you are better off with a station-wagon or SUV.

Think of Adequate Forth as a basic vehicle that is for simple (and hopefully useful) work --- primarily cross-compilation --- you can have another Forth standard that is more fancy or has some other features that are useful to you (for example, better support for numeric programming).

Primarily, the goal is that Adequate Forth can be used as the host system for cross-compilers. Forth-83 failed at this (I had to upgrade UR/Forth with a few non-standard features to support MFX). ANS-Forth was worse than Forth-83 in almost every way; it was an epic failure. Forth-200x is mandated to be 100% compatible with ANS-Forth, so it is guaranteed to fail too. The goal of supporting cross-compilation is not difficult though --- this can be achieved within a matter of a few months --- most of the needed features are easy to describe and trivial to implement.

I am adding a few new features that are not needed for cross-compilation.

1.) I am requiring the cell size to be 64-bit, rather than allow it to be any size (16-bit, 32-bit or 64-bit) as in ANS-Forth, and I'm setting unity at 2^32 rather than 1 so numbers can have a fractional part. This is very useful for simple numeric programs (specifically for CNC machines, such as lathes and milling machines, which I have some experience with).

2.) I'm providing a string-stack (I've written this already in ANS-Forth) that gives the user a place to store strings temporarily. By making this part of the core, rather than an extension library, I allow core words such as <# #> and WORD to use the string-stack rather than static buffers like in ANS-FORTH.

3.) I'm providing quotations that access the parent function's local variables despite the fact that the HOF (higher-order-function) that is executing the quotation may have local variables of its own. This is done to support general-purpose data-structures.

These extra features seem worthwhile, despite the fact that they aren't necessary for cross-compilation. Without these extra features, Adequate Forth would only be a slight upgrade on Forth-83 --- considering that this is the year 2017, we don't want to go all the way back to Forth-83 again --- a few extra features are good, especially if they are easy to describe and trivial to implement.


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7047
Благодарил (а): 17 раз.
Поблагодарили: 116 раз.
HughAguilar писал(а):
I explained above that the behavior is the same whether unity is 2^32 or 1.
The only difference is the range of values that you can use.
With 64-bit cells and unity = 2^32 you get a range for the integer part that is the same as you would have gotten with 32-bit cells and unity = 1. So, programs written assuming a 32-bit cell and unity = 1 (Quark Forth, VFX, SwiftForth, etc., which are all 32-bit) will behave the same as they did before (except that division will not truncate the quotient as before, but will provide a fractional part for better precision than before).

Ok, I see you point here. This is not too deeply integrated part of Forth, so can be tuned later.

HughAguilar писал(а):
Think of Adequate Forth as a basic vehicle that is for simple (and hopefully useful) work --- primarily cross-compilation --- you can have another Forth standard that is more fancy or has some other features that are useful to you (for example, better support for numeric programming).


I plan to test it on my tasks - primarly it is focused on some math with intensive FP calculations and cross-compilation for embedded and FPGA. This will not cover all Forth niches, and this is why we still need to involve motivated programmers to write sample code for tasks of different kinds.


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

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

SP-Forth, Win32Forth, etc., lack support for cross-compilation.
It is important to have LITERAL DLITERAL and FLITERAL vectored so TARG words can have literal numbers in them. This was outlawed in ANS-Forth. There are other features that are useful for cross-compilation, such as VOCNO@ and VOCNO! for fetching and storing the vocabulary number given the xt. Also, IMMEDIATE@ and IMMEDIATE! for fetching and storing the immediate flag given the xt. There some other features as well, all of which are easy to describe and trivial to implement --- everything useful was outlawed in ANS-Forth though.

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

VFX and SwiftForth are both 32-bit x86 Forth systems. The 32-bit x86 has been obsolete for at least a decade now though.
It is pointless to come out with another 32-bit x86 Forth system that will be a decade obsolete on its first day. Making Adequate Forth 64-bit will make VFX and SwiftForth look foolish.

There is a 64-bit x86 Gforth (I'm told). This is nonsense though! Gforth is still ANS-Forth which means that unity = 1, so they still have no fractional part on their numbers. Making Adequate Forth assume unity = 2^32 will make Gforth look foolish.

It is not difficult to make the ANS-Forth and Forth-200x supporters look foolish. ;-)
All of the features of Adequate Forth that I'm describing are easy to describe and trivial to implement.

KPG писал(а):

What you see there is very old --- I released that in 2010, if I recall correctly.
I have a lot more now. I have STRING-STACK.4TH written. I also have a merge-sort for lists. I have <SWITCH FAST-SWITCH> written that is like CASE but generates a sparse jump-table, and SLOW-SWITCH> that generates a packed jump-table and uses BSEARCH to find the vector. I have disambiguifiers that fix the problem in ANS-Forth of FIND being ambiguous. I have an early-binding MACRO: now that replaces the late-binding MACRO: in the old package. I have a lot of new features.

I haven't released the new version of the novice-package --- I may not bother --- everybody on comp.lang.forth hates it.
Why should I support ANS-Forth? This is giving Elizabeth Rather's toy language more credibility than it deserves.


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7047
Благодарил (а): 17 раз.
Поблагодарили: 116 раз.
HughAguilar писал(а):
SP-Forth, Win32Forth, etc., lack support for cross-compilation.
It is important to have LITERAL DLITERAL and FLITERAL vectored so TARG words can have literal numbers in them. This was outlawed in ANS-Forth. There are other features that are useful for cross-compilation, such as VOCNO@ and VOCNO! for fetching and storing the vocabulary number given the xt. Also, IMMEDIATE@ and IMMEDIATE! for fetching and storing the immediate flag given the xt. There some other features as well, all of which are easy to describe and trivial to implement --- everything useful was outlawed in ANS-Forth though


I wonder why ANS (and SPF team) are so stubborn making some words vectored. They have a clear way to add cross-compilation domain to the existing Forth, but they are refuse to do this. This is an example of provoking programmers to abandon ANS.

HughAguilar писал(а):
VFX and SwiftForth are both 32-bit x86 Forth systems. The 32-bit x86 has been obsolete for at least a decade now though.
It is pointless to come out with another 32-bit x86 Forth system that will be a decade obsolete on its first day. Making Adequate Forth 64-bit will make VFX and SwiftForth look foolish.

Yes, we have an era of 64-bit systems....

HughAguilar писал(а):
This is nonsense though! Gforth is still ANS-Forth which means that unity = 1, so they still have no fractional part on their numbers.

I see your point about fractional part, but just want to be careful with this. Reviewing of practical approaches to support 32.32 fixed point numbers, I see it can be made optional by some #defines and conditional compilation.

I hope in the several days I will be able to speak to my team what they expect from the new generation of 'mainstream Forth'. Quark is used active enough, so I need to provide a new tool with backward compatibility and actual new features.


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

Зарегистрирован: Сб дек 17, 2016 23:03
Сообщения: 59
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
Hishnik писал(а):
HughAguilar писал(а):
SP-Forth, Win32Forth, etc., lack support for cross-compilation.
It is important to have LITERAL DLITERAL and FLITERAL vectored so TARG words can have literal numbers in them. This was outlawed in ANS-Forth. There are other features that are useful for cross-compilation, such as VOCNO@ and VOCNO! for fetching and storing the vocabulary number given the xt. Also, IMMEDIATE@ and IMMEDIATE! for fetching and storing the immediate flag given the xt. There some other features as well, all of which are easy to describe and trivial to implement --- everything useful was outlawed in ANS-Forth though

I wonder why ANS (and SPF team) are so stubborn making some words vectored. They have a clear way to add cross-compilation domain to the existing Forth, but they are refuse to do this. This is an example of provoking programmers to abandon ANS.

A lot of words can be defined with a default behavior, but also defined to be vectored so the user can change the behavior.
I think it is a bad idea for the user to willy-nilly change the behavior of words --- this makes code context-sensitive --- one of Forth's virtues is that code is not context-sensitive.
I also think that most Forth programmers are smart enough to understand this and avoid trouble --- cross-compilers are exceptional in needing this feature --- but in general it should be avoided.
Cars are sold with many features, including the ability to go 100 mph --- most drivers are smart enough not to do this in general --- if they do this and get in trouble, it is there own fault.
We could make a note in the documentation: "You should not use this feature unless you really want to."

Hishnik писал(а):
HughAguilar писал(а):
VFX and SwiftForth are both 32-bit x86 Forth systems. The 32-bit x86 has been obsolete for at least a decade now though.
It is pointless to come out with another 32-bit x86 Forth system that will be a decade obsolete on its first day. Making Adequate Forth 64-bit will make VFX and SwiftForth look foolish.

Yes, we have an era of 64-bit systems....

HughAguilar писал(а):
This is nonsense though! Gforth is still ANS-Forth which means that unity = 1, so they still have no fractional part on their numbers.

I see your point about fractional part, but just want to be careful with this. Reviewing of practical approaches to support 32.32 fixed point numbers, I see it can be made optional by some #defines and conditional compilation.

I hope in the several days I will be able to speak to my team what they expect from the new generation of 'mainstream Forth'. Quark is used active enough, so I need to provide a new tool with backward compatibility and actual new features.

Is Quark Forth 64-bit?


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7047
Благодарил (а): 17 раз.
Поблагодарили: 116 раз.
HughAguilar писал(а):
Is Quark Forth 64-bit?

No. I start 64-bit version some time ago, but it were no real demands on 64-bit inside Forth engine.


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

Зарегистрирован: Сб дек 17, 2016 23:03
Сообщения: 59
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
Hishnik писал(а):
I hope in the several days I will be able to speak to my team what they expect from the new generation of 'mainstream Forth'. Quark is used active enough, so I need to provide a new tool with backward compatibility and actual new features.

I don't think Adequate Forth should be a super-set of Quark Forth.
The name "Adequate Forth" implies that it is quite basic and is adequate for simple programs --- primarily that it is adequate for a cross-compiler.

I said that Stephen Pelc is going to use his position as chairman of the Forth-200x committee to declare VFX to be the new standard, and declare everybody else to be non-standard.
You sound like you want to declare Quark Forth to be the new standard --- that is not my goal though --- I want a quite basic standard that is adequate for cross-compilation.

Quark Forth is a big Forth system. How many people are going to implement a compatible Forth system? That would be a lot of work! The concept of portable programs is only meaningful if there are multiple compliant Forth systems available that programs can be ported between. Adequate Forth should be basic enough that multiple people can implement compatible Forth systems with only a little work --- if they are ambitious and creative they can write extension libraries on top of the basic system --- simple programs will be portable, but big programs that require fancy features are not necessarily going to be portable.

Adequate Forth should be close to Quark Forth so programs can be ported with only a little work --- there should not be any incompatibilities that were introduced by accident (because I'm not familiar with Quark Forth) --- but this doesn't mean that Quark Forth is the new standard without any trimming.


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

Зарегистрирован: Сб дек 17, 2016 23:03
Сообщения: 59
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
HughAguilar писал(а):
The concept of portable programs is only meaningful if there are multiple compliant Forth systems available that programs can be ported between. Adequate Forth should be basic enough that multiple people can implement compatible Forth systems with only a little work ...

Over on comp.lang.forth I said this:

On Monday, December 25, 2017 at 5:52:13 PM UTC-7, hughag...@gmail.com wrote:
> On Monday, December 25, 2017 at 4:41:27 PM UTC-7, dxf...@gmail.com wrote:
> > On Monday, December 25, 2017 at 4:07:42 AM UTC+11, Elizabeth D. Rather wrote:
> > > FORTH, Inc. tries very hard to document its implementation dependencies
> > > and other such things. If programmers want to write portable programs
> > > with relatively few dependencies I think it's possible.
>
> Documenting implementation dependencies doesn't make programs portable --- this is just documentation of failure --- in case anybody hadn't already noticed.
>
> > > However, I'm not really sure there's really the desire. Same is true
> > > about libraries. If Forth programmers were really making the attempt to
> > > publish library functions or portable programs, we'd here more about
> > > their successes and failures and needs, rather than the kinds of issues
> > > and complaints we do have. People here complain that there are no
> > > standard programs or libraries, but I don't see them actually trying to
> > > write any; it's all a clamor that "someone" should. Instead, most clf
> > > programmers seem to be most concerned with maintaining their own
> > > idiosyncratic Forth variants.
>
> Everything in the novice-package is portable ANS-Forth.
> The only exception is rquotations, but I documented this --- it should be trivial to make rquotations work on any Forth system.
>
> > Finally, an admission of the unlikelihood of
> > the standard ever being used to write portable
> > programs. It was hardly a secret. So we have
> > Forth Inc 'committed to a process' whose goals
> > are unstated, if not unknown.
>
> All corporations' goal is to increase their own profit --- usually this involves wrecking the competition rather than making a better product.
> This fact is not "unknown" --- it is well known --- it doesn't need to be stated.
> A corporation is the worst possible choice for writing a language standard --- corporations don't want portability of programs between Forth systems ---
> corporations want the other Forth systems to go out of business so they can have a monopoly.
> When Anton Ertl was the Forth-200x chair-person, Forth-200x had the appearance of being an academic pursuit (fake though, as he was appointed by Forth Inc.).
> Now that Stephen Pelc is the Forth-200x chair-person, this appearance has been discarded. Forth-200x is a corporate project --- a marketing gimmick.
>
> The word "standard" has two meanings in English:
>
> 1.) A standard allows programs to be ported between compliant Forth systems, so long as the programs limit themselves to the standard word-set.
>
> 2.) A standard is important.
>
> Elizabeth Rather is using the #2 definition --- she is saying that she is very important --- she is saying that Forth isn't meaningful without Forth Inc..
>
> Similarly, when GM demanded (and obtained) a huge bailout, they were saying that they were very important ---
> they were saying that America isn't meaningful without GM.
>
> GM cars are actually very low-quality compared to Japanese or German cars.
> Similarly, SwiftForth is very low-quality compared to every other Forth system available (except Gforth that was purposely crippled to make it worse).
>
> Sales people tend to have gigantic egos. They really believe that they are very important! They actually contribute nothing positive to the world though.
> Elizabeth Rather has never made a positive contribution --- she has never written any Forth code --- she just copies example code from: "Starting Forth"
> Forth Inc. has always been an embarrassment to the Forth community --- PolyForth and SwiftForth are crap --- this makes Forth seem to be meaningless.

P.S. Merry Christmas! :-)
I don't know if Russians celebrate Christmas or not --- you didn't during the bad old days of communism.
I have read that Joseph Stalin's daughter enjoyed herself so much at a Christmas celebration (outside of Russia) that he relented and allowed Christmas in Russia, but edited out the religious aspects (Santa Claus became "Father Winter," nobody could put a Star of Bethlehem on their tree, and there was definitely no mention of "you know who" that was supposedly born that day).
I'm not actually a Christian myself --- I do like Christmas though --- it is a jolly merry time of year, although the commercialism from the stores selling gifts does annoy me.


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

Зарегистрирован: Вт май 02, 2006 22:48
Сообщения: 7047
Благодарил (а): 17 раз.
Поблагодарили: 116 раз.
HughAguilar писал(а):
The name "Adequate Forth" implies that it is quite basic and is adequate for simple programs --- primarily that it is adequate for a cross-compiler.

Cross-compiler looks like very good testbed for a new Forth.

HughAguilar писал(а):
You sound like you want to declare Quark Forth to be the new standard --- that is not my goal though --- I want a quite basic standard that is adequate for cross-compilation.

No, of course not. Changing master don't equal to be free :) I want to use the adequate standard as a base of my product, because I'm clearly understand my requirements may be incompatible with requirements of other users. For this purpose, a standard should be extendabe and provide enough flexibility to target different domains. Simple, we need to stop at the right line.

HughAguilar писал(а):
Quark Forth is a big Forth system. How many people are going to implement a compatible Forth system?

Indeed there was a lot of add-ons to Quark while using for particular projects. Core has grown for about quarter while many words were used from one project to another and finally wrote in Fasm. This is not a mandatory part. I rather want to other people to lead same way and complete their own Forth core, understanding their requirements and trade-offs. In this case, we will be able to find common points. Choosing the best fetish to pray is useless.

HughAguilar писал(а):
P.S. Merry Christmas!


Thank you! Indeed we should celebrate you, since Russian Orthodox Church has a Christmas at 7 Jan. Russian Christianity strongly positioned as descendent of Eastern Rome Christianity opposing to Rome Orthodox Church, so old-style calendar is a point of highlighting differencies.

HughAguilar писал(а):
I have read that Joseph Stalin's daughter enjoyed herself so much at a Christmas celebration (outside of Russia) that he relented and allowed Christmas in Russia, but edited out the religious aspects (Santa Claus became "Father Winter," nobody could put a Star of Bethlehem on their tree, and there was definitely no mention of "you know who" that was supposedly born that day).

We here will have a great celebration at the midnight 31 Dec, the calendar New Year. This is neutral to religion celebration and almost all Christmas ceremonies are just copied to the New Year (gifts, Christmas tree, and Russian analog of Santa Claus).


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

Зарегистрирован: Сб дек 17, 2016 23:03
Сообщения: 59
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
Hishnik писал(а):
HughAguilar писал(а):
The name "Adequate Forth" implies that it is quite basic and is adequate for simple programs --- primarily that it is adequate for a cross-compiler.

Cross-compiler looks like very good testbed for a new Forth.

Yes! A cross-compiler is easy --- I upgraded UR/Forth with only one small file of assembly-language specific to UR/Forth --- cross-compilation is a goal that can be achieved!
(note that ANS-Forth has been failing at this easy goal since 1994, and Forth-200x continues to fail...)

With Adequate Forth I am adding a few new features. Supporting cross-compilation is too easy --- some extra features will make Adequate Forth reasonably useful in general.
For example, the string-stack is needed. This can't be an optional extension because it needs to be used by core words such as <# #> WORD etc. --- I've already written the code in ANS-Forth, so it should be easy to include.

Note that my STRING-STACK.4TH is much better than Wil Baden's string-stack. I have Copy-On-Write (COW). We have unique strings that are on the heap, and derivative strings that are a reference to a unique string. Derivative strings don't get converted into unique strings unless necessary. If your code mostly uses derivative strings (such as for pattern matching) then the code is manipulating references internally --- this is much faster than allocating a memory-block on the heap, copying a string over to the memory block, and eventually freeing the memory-block from the heap. The user just assumes that everything is unique, and does not need to worry about whether some strings are actually derivative. STRING-STACK.4TH is some of the best Forth code I've written in years --- of course, the comp.lang.forth crowd says that it is useless and stupid, and that if I knew anything about computer programming I would have written a regular-expression package instead.

I hope I don't sound too boastful, but my Forth code is superior in every way to anything that the Forth-200x committee has written, in every category --- their Forth-200x is hugely bloated with useless features (regular expressions, for example) --- despite its ponderous size, it still fails to be adequate for simple tasks!

We want to make Adequate Forth as small as possible though. If features can be made optional, they should be made optional. The core should be quite small --- only what is necessary to be adequate --- the core should be small enough to be easily documented and easily implemented (everything straight-forward and obvious; no tricky features that boggle the mind).

If you look at a Van Gogh painting, you will see that it is quite simple. This is different from artists who strive to paint detailed portraits (they became obsolete with the invention of the camera).
Here is an example:
https://www.google.com/culturalinstitut ... 9994%7D%7D

Hishnik писал(а):
HughAguilar писал(а):
You sound like you want to declare Quark Forth to be the new standard --- that is not my goal though --- I want a quite basic standard that is adequate for cross-compilation.

No, of course not. Changing master don't equal to be free :)

I'm impressed! You understood my words!

The problem so far is too much desire to be a master and not enough desire to form a community --- by thinking in terms of forming a community, we can succeed.

Anybody who declares him or herself to be the great master will fail --- this has already been tried, and the result was that Forth fell from being popular (in the 1980s) to being almost totally unknown (post-1994).

Start small with Adequate Forth, making it adequate for cross-compilation and a few simple programs --- don't try to conquer the world in one day --- the core has to be accepted first, before anybody writes any optional extension package.


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

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


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

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


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

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