LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 08-31-2014, 01:28 PM   #271
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,600

Rep: Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241

Nice reference. I can barely remember a reference to Forth while in school, but nothing for a DecSystem 10 (and we didn't have a PDP-11 until just after I graduated).
 
Old 09-01-2014, 02:14 AM   #272
schmitta
Member
 
Registered: May 2011
Location: Blacksburg VA
Distribution: UBUNTU, LXLE
Posts: 308

Original Poster
Rep: Reputation: Disabled
Stevens Institute in Hoboken NJ Had a dec 10 in 1970 running ristus(?) OS - Almost went there.
 
Old 09-01-2014, 08:15 AM   #273
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,600

Rep: Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241
I remember we got a copy of SITGO interpreter (SNOBOL I believe) from there. DEC 10s all ran TOPS-10 except maybe those at Stanford (I think they had Tenex). RSTS ran on PDP-11s, it was one of the timesharing systems for the PDP-11/34 and higher (those had MMU and floating floating point. Up until the PDP 11/23 I don't remember those features existing).
 
Old 09-08-2014, 11:43 PM   #274
schmitta
Member
 
Registered: May 2011
Location: Blacksburg VA
Distribution: UBUNTU, LXLE
Posts: 308

Original Poster
Rep: Reputation: Disabled
I am somewhat a simple person - things need to be clear to me. For a while I was thinking that I could produce a sort of pseudo compiler that took in basic and compiled it to a linked list language where each super instruction was a node in a linked list that also contained pointers to variables, etc. It would be a VM or pseudo instruction set. Then I worked on the basic interpreter for 6 months. Then I started working on another approach to mist control which required sub-interfaces like a I2C slave LCD display and a I2C slave keypad. Then I needed an I2C master that connected to a PC to test them out. Then that project morphed back into a single board computer that used a PIC24 with 512k flash (program area) and 53k ram (harvard architecture). Then to bring that up with a programming language I looked at Forth but had reservations as the language too hard for most people to use which would result in less sales than say basic. Reading about forth I found it was threaded code which for some reason I had never found the definition of. So I looked it up and found that it was my threaded linked list of super instructions. And seeing your stack machine and forth's use of data and return stacks It started to become clear that with 512K program space and a SDcard PGM and DATA disks that I could write a system that included a compiler to threaded code with a stack machine implementation of the VM all in the single board computer.

It will take a lot more thought to put it all together but studying Forth seemed to jell certain concepts. I may be crazy but it is starting to make sense. What do you think?
 
Old 09-09-2014, 08:53 AM   #275
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,600

Rep: Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241
That is the learning process. And it can take a while for information from various sources to be integrated and then come up with a "Ah HA" moment when it all makes sense.

And there should be enough room for that as an application.

An example is the old Radio Shack TRS80 - a small handheld originally released in 1980 (I had one). The basic was very small, and simple - but easily handled a phone number lookup that I wrote (it was all I needed).

http://oldcomputers.net/trs80pc1.html
 
1 members found this post helpful.
Old 09-09-2014, 04:18 PM   #276
schmitta
Member
 
Registered: May 2011
Location: Blacksburg VA
Distribution: UBUNTU, LXLE
Posts: 308

Original Poster
Rep: Reputation: Disabled
It may end up that I just implement Forth on the PIC24 along with FATFS ( http://elm-chan.org/fsw/ff/00index_e.html ) file system and change the BASIC interpreter to a compiler to generate Forth code. That way they can either just use Forth or BASIC if they like. The BASIC compiler would then run on the PC unless I have enough space in the PIC24. If it ran in the PIC I would only need to generate the BASIC compiler once in stead of a jillion times for each machine (it is in C) unless I can convert it to JAVA. My current basic interpreter is 64.8KB without the debug info. The PIC24 has 24 bit words so the actual program space is ~170K words.

Last edited by schmitta; 09-09-2014 at 04:30 PM.
 
Old 09-09-2014, 05:02 PM   #277
schmitta
Member
 
Registered: May 2011
Location: Blacksburg VA
Distribution: UBUNTU, LXLE
Posts: 308

Original Poster
Rep: Reputation: Disabled
A BNF parser in Forth http://www.bradrodriguez.com/papers/bnfparse.htm
 
Old 09-09-2014, 09:25 PM   #278
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,600

Rep: Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241
Quote:
Originally Posted by schmitta View Post
And he reports the problems with using a recursive decent parser...

The BNF parsers used by Linux (Bison mostly) are LR table driven, because it allows the left recursion to be handled...(useful in some circumstances, but to use it just anywhere causes the result to be inefficient and slow).
 
1 members found this post helpful.
Old 09-10-2014, 03:32 PM   #279
schmitta
Member
 
Registered: May 2011
Location: Blacksburg VA
Distribution: UBUNTU, LXLE
Posts: 308

Original Poster
Rep: Reputation: Disabled
I may not be able to use Forth on the PIC24. PIC24 is Harvard architecture and Forth requires that machine code routines be able to be written. In PIC24 code is only executed in flash. I can rewrite flash but only 100000 or 1000000 times. True flash will be written probably less often. The dictionary would have to be in flash and that is written to a lot. Another microchip problem.

I guess I could write threaded pseudo code in ram and have it call -- I was going to say call routines in flash but I am not sure how I would get those addresses into ram or if a call can be made with an address in ram. Some how an indirect call would have to be made possibly getting the offset into a table in flash that would have the address to call to.
 
Old 09-10-2014, 07:45 PM   #280
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,600

Rep: Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241
If nothing else you should be able to push data on the stack and return... and that "data" is the address to start execution of the next function (which could be in flash).

Remember, only the base machine code has to be executed directly - the rest can be software interpreted (as in the indexed jump table). The only requirement then is that the base instructions used by the Forth interpreter are then just indexes into the jump table.

Second, you can have multiple dictionaries - a static one for the base language, plus an expansion in ram used by the application as needed. And the application COULD be in flash - then copied/read into ram creating the extended dictionary (and the threaded code to be interpreted). Thus the flash would only be rewritten when the program is installed. It is also one way to eliminate two dictionaries - the flash based one could be copied to ram before use. The penalty is having to use RAM for the same data that is already in the flash.
 
1 members found this post helpful.
Old 09-14-2014, 12:23 AM   #281
schmitta
Member
 
Registered: May 2011
Location: Blacksburg VA
Distribution: UBUNTU, LXLE
Posts: 308

Original Poster
Rep: Reputation: Disabled
I can only execute instructions in flash not ram.
 
Old 09-16-2014, 06:36 AM   #282
schmitta
Member
 
Registered: May 2011
Location: Blacksburg VA
Distribution: UBUNTU, LXLE
Posts: 308

Original Poster
Rep: Reputation: Disabled
It looks like at this point I would first try to finish the BASIC interpreter as it would contain what was needed also for the compiler. The thing is I would like to have the compile system in the 170k flash words of the pic24. Some form of stack machine is the way to go. Some PIC24s have ram that goes up to 97k so I would need 3 bytes for address. But those machines only go up to 256K flash ( 85.33k words ) . Maybe the compiler should be in the PC and have it produce assembler and then the assembler be in the 85k words. No need for a linker. Maybe multitasking which would require multiple stacks and saving and restoring regs. An assembler would have to be developed in C. Maybe I should use your system on the PIC24. Want to get a royalty for each system sold for your work? Some form of assembler OPS would need to be developed for controlling the device's peripherals like I2C, SPI, GPIO and ADC. I have a C compiler that (not completely ansi) makes it easy to write routines to control those peripherals which I would like to use. Or the multitasking OS could be at the machine level (real machine) that would allow for development of programs in background while a program(s) were running in foreground. I need to develop a reflow controller that would then allow me to use smd parts to make the pic24 system. My name for the board system would be TIGER with TIGER-B for basic, TIGER-C for C or TIGER-A for assembler.
 
Old 09-16-2014, 07:47 AM   #283
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,600

Rep: Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241
Quote:
Originally Posted by schmitta View Post
I can only execute instructions in flash not ram.
The dictionary itself is only data. It may POINT to flash though. According to the info I find on the PIC24, you can use an indirect jump (still have load the register with the address to go to though).

In any case, the interpreter itself is the only thing being executed. It does require the dictionary to contain an identification of whether the data is referring to native code (then use the jump) or interpretive code (in which case use an interpreted go to that simply changes the virtual PC).
 
Old 09-18-2014, 03:35 AM   #284
schmitta
Member
 
Registered: May 2011
Location: Blacksburg VA
Distribution: UBUNTU, LXLE
Posts: 308

Original Poster
Rep: Reputation: Disabled
I do see your idea of having two dictionaries in Forth. The one in flash can have assembler code in it that can be executed. The one in ram cannot have assembler code in it but can have the pseudo instructions of the forth virtual machine with more added in the future. My system would allow users to have programs on disk (sdcard) - some how the user's system would have to be store-able which I guess would be the ram dictionary. I guess I could turn the BASIC interpreter into a compiler that produced Forth output. Might have to come up with forth words for the flash dictionary that would ease the BASIC to Forth translation process. The BASIC would have commands to access the computer's peripherals which counter parts could be come up with as forth words. A person knowledgeable could write directly in Forth. Forth processors are small so maybe I could shoehorn in the BASIC compiler, FAT file system (both in C) and the Forth virtual machine. If that were not possible then possibly the BASIC compiler could be written in Forth probably speeding it up and reducing its size. Don't know how to do that yet.
 
Old 09-18-2014, 07:18 AM   #285
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,600

Rep: Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241Reputation: 1241
The usual problem is the length of the expressions allowed.

The BASIC compiler doesn't HAVE to be in forth - as long as the forth interpreter can invoke it at the right place. The compiler could/would be a forth dictionary entry... or if the "edit,compile,execute" loop is the BASIC interpreter, then the execute would be invoking Forth. Forth is compact, but it still has the branch overhead - and that adds to the memory requirements. Having BASIC written in Forth would impose that overhead on the compiler as well, where a native code block wouldn't.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Regular Expressions nova49 Linux - Newbie 4 07-13-2011 08:05 AM
Regular Expressions Wim Sturkenboom Programming 10 11-19-2009 02:21 AM
regular expressions. stomach Linux - Software 1 02-10-2006 07:41 AM
Regular Expressions overbored Linux - Software 3 06-24-2004 03:34 PM
help with REGULAR EXPRESSIONS ner Linux - General 23 11-01-2003 12:09 AM


All times are GMT -5. The time now is 02:05 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration