LinuxQuestions.org
Share your knowledge at the LQ Wiki.
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 11-23-2013, 04:42 PM   #106
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,713

Rep: Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279

It will always take up stack space. The only way to reduce it is to not have to carry the information around.

The only reason an interpreter needs the information is that there are no preconditions that have been assigned. Thus each operator needs to know the data type at the time the operation is to be carried out.

The advantage of a translator is that such operators don't need the data type - it has been identified during the analysis phase - so the output is just the operator for the specific data type. It is no longer a generic structure, but specific to the task. This is why languages/interpreters like Perl and Python get their speed. They translate the input into a byte code which is then interpreted - but that bytecode isn't as dependent on the global information.

I've been having a bit of a concentration problem, but will get back to a translator tomorrow. I have a grammar and a parser, but not fully tested. Once I can start building up from the scanner (file name handling and library functions needed for the scanner) the parse tree (which holds all that information) can then be reduced to just the required sequence of instructions - which don't need the extra information.
 
Old 11-24-2013, 11:27 PM   #107
schmitta
Member
 
Registered: May 2011
Location: Blacksburg VA
Distribution: UBUNTU, LXLE
Posts: 311

Original Poster
Rep: Reputation: Disabled
You might find this interesting: http://www.instructables.com/id/Make...-the-software/
 
Old 11-25-2013, 03:59 AM   #108
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,713

Rep: Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279
Saw some of the Motorola concepts too. Even getting with a 3D printer company to print the supporting frames.
 
Old 11-25-2013, 06:13 PM   #109
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,713

Rep: Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279
Bit of a followup. I've started getting the parse tree built (only data declarations so far, next will be
function definitions).
 
Old 11-26-2013, 11:42 PM   #110
schmitta
Member
 
Registered: May 2011
Location: Blacksburg VA
Distribution: UBUNTU, LXLE
Posts: 311

Original Poster
Rep: Reputation: Disabled
Would like to see what you do for your compiler if that would be ok. As you know, I am writing an interpreter for BASIC with many C like expression ops. I will be building hardware to run the interpreter on. Would you like to implement svm on my hardware? Maybe a royalty agreement could be worked out if I sell my hardware with your svm. Or I could sell you my hardware and you could put your svm on it. I will have a bootloader that will accept my form of packets that are encrypted so a user could download upgrades without being able (?!) to re-engineer the software. The bootloader will operate over the USB bus from the user's computer. What do you think?
 
Old 11-27-2013, 04:18 AM   #111
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,713

Rep: Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279
Have to think about it..

If that was the entire purpose, why not just use the C compiler for the chip for the compiler. It would certainly run faster.

Though it does point out one interesting encryption- just re-order the instruction set now and then...

BTW, I just got it parsing my test program - but not yet finished generating the parse tree - I have to allow for multiple symbol tables and I didn't think I needed to when I made the symbol table support (parameter lists are a table as well as the global list).

Last edited by jpollard; 11-27-2013 at 04:28 AM.
 
Old 11-29-2013, 05:45 AM   #112
schmitta
Member
 
Registered: May 2011
Location: Blacksburg VA
Distribution: UBUNTU, LXLE
Posts: 311

Original Poster
Rep: Reputation: Disabled
I finished writing get_exp (expression). Next I have to write PRINT then I can start testing. I started writing assignment (=) first and that led to writing all the supporting routines which ended with expressions. Close to 4000 lines of code. I am going to look at FORTH (used it slightly years ago) and on Saturday will probably get some books (written in the 1980's) on it from the Virginia Tech library. Not sure it could be implemented on the PIC due to its Harvard architecture. Found out about jonesforth ( http://rwmj.wordpress.com/2010/08/07...it-repository/ ) which was made for public use and is well documented. Looking at FORTH because you recommended it and it looks like fun to learn about it. Monday through Friday I work on the interpreter and on Saturday I work on the mist sensor. This project I have been working on for years. It uses the dielectric constant of water to tell how much mist is on a sensor. It is for plant propagation using cuttings where the cuttings have no roots and need to be kept at 100% humidity by mist to be kept turbid. Too much mist and they rot; Too little mist and they dry out and die. Got some new ideas while working on the interpreter for the sensor and electronics. Hope you had a nice Thanksgiving and got some rest.
 
Old 11-29-2013, 06:04 AM   #113
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,713

Rep: Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279
Spent most of the day fixing dinner which turned out fairly well.

At least the cats thought so. None came when it was their dinner time...

And now lots of tasty leftovers.

I'm about to attack the expression parsing myself - as soon as I get the symbol tables updated. (got the structure, just have to figure out how to pass the appropriate one around).

Last edited by jpollard; 11-29-2013 at 06:06 AM.
 
Old 11-29-2013, 12:12 PM   #114
schmitta
Member
 
Registered: May 2011
Location: Blacksburg VA
Distribution: UBUNTU, LXLE
Posts: 311

Original Poster
Rep: Reputation: Disabled
Talked to jones of jonesFORTH. Had suspicions that the PIC24 would not work with FORTH due to its Harvard technology. The core WORDs could have assembler behind them as they would reside in flash and the new FORTH words written in FORTH could reside in ram (characters) but he said words like DROP and C, would not be able to work with flash. Pretty much needs von neumann machine with the program in ram. What do you think?
 
Old 11-29-2013, 07:18 PM   #115
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,713

Rep: Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279
Quote:
Originally Posted by schmitta View Post
Talked to jones of jonesFORTH. Had suspicions that the PIC24 would not work with FORTH due to its Harvard technology. The core WORDs could have assembler behind them as they would reside in flash and the new FORTH words written in FORTH could reside in ram (characters) but he said words like DROP and C, would not be able to work with flash. Pretty much needs von neumann machine with the program in ram. What do you think?
I didn't think you had a pure harvard architecture - if you did, you would not be able to load programs - they would have to be burned into the instruction memory externally. That was/is the advantage of implementing a stack machine - the machine interpreter itself can be in flash, only the stack and data segments have to be in ram, and if you wanted to be able load programs, the code segment would have to be in ram (well, along with the registers). It emulates a Von Neumann architecture in that case.

But I admit to not having worked with forth. I do think you would be able to load the base interpreter into flash. The interpreter itself doesn't change - but some features would have to be copied into general ram - the base dictionary for instance (which is where I think the DROP functions, I think it allows for changing definitions of the base function definitions, but that just means the DROP doesn't have to do garbage collection on the flash, but does for anything else). This would again be like the stack machine - it would emulate the Von Neumann architecture.

The advantage of both methods is that the core program would be in flash (the interpreter) and the application running on the interpreter could (with the data) be in ram, either loaded from flash, or downloaded at boot time.

Both methods also make it more difficult to update the interpreter itself - that would require replacing the flash. Or having something local to be able to reprogram the flash... but that just pushes the limits to yet another level, because even that program could not be updated (same problem with BIOS and even UEFI - the base program can't be updated, though sometimes I think they try to have
swap memory partitions... but then, it also allows you to brick the system).

The Harvard architecture is good for things that don't get updated. Once the program is written, you can't use the CPU itself to replace it. The advantage of the Harvard architecture is that the same address range can be used for the separated instruction/data space. If all you have for memory is a 16 bit bus, you are limited to 64k general memory... but the instruction memory can also be 64K. One other advantage the architecture has is speed - because the instruction memory is separate from the data memory, access operations can occur in parallel. It also means that the program can't be dumped using the CPU (it wouldn't have access to the instructions except through the program counter... making it hard to do things to it, or extract it).

In the von Neumann architecture, this is accomplished by using dual ported memory - even though the CPU is still using the same addresses, it can split the access allowing overlapped memory operations.

Side note: this is one of the techniques used for the old Cray systems - it had 4 ports to memory per CPU, 1 for instruction stream input only, two for data input, and one for data output. Combined with quad ports to memory (for one cpu) gave maximum throughput using four bus subsystems. It does mean the number of address lines has to be larger. It did introduce a lot of complexity for the bus - Each cpu with 4 bus connections, and a maximum of 16 processors required there to be a minimum of 64 ports to main memory... and using a bus switch on each port to reduce the total wiring overhead... it ended up that nearly each machine was uniquely wired. There were also one (or two) I/O processors that were independent just for performing I/O. Boot sequence was tricky- first boot the I/O processor, which then copied data into system memory before starting the first Cray processor. From the view of the Cray CPU, it was like a diskless system - it talked to the I/O processor using a network protocol...

The advantages of choice... I've always read of the PIC processors as being limited to embedded controllers (ie, not updated, or very rarely) like the formatter boards on disk drives. For more general embedded use, most people went ARM (bigger address range, von Neuman style, and more flexible).
 
Old 11-29-2013, 10:44 PM   #116
schmitta
Member
 
Registered: May 2011
Location: Blacksburg VA
Distribution: UBUNTU, LXLE
Posts: 311

Original Poster
Rep: Reputation: Disabled
For the PIC a bootloader in flash can load a new program into flash. It is slow (milliseconds) but it works. The way to get the bootloader in is to use In Circuit Serial Programming (ICSP) to load everything into flash. Five lines: +5, ground, reset (set to -13 volts to program the chip) an I/O line (data) and a clock line. The core FORTH system has a ditionary consisting of a link list with the first 8 or so bytes being the ascii of the WORD and the rest of the record being an assembly program (machine code). This I would think could reside in flash with the rest of the interpreter. I am going to have a 1 MB serial I2C eeprom that I would allow the user to put his programs in ram to. For BASIC it is the basic program and for FORTH it would be the program in ram. One MB may not sound like much but you could get 512 2k programs in it or 50 40 byte lines. Of course the programs can be of any size up to the remaining ram after the interpreter used ram. I expect to get 24kb of BASIC program area or a 300 line program of 80 bytes per line. Most lines would probably be less than 40 bytes long. The user will use the USB to load his programs from the PC into the PIC's ram. The PIC24 I am using has 512 KB of flash (3 byte words so 170,666 words of program space) and 53kb of ram. The reason I am using the PIC is the CCS C compiler that already has built in functions to access the device's peripherals (I2C, PWM, SPI, Serial I/O, etc). The selling point is that the user will not have to burn in the program needing the $250 compiler and the $100 programmer. All he has to do is write a basic program and he will be able to access the peripherals immediately. I will have a bus brought out so that shields can be attached. The first shield would be a real time clock with battery and an SD card with a FAT file system to put data on from the peripherals like A to D or the other I/O.

Last edited by schmitta; 11-29-2013 at 10:50 PM.
 
Old 11-30-2013, 07:30 AM   #117
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,713

Rep: Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279
Quote:
Originally Posted by schmitta View Post
For the PIC a bootloader in flash can load a new program into flash. It is slow (milliseconds) but it works. The way to get the bootloader in is to use In Circuit Serial Programming (ICSP) to load everything into flash. Five lines: +5, ground, reset (set to -13 volts to program the chip) an I/O line (data) and a clock line. The core FORTH system has a ditionary consisting of a link list with the first 8 or so bytes being the ascii of the WORD and the rest of the record being an assembly program (machine code). This I would think could reside in flash with the rest of the interpreter.
It depends on how the assembly program is accessed. If the native PIC instructions can be there (and are accessible as native instructions there would be no problem. If they can't (assuming full Harvard architcture), then the "native instructions" would actually have to be an interpreted instruction (like the stack machine does its instructions), But again, that isn't a difficult item - just one layer of indirection (and one way to do it is to just use the PIC instruction address as the address to jump to (or as the target address of a function call), the interpreter just retrieves the address from the dictionary and goes to that address for execution). It also reduces the dictionary size needed in ram (only one or two "instructions"), so things would still just work as forth expects them to.
Quote:
I am going to have a 1 MB serial I2C eeprom that I would allow the user to put his programs in ram to. For BASIC it is the basic program and for FORTH it would be the program in ram. One MB may not sound like much but you could get 512 2k programs in it or 50 40 byte lines. Of course the programs can be of any size up to the remaining ram after the interpreter used ram. I expect to get 24kb of BASIC program area or a 300 line program of 80 bytes per line. Most lines would probably be less than 40 bytes long. The user will use the USB to load his programs from the PC into the PIC's ram. The PIC24 I am using has 512 KB of flash (3 byte words so 170,666 words of program space) and 53kb of ram. The reason I am using the PIC is the CCS C compiler that already has built in functions to access the device's peripherals (I2C, PWM, SPI, Serial I/O, etc). The selling point is that the user will not have to burn in the program needing the $250 compiler and the $100 programmer. All he has to do is write a basic program and he will be able to access the peripherals immediately. I will have a bus brought out so that shields can be attached. The first shield would be a real time clock with battery and an SD card with a FAT file system to put data on from the peripherals like A to D or the other I/O.
Sounds similar to the Raspberry PI (or the Arduino), though much more focused on device control.
 
Old 11-30-2013, 01:20 PM   #118
schmitta
Member
 
Registered: May 2011
Location: Blacksburg VA
Distribution: UBUNTU, LXLE
Posts: 311

Original Poster
Rep: Reputation: Disabled
Forth for PIC24 http://sourceforge.net/projects/flashforth/

AND: http://flashforth.sourceforge.net/

Last edited by schmitta; 11-30-2013 at 02:04 PM.
 
Old 11-30-2013, 02:49 PM   #119
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,713

Rep: Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279Reputation: 1279
Quote:
Originally Posted by schmitta View Post
Always something to try.
 
Old 12-01-2013, 06:59 AM   #120
schmitta
Member
 
Registered: May 2011
Location: Blacksburg VA
Distribution: UBUNTU, LXLE
Posts: 311

Original Poster
Rep: Reputation: Disabled
It looks like they can regularly update the flash which only allows 10000 updates before it is no good so kind of scary.
 
  


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

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 03:44 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