Linux - NewbieThis 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!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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).
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?
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).
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.
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).
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.
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.
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.
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).
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.
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.