Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #44560 > unrolled thread

DurexForth v1.5.0

Back to article view | Back to comp.lang.forth

Contents

  DurexForth v1.5.0 Johan Kotlinski <kotlinski@gmail.com> - 2016-01-04 15:08 -0800
    Re: DurexForth v1.5.0 hughaguilar96@gmail.com - 2016-01-04 20:54 -0800
      Re: DurexForth v1.5.0 Johan Kotlinski <kotlinski@gmail.com> - 2016-01-05 00:48 -0800
        Re: DurexForth v1.5.0 rickman <gnuarm@gmail.com> - 2016-01-05 04:40 -0500
          Re: DurexForth v1.5.0 Johan Kotlinski <kotlinski@gmail.com> - 2016-01-05 02:53 -0800
            Re: DurexForth v1.5.0 rickman <gnuarm@gmail.com> - 2016-01-05 09:19 -0500
              Re: DurexForth v1.5.0 Chris Curl <ccurl609@gmail.com> - 2016-01-05 08:44 -0800
                Re: DurexForth v1.5.0 rickman <gnuarm@gmail.com> - 2016-01-05 11:53 -0500
                  Re: DurexForth v1.5.0 Chris Curl <ccurl609@gmail.com> - 2016-01-05 10:28 -0800
                    Re: DurexForth v1.5.0 rickman <gnuarm@gmail.com> - 2016-01-05 14:12 -0500
                      Re: DurexForth v1.5.0 Paul Rubin <no.email@nospam.invalid> - 2016-01-05 11:16 -0800
                        Re: DurexForth v1.5.0 rickman <gnuarm@gmail.com> - 2016-01-05 14:58 -0500
                          Re: DurexForth v1.5.0 Paul Rubin <no.email@nospam.invalid> - 2016-01-05 12:03 -0800
                            Re: DurexForth v1.5.0 rickman <gnuarm@gmail.com> - 2016-01-05 15:10 -0500
                              Re: DurexForth v1.5.0 Paul Rubin <no.email@nospam.invalid> - 2016-01-05 12:36 -0800
                                Re: DurexForth v1.5.0 rickman <gnuarm@gmail.com> - 2016-01-05 16:34 -0500
                      Re: DurexForth v1.5.0 Johan Kotlinski <kotlinski@gmail.com> - 2016-01-05 13:42 -0800
                        Re: DurexForth v1.5.0 hughaguilar96@gmail.com - 2016-01-05 16:40 -0800
                          Re: DurexForth v1.5.0 Johan Kotlinski <kotlinski@gmail.com> - 2016-01-05 18:13 -0800
                            Re: DurexForth v1.5.0 "Elizabeth D. Rather" <erather@forth.com> - 2016-01-05 16:27 -1000
                            Re: DurexForth v1.5.0 Paul Rubin <no.email@nospam.invalid> - 2016-01-05 18:59 -0800
                              Re: DurexForth v1.5.0 Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-05 22:47 -0800
                                Re: DurexForth v1.5.0 "Elizabeth D. Rather" <erather@forth.com> - 2016-01-05 21:37 -1000
                                  Re: DurexForth v1.5.0 Paul Rubin <no.email@nospam.invalid> - 2016-01-06 00:14 -0800
                                    Re: DurexForth v1.5.0 Ron Aaron <rambamist@gmail.com> - 2016-01-06 10:32 +0200
                                      Re: DurexForth v1.5.0 Paul Rubin <no.email@nospam.invalid> - 2016-01-06 00:42 -0800
                                        Re: DurexForth v1.5.0 Ron Aaron <rambamist@gmail.com> - 2016-01-06 11:02 +0200
                                          Re: DurexForth v1.5.0 Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-06 01:51 -0800
                                            Re: DurexForth v1.5.0 Ron Aaron <rambamist@gmail.com> - 2016-01-06 12:02 +0200
                                      Re: DurexForth v1.5.0 Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2016-01-06 10:46 +0000
                                        Re: DurexForth v1.5.0 Ron Aaron <rambamist@gmail.com> - 2016-01-06 12:49 +0200
                                        Re: DurexForth v1.5.0 Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-06 03:12 -0800
                                          Re: DurexForth v1.5.0 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-06 18:21 +0000
                                            Re: DurexForth v1.5.0 Johan Kotlinski <kotlinski@gmail.com> - 2016-01-06 22:57 -0800
                                              Re: DurexForth v1.5.0 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-07 08:47 +0000
                                      Re: DurexForth v1.5.0 Coos Haak <chforth@hccnet.nl> - 2016-01-06 13:39 +0100
                                        Re: DurexForth v1.5.0 Ron Aaron <rambamist@gmail.com> - 2016-01-06 14:45 +0200
                                  Re: DurexForth v1.5.0 Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-06 12:48 +0000
                                  Re: DurexForth v1.5.0 Syd Rumpo <usenet@nononono.co.uk> - 2016-01-07 11:09 +0000
                                Re: DurexForth v1.5.0 hughaguilar96@gmail.com - 2016-01-06 22:57 -0800
          Re: DurexForth v1.5.0 no.top.post@gmail.com - 2016-01-14 12:45 +0000
    Re: DurexForth v1.5.0 anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-05 10:37 +0000
      Re: DurexForth v1.5.0 Johan Kotlinski <kotlinski@gmail.com> - 2016-01-05 03:08 -0800
    Re: DurexForth v1.5.0 Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2016-01-06 12:22 +0100
      Re: DurexForth v1.5.0 Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-06 13:08 +0000
    Re: DurexForth v1.5.0 Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-07 03:14 -0500

Page 1 of 3  [1] 2 3  Next page →

#44560 — DurexForth v1.5.0

Hi all,
sorry to disturb, I have been lurking here some years while developing my own toy Forth. It's a subroutine-threaded Forth for the C64.

A few months ago I started working on Forth 2012 standard compliance, and now released a version that passes 99% of the core standard tests. If you are interested, you can try it out here: https://github.com/jkotlinski/durexforth/releases/tag/v1.5.0

Overall, the Forth 2012 web site and tests have been a great resource. I learned a lot and now DurexForth is also more enjoyable to use.

Unfortunately there is one part of the standard that seems really like a bad idea for me to follow, so I would like to pass in some criticism here. It is the enforcing of ASCII that sits bad, since the C64 naturally uses PETSCII. It bothers me why the Forth standard, which is so flexible in many other areas, should be so specific about this? The C standard does well without this requirement.

Regards
Johan

[toc] | [next] | [standalone]

#44570

On Monday, January 4, 2016 at 4:09:00 PM UTC-7, Johan Kotlinski wrote:
> Unfortunately there is one part of the standard that seems really like a bad idea for me to follow, so I would like to pass in some criticism here. It is the enforcing of ASCII that sits bad, since the C64 naturally uses PETSCII. It bothers me why the Forth standard, which is so flexible in many other areas, should be so specific about this? The C standard does well without this requirement.

This seems reasonable --- so long as a char is 8-bit, there is no reason why it has to be any particular character coding --- we have the words SPACE and CR that abstractify blanks and carriage-controls, so they don't have to be any particular code.

As I recall, PETSCII was an 8-bit extended version of ASCII, with the lower half being ascii and the upper half being all the extension chars --- there are several 8-bit extended versions of ASCII in use nowadays.

[toc] | [prev] | [next] | [standalone]

#44575

On Tuesday, January 5, 2016 at 5:55:00 AM UTC+1, hughag...@gmail.com wrote:
> This seems reasonable --- so long as a char is 8-bit, there is no reason why it has to be any particular character coding --- we have the words SPACE and CR that abstractify blanks and carriage-controls, so they don't have to be any particular code.
> 
> As I recall, PETSCII was an 8-bit extended version of ASCII, with the lower half being ascii and the upper half being all the extension chars --- there are several 8-bit extended versions of ASCII in use nowadays.

Well, PETSCII is distinctly different from ASCII also in the lower half. For example, the code ranges for a-z, A-Z are moved. This is perfectly fine with C, since it only requires essential characters to be defined, and that the a-z A-Z 0-9 ranges are internally sequential. To me that seems like a nice way to do it. On the flip side, I do not see any benefit of user programs assuming ASCII. It is easier to write '!' than 33 (ASCII code for !).

This is not a huge deal for me, since all it means is that I would have to apply the tag "with Environmental Restrictions" whenever I make the bold claim that my Forth is a "Standard System". However I would like to raise the issue. Maybe there is something I overlooked.

Rgrds
Johan

[toc] | [prev] | [next] | [standalone]

#44576

On 1/5/2016 3:48 AM, Johan Kotlinski wrote:
> On Tuesday, January 5, 2016 at 5:55:00 AM UTC+1, hughag...@gmail.com
> wrote:
>> This seems reasonable --- so long as a char is 8-bit, there is no
>> reason why it has to be any particular character coding --- we have
>> the words SPACE and CR that abstractify blanks and
>> carriage-controls, so they don't have to be any particular code.
>>
>> As I recall, PETSCII was an 8-bit extended version of ASCII, with
>> the lower half being ascii and the upper half being all the
>> extension chars --- there are several 8-bit extended versions of
>> ASCII in use nowadays.
>
> Well, PETSCII is distinctly different from ASCII also in the lower
> half. For example, the code ranges for a-z, A-Z are moved. This is
> perfectly fine with C, since it only requires essential characters to
> be defined, and that the a-z A-Z 0-9 ranges are internally
> sequential. To me that seems like a nice way to do it. On the flip
> side, I do not see any benefit of user programs assuming ASCII. It is
> easier to write '!' than 33 (ASCII code for !).
>
> This is not a huge deal for me, since all it means is that I would
> have to apply the tag "with Environmental Restrictions" whenever I
> make the bold claim that my Forth is a "Standard System". However I
> would like to raise the issue. Maybe there is something I
> overlooked.

If the C64 does not use ASCII it would have a hard time exchanging text 
files with the rest of the computer world, no?  I can't imagine why it 
would be useful to not use the 128 ASCII codes.  One time it would be an 
issue is when converting from ASCII-hex to integers.  It is not uncommon 
to hard code the conversion constants as numbers rather than use the 
ASCII characters.  This would be broken on the C64 I expect.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#44578

On Tuesday, January 5, 2016 at 10:39:59 AM UTC+1, rickman wrote:
> If the C64 does not use ASCII it would have a hard time exchanging text 
> files with the rest of the computer world, no?  I can't imagine why it
> would be useful to not use the 128 ASCII codes.

Using ASCII might make it easier to exchange text files with the rest of the world, but it would make the situation awkward locally on the C64. For example, PETSCII is printed on the keyboard, used by kernal I/O routines, and also by the file system. Not to mention, adding PETSCII/ASCII conversion would waste precious RAM.

> would be useful to not use the 128 ASCII codes.  One time it would be an 
> issue is when converting from ASCII-hex to integers.

For the general case, it should be enough to use >number for converting strings to integers..? This is not something that needs to be done by hand by the user...

Johan

[toc] | [prev] | [next] | [standalone]

#44583

On 1/5/2016 5:53 AM, Johan Kotlinski wrote:
> On Tuesday, January 5, 2016 at 10:39:59 AM UTC+1, rickman wrote:
>> If the C64 does not use ASCII it would have a hard time exchanging
>> text files with the rest of the computer world, no?  I can't
>> imagine why it would be useful to not use the 128 ASCII codes.
>
> Using ASCII might make it easier to exchange text files with the rest
> of the world, but it would make the situation awkward locally on the
> C64. For example, PETSCII is printed on the keyboard, used by kernal
> I/O routines, and also by the file system. Not to mention, adding
> PETSCII/ASCII conversion would waste precious RAM.

That makes no sense.  If the 64 used ASCII, it would use it across the 
board.


>> would be useful to not use the 128 ASCII codes.  One time it would
>> be an issue is when converting from ASCII-hex to integers.
>
> For the general case, it should be enough to use >number for
> converting strings to integers..? This is not something that needs to
> be done by hand by the user...



-- 

Rick

[toc] | [prev] | [next] | [standalone]

#44589

On Tuesday, January 5, 2016 at 9:19:57 AM UTC-5, rickman wrote:
> 
> That makes no sense.  If the 64 used ASCII, it would use it across the 
> board.
I think the point is that the other C64 subsystems use PETSCII as well
(e.g. - displaying a character on the screen), so in order to make them 
behave as expected, a translation would need to be performed at all those
integration points.

[toc] | [prev] | [next] | [standalone]

#44590

On 1/5/2016 11:44 AM, Chris Curl wrote:
> On Tuesday, January 5, 2016 at 9:19:57 AM UTC-5, rickman wrote:
>>
>> That makes no sense.  If the 64 used ASCII, it would use it across the
>> board.
> I think the point is that the other C64 subsystems use PETSCII as well
> (e.g. - displaying a character on the screen), so in order to make them
> behave as expected, a translation would need to be performed at all those
> integration points.

I think that is absurd.  The solution is to use ASCII in *all* 
subsystems like the rest of the world.  It was back in the 60's when 
many computer makers used their own internal character codes such as the 
6 bit code used by Univac to map neatly to the 36 bit word size.

What is the advantage of PETSCII?  Why was it invented?  After reading 
the characters missing from it, it would appear it is about creating 
problems rather than solving them.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#44591

On Tuesday, January 5, 2016 at 11:53:52 AM UTC-5, rickman wrote:
>  ... The solution is to use ASCII in *all* 
> subsystems like the rest of the world.  It was back in the 60's when 
> many computer makers used their own internal character codes such as the 
> 6 bit code used by Univac to map neatly to the 36 bit word size.
> ...
I agree completely. But since this is for a C64 that was built the
way it was built way back when, that train left the station a long 
time ago.

[toc] | [prev] | [next] | [standalone]

#44592

On 1/5/2016 1:28 PM, Chris Curl wrote:
> On Tuesday, January 5, 2016 at 11:53:52 AM UTC-5, rickman wrote:
>>   ... The solution is to use ASCII in *all*
>> subsystems like the rest of the world.  It was back in the 60's when
>> many computer makers used their own internal character codes such as the
>> 6 bit code used by Univac to map neatly to the 36 bit word size.
>> ...
> I agree completely. But since this is for a C64 that was built the
> way it was built way back when, that train left the station a long
> time ago.

Yeah, that's for sure.  So I guess nothing remains to explain why the 
C64 was designed this way?

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#44593

rickman <gnuarm@gmail.com> writes:
> Yeah, that's for sure.  So I guess nothing remains to explain why the
> C64 was designed this way?

Interoperability with other computers probably didn't matter as much
back then.  

[toc] | [prev] | [next] | [standalone]

#44594

On 1/5/2016 2:16 PM, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
>> Yeah, that's for sure.  So I guess nothing remains to explain why the
>> C64 was designed this way?
>
> Interoperability with other computers probably didn't matter as much
> back then.

Still doesn't answer the question of why reinvent the wheel.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#44595

rickman <gnuarm@gmail.com> writes:
> Still doesn't answer the question of why reinvent the wheel.

I thought the Commodore machines had some special graphics characters
for computer games.  They might have displaced some ascii characters for
those.  EBCDIC was also a thing back then.

[toc] | [prev] | [next] | [standalone]

#44596

On 1/5/2016 3:03 PM, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
>> Still doesn't answer the question of why reinvent the wheel.
>
> I thought the Commodore machines had some special graphics characters
> for computer games.  They might have displaced some ascii characters for
> those.  EBCDIC was also a thing back then.

"Might have"?

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#44597

rickman <gnuarm@gmail.com> writes:
> "Might have"?

BTSOM.  I never used those things.  They're still around and I saw one
fairly recently, but didn't try it.

[toc] | [prev] | [next] | [standalone]

#44599

On 1/5/2016 3:36 PM, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
>> "Might have"?
>
> BTSOM.  I never used those things.  They're still around and I saw one
> fairly recently, but didn't try it.

IDLUAA

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#44600

On Tuesday, January 5, 2016 at 8:12:22 PM UTC+1, rickman wrote:
> Yeah, that's for sure.  So I guess nothing remains to explain why the 
> C64 was designed this way?

I think Paul had the right idea. The original Commodore computers were based on the 1963 ASCII standard, with only uppercase characters and the $60-$ff range left undefined. Commodore used this extra space to provide graphics characters for games. It was also possible to switch to a business graphics set, where uppercase + graphics are replaced with lowercase + uppercase.

One could have imagined that the business set would map to ASCII-1973, but it does not. This is because the keyboard is made so that pressing SHIFT simply toggles the MSB (unshifted 'a'=$41 becomes shifted 'A'=$c1).

Commodore cut a lot of corners with the C64 to reduce development time and production costs. This example is far from the worst :)

Johan

[toc] | [prev] | [next] | [standalone]

#44603

On Tuesday, January 5, 2016 at 2:42:17 PM UTC-7, Johan Kotlinski wrote:
> On Tuesday, January 5, 2016 at 8:12:22 PM UTC+1, rickman wrote:
> > Yeah, that's for sure.  So I guess nothing remains to explain why the 
> > C64 was designed this way?
> 
> I think Paul had the right idea. The original Commodore computers were based on the 1963 ASCII standard, with only uppercase characters and the $60-$ff range left undefined. Commodore used this extra space to provide graphics characters for games. It was also possible to switch to a business graphics set, where uppercase + graphics are replaced with lowercase + uppercase.
> 
> One could have imagined that the business set would map to ASCII-1973, but it does not. This is because the keyboard is made so that pressing SHIFT simply toggles the MSB (unshifted 'a'=$41 becomes shifted 'A'=$c1).
> 
> Commodore cut a lot of corners with the C64 to reduce development time and production costs. This example is far from the worst :)
> 
> Johan

I liked the C64 --- that was a very cool computer --- it was a lot better than the Apple-II and cost a lot less.

Rickman is just a troll --- no matter what subject you might have brought up, he would have put it down --- the C64 is a classic of the era though, so putting it down is like putting down the Datsun 280Z.

Anyway, as I said before, good Forth style is to abstract away magic numbers, including ascii values. We have BL that returns the value of a blank, but this doesn't necessarily return 32 on every system. We also have BLANK CR SPACE and SPACES that abstract away the char value used internally. BTW: I don't know why ANS-Forth has both SPACE and SPACES as one or the other should be sufficient. Similarly, BLANK is so trivial to write that it hardly needs to be in the standard. A lot of these could have just been provided in source-code as recommendations, rather put in the standard where they just become clutter. 

ANS-Forth fails to provide a way to obtain the char values of various non-printable characters. The BL constant is the only one standardized, and it didn't have to be standardized because it is easy to obtain like this: 
s"  " drop c@ 
Because of this lack, I have these constants in my novice package:
 8 constant <backspace>
 9 constant <tab>
13 constant <cr>
27 constant <esc>
I don't know of any way to programmatically determine these constants. All of these constants should have been in the ANS-Forth standard, but the best we can do now is to just put these in every program as a pseudo-standard --- change them as necessary when porting to any computer that has different values.

When I was programming in UR/Forth, I had these constants:
1   constant c   \ the size of a char
2   constant w   \ the size of a word, either an integer or pointer
4   constant d   \ the size of a double word
8   constant f   \ the size of a float

Putting these constants at the top of every program as a pseudo-standard allowed me to easily switch back and forth between 16-bit and 32-bit UR/Forth just by changing the constants --- afaik, everybody who used Forth-83 in those days had constants like this that they used to ease the transition from 16-bit to 32-bit. I still have these constants in the novice package --- because they are short, they are more convenient to use than 1 CELLS or 1 FLOATS (W and F respectively).

[toc] | [prev] | [next] | [standalone]

#44604

On Wednesday, January 6, 2016 at 1:40:50 AM UTC+1, hughag...@gmail.com wrote:
> Rickman is just a troll --- no matter what subject you might have brought up, he would have put it down --- the C64 is a classic of the era though, so putting it down is like putting down the Datsun 280Z.

Don't know about Rickman but at least that's a cool car I didn't know about!

> SPACES that abstract away the char value used internally. BTW: I don't know why ANS-Forth has both SPACE and SPACES as one or the other should be sufficient.

I guess none of SPACE SPACES BL, or even your constants, are essential if the standard dictates ASCII. One could always look up the ASCII table. But at least SPACE SPACES BL have an educational value since they are used in Starting Forth.

> When I was programming in UR/Forth, I had these constants:
> 1   constant c   \ the size of a char
> 2   constant w   \ the size of a word, either an integer or pointer
> 4   constant d   \ the size of a double word
> 8   constant f   \ the size of a float

c d f would cause some bad surprises when programming in HEX.

Johan

[toc] | [prev] | [next] | [standalone]

#44605

On 1/5/16 4:13 PM, Johan Kotlinski wrote:
> On Wednesday, January 6, 2016 at 1:40:50 AM UTC+1, hughag...@gmail.com wrote:
>> Rickman is just a troll --- no matter what subject you might have brought up, he would have put it down --- the C64 is a classic of the era though, so putting it down is like putting down the Datsun 280Z.
>
> Don't know about Rickman but at least that's a cool car I didn't know about!
>
>> SPACES that abstract away the char value used internally. BTW: I don't know why ANS-Forth has both SPACE and SPACES as one or the other should be sufficient.
>
> I guess none of SPACE SPACES BL, or even your constants, are essential if the standard dictates ASCII. One could always look up the ASCII table. But at least SPACE SPACES BL have an educational value since they are used in Starting Forth.
>
>> When I was programming in UR/Forth, I had these constants:
>> 1   constant c   \ the size of a char
>> 2   constant w   \ the size of a word, either an integer or pointer
>> 4   constant d   \ the size of a double word
>> 8   constant f   \ the size of a float
>
> c d f would cause some bad surprises when programming in HEX.

SPACE SPACES BL are extremely useful! Always better to use names than 
numbers in cases like that. BL PARSE is very clear.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web