Pages: 1 
|
 |
|
Author
|
Topic: Some thoughts... (Read 4528 times)
|
Charles Childers
Administrator
Sr. Member
Karma: +2/-0
 Offline
Posts: 745
|
A lot of contributions have been made recently. I think that this is a good time to bring up the philosophical goals I set for RetroForth. And perhaps explain some things as well. I strive for a balance between simplicity and features. I'm not out to create a standardized Forth, so incompatibilities can and will exist between RetroForth and all of the various Forth standards.
At the same time, I don't want a totally minimal Forth. The core (core.asm, core.dict, rf.asm, macros.fasm, and the bootstrap code in blocks/*) is intended to be as small as possible without sacrificing practicality. When possible words are written and saved in Forth (+ inline machine code) rather than in assembly. This is an intentional decision that should serve to help with ports to other processors, and also reduce our dependence on a specific assembler.
I don't want complex control structures. That's why words like else are missing. I used tail recursion and conditional exits successfully for a long time. But it's nice to have some real loops once in a while. Deep nesting should not be done. You should factor your code when feasible. I don't advocate extreme factoring. But it does help to keep the code clean, understandable, and simple.
for and next are good. They take little from the stack (just a count) and don't complicate things too much. The repeat and again loops are also useful for many things.
With the words for comments, I chose based on readability. Consider these samples:
[code]: loop
|
|
|
|
« Last Edit: September 25, 2005, 07:35:56 PM by Charles Childers »
|
Logged
|
|
|
|
RogerLevy
Full Member
Karma: +1/-0
Offline
Posts: 55
|
thank you Charles.
i totally believe in a simple, non bloated core with the possibility for lots of extensions. because it just gives people more options! and when it comes to "libraries", if you don't like one camp's way of doing things you can try something else, while still keeping the "glue" the same. writing code in forth is so easy there's no point in getting anything done once and for all - you can just write new code to solve each problem, no big deal.
|
|
|
|
|
Logged
|
|
|
|
Andrew Price
Member
Karma: +0/-0
Offline
Posts: 7
=B-)
|
Learnability and simplicity are the two main virtues that attract me to retro.
For the past year I have been searching for a forth I can write simulations in, and which could output graphics. Later, I would like to use the same forth to control rather complex industrial robots. I tried Win32Forth, but it has thousands of words. So does BigForth, which is an amazing accomplishment, but you need to learn a lot to use it. GForth is a little better and I spent some time trying to get OpenGL/GLUT to work with it, mostly without success. I keep trying to use the brutally beautiful ColorForth (as XColorForth), but the i/f is simply so ferocious that I can't get over the initial learning hump (I am lazy). Enth is better, but Sean seems to be moving on. So I am stuck using Java (yuck), but cannot get more than 50 fps out of it and it is bloated beyond belief.
I came across retroforth in the freshmeat list last night and like it most of all, however I need some more facilities.
I think your goals are right on Charles and I commend everyone who has contributed to RF.
While the core needs to be very sparse, I would suggest the following areas where small toolkits are essential to making RF a tool that can take on a variety of useful tasks. I would encourage us all to try to establish these almost-core 'packages' as being quite standard so that somewhat sophisticated RF programs can be portable.
1. File I/O (seems well under way)
2. Graphics -- OpenGL seems like a logical target, but a small set of words that can use either OpenGL or DirectX would be cool (Chuck's warnings about LCDs notwithstanding). I might be able to help with this on Linux.
3. USB access (keyboard/mouse/sound/maybe net/etc etc)
4. net IP access
5. Multitasking/IPC
A common set of words for similar parts of 1,3 and 4 might be good. Words for async/sync/connection oriented/connectionless/stream/block might be the same for all.
With those 4 packages as standard (within retro, not externally) as possible I think retro would be usable for a huge range of projects, and need not be very large.
I love how clean the core is, please keep it that way and please don't worry about external compatibility (ANS etc) either.
I would also appreciate worked examples to go with every entry in the word list, and can try to chip some in for those I understand properly.
Regards
Andy
|
|
|
|
« Last Edit: January 03, 2005, 03:34:29 AM by Andrew Price »
|
Logged
|
CTO, HealthSpace
|
|
|
Charles Childers
Administrator
Sr. Member
Karma: +2/-0
Offline
Posts: 745
|
While the core needs to be very sparse, I would suggest the following areas where small toolkits are essential to making RF a tool that can take on a variety of useful tasks. I would encourage us all to try to establish these almost-core 'packages' as being quite standard so that somewhat sophisticated RF programs can be portable.
I am finally getting to a point where I'm satisfied with the basic wordset. With 8.0 (where the major cleanups are being implemented/tested), some things will be much cleaner and more modular, but next month you'll start to see some of the changes. Until 8.0 gets to a semi-stable state, I'll be continuing active development of the 7.x codebase. 7.7 will bring a few of the internal cleanups, as well as some of the improved modularity.
Basically, I like having a small, simple core, but I do agree that we need some internal standards for things like file I/O. (I use blockfiles, but most people seem to prefer normal files, so I make a concession there...).
1. File I/O (seems well under way)
File I/O is coming to Linux, Windows, and FreeBSD in 7.7 or 7.8. My words for this won't be ANS compatible, but Ron and others have been doing work towards ANS-compatible file words, so that's not a major deal for me.
2. Graphics -- OpenGL seems like a logical target, but a small set of words that can use either OpenGL or DirectX would be cool (Chuck's warnings about LCDs notwithstanding). I might be able to help with this on Linux.
Alexey has done some work on supporting OpenGL under Windows. I'll be porting that over to the Generic/DL port sometime this month, and then fleshing out the functionality as I have time. In addition, Roger has been working with the Allegro gameing library for graphics, and Chris Walton has been experimenting with libSDL.
I'd like to put together a set of fairly generic drawing words that can be adapted to work with OpenGL, libSDL, or Allegro, so that we have a lot of flexibility on the backend used.
3. USB access (keyboard/mouse/sound/maybe net/etc etc)
4. net IP access
5. Multitasking/IPC
These are harder. The USB protocols are quite complex. The native version, where I'm focusing on writing drivers, can use USB devices if the BIOS has settings to make them appear as "traditional" devices. Under Linux, you could communicate with them via syscalls though. Windows makes things even harder 
Network access depends on at least cooperative multitasking to be functional, though you can use tcpclient under Linux to do some network-oriented things. (See http://www.retroforth.org/irc.f for the start of an irc client using retroforth and tcpclient. The primary author of the irc code is working on net access without tcpclient IIRC)
Multitasking and IPC depend on the host OS. I could probably do some basic multitasking & IPC words under Linux, and possibly FreeBSD, but Windows is just a pain to deal with, no matter how you cut it.
I would also appreciate worked examples to go with every entry in the word list, and can try to chip some in for those I understand properly.
Anything you can help with there would be appreciated. I'm getting short of time these days (Me and my family are busy preparing for our new child, which will be born in a few weeks...)
I'll expand on what's coming in the modularity and cleanups a bit over the next few days.
Charles
|
|
|
|
|
Logged
|
|
|
|
Andrew Price
Member
Karma: +0/-0
Offline
Posts: 7
=B-)
|
Basically, I like having a small, simple core, but I do agree that we need some internal standards for things like file I/O. (I use blockfiles, but most people seem to prefer normal files, so I make a concession there...).
I agree and would not suggest adding these extra 'packages' or vocabularies into the core. Rather I would prefer to see them be as consistent among themselves as is consistent with their real differences. At least for me, any kind of compatibility with other forths is very low priority.
So for example, I would expect that USB, file, ipc and net vocabs might all have a 'locate' or 'exists?' word that returns an error/success code, and an 'open' word that returns a handle to a file, stream or connection. The same word might take different parameters in each package, but would behave in much the same way.
Similarly, when the same 'package' exists in different implementations for different platforms, I would prefer to see them be 'mostly compatible' rather than identical. Someone wishing to do graphics on windows using directx after developing on linux ogl, or on SDL after ogl should expect to have to do a little tweaking. The core, however, should be compatible across platforms. This is consistent with keeping retroforth simple and yet not succumbing to the lowest common denominator effect that Chuck warns of.
Obviously multitasking and graphics might not have much in common with the other packages.
Alexey has done some work on supporting OpenGL under Windows. I'll be porting that over to the Generic/DL port sometime this month, and then fleshing out the functionality as I have time. In addition, Roger has been working with the Allegro gameing library for graphics, and Chris Walton has been experimenting with libSDL.
I'd like to put together a set of fairly generic drawing words that can be adapted to work with OpenGL, libSDL, or Allegro, so that we have a lot of flexibility on the backend used.
I think this is exactly the right approach -- develop a common toolset for each that reduces the time to port, without attempting to eliminate it, since that last few percent of difference is where the majority of function will be lost by forcing all to conform.
(use,net and ipc) are harder. The USB protocols are quite complex. The native version, where I'm focusing on writing drivers, can use USB devices if the BIOS has settings to make them appear as "traditional" devices. Under Linux, you could communicate with them via syscalls though. Windows makes things even harder
Yes, I would not expect the protocols within USB to be standard, simply the way of acquiring devicies and reading and writing the data. Linux has a devusb filesystem that may help make usb more tractable.
Note that I say all of this from the comfort and safety of my armchair, since I cannot provide much help at present. 
Good luck with the new baby and keep up the great work, I am lost in admiration that you do so much already.
btw, take a look at http://www.beepcore.org/ for a highish level tcp kit. Thanks for the pointers, I shall certainly look at the irc stuff.
Cheers
Andy
|
|
|
|
|
Logged
|
CTO, HealthSpace
|
|
|
|
|
|
|
|
|
Pages: 1 
|
|
|
|
|
