Sign in

username:

password:



Not a member?

Search blogs



Search tips

Articles by category

Sponsor

controlSUITE™ software
Comprehensive.
Intuitive.
Optimized.

Real-world software for real-time control. Details Here!

Ads

Our Bloggers

See Also

DSPFPGAElectronics

Embedded Systems Blogs > Kim Mansfield > Interpreters Good and Bad


Advertise Here
Kim Mansfield
Kim Mansfield is an embedded software consultant. He has over 25 years experience in industry specializing in small single chip systems with the MSP430 being his processor of choice. He has worked with Motorola, Zilog, and 8051's in C and assembly language. He currently holds a BS in Computer Engineering and an MS in Computer Science.

RSS Feed

Would you like to be notified by email when Kim Mansfield publishes a new blog?

  

Interpreters Good and Bad

Posted by Kim Mansfield on Oct 24 2007 under   

Interpreters

What do you think of when you think of an interpreter? I think of the BASIC (Beginners All purpose Symbolic Instruction Code) interpreters of the early 80's. There were several varieties. Apple had one for their computers, Radio Shack had a couple of different ones for their TRS-80 computers, and interpreters for small computers of the Era. Microsoft got its start writing BASIC interpreters for these machines.

Today we have Java which is used in many applications. It is used as applets in web pages, in general applications, and in embedded devices. Java is compiled to what is termed byte codes. These byte codes are executed by an interpreter. So, you might say Java is an interpreted language but not in the sense as the old BASIC interpreters. Java is much faster and easier to implement on different machines.

I remember one of my first full time consulting jobs. I was hired by a small startup to help with their POS (Point of Sale) terminals. It was based on an 8051 on steroids. It had megabytes of RAM and flash. They had contracted with a manufacturer back east to develop the software and hardware for this terminal. The manufacturer finished the device and had delivered it. The software was a little lacking. It wouldn't do some of the things the startup wanted it to do.

The startup wanted the POS terminal to be very flexible. They wanted the ability to change products sold by the terminal at any time, to change inventory on the terminal and any other thing they could think of. The software as delivered was designed to be table driven. These tables could be changed by downloading a new table to the device which would change the functionality of the terminal.

When I started they wanted to make a change to the terminal and found that the tables wouldn't support the change. They contacted the manufacturer and requested the change. The manufacturer said it would be very difficult and would require more money to implement the change. With this information I was tasked with making changes to the terminal to make it more flexible.

With this assignment I dug into the software looking at the architecture and wondering how I could make it more flexible. I thought it would be great if we could just download a new program to the terminal. Then it dawned on me. I needed an interpreter which would implement the actual functionality of the terminal. All I had to do was to create an environment that would support all the functionality required to operate the POS functions.

I presented this idea to my boss. He was impressed by my enthusiasm and the flexibility the new architecture would bring to the terminal. The biggest problem was I was talking about a total rewrite of the software. I would discard 70 percent of the current software. My boss didn't like that. The startup had invested a lot of time and money on the current software base. Another problem was the time required for the rewrite. They were coming to the end of their funding and didn't have a viable product to generate cash flow.

I decided that the byte code approach would be the best option. I looked at implementing Java but decided against it as Java was bigger than we really needed. We would need a file system that could hold the inventory of the terminal and the byte code of the programs along with other necessary information.

Once the system was finished my boss was very excited. He would come up with a new way of selling something or presenting the menus to the user and I would say sure we can do that. We did run into a couple of situations that wasn't supported by the system but it was very easy to add a keyword or two to the interpreter to support the required functionality.

A requirement of the terminal was to authorize credit card purchases. This was one of the things the table driven environment wasn't able to support. My boss said this would be the ultimate test to see if the interpreter could support the authorization process. I wrote a script compiled it and put it on the terminal. I ran through the authorization process and it worked. That was icing on the cake.

One thing this architecture gave the startup was the ability to move the interpreter to other hardware. The porting process was just a few weeks versus months of development for a new system. The interpreter was moved to a PC and other POS hardware. Needless to say it was a great success. It has been 4 years since the completion of the project and some friends that still work there have told me the system hasn't been touched in all that time. The company is still thriving and profitable.

It is not all good. There are problems with interpreters. They execute code slower than native code. This hit in performance can be minimized by using a virtual machine or byte code. Java uses a Just In Time compiler which takes their byte code and as it is executed translates it into native code to speed up execution. Of course these JIT compilers add to the complexity of an interpreter which is a little beyond what I'm trying to do here. I'm a big advocate of keeping things simple. I find simple things work better.

So, until next time keep your code simple and comment it. You may have to go back and modify it.

Kim

Rate this article:
0
Rating: 0 | Votes: 0
 
posted by Kim Mansfield
Kim Mansfield is an embedded software consultant. He has over 25 years experience in industry specializing in small single chip systems with the MSP430 being his processor of choice. He has worked with Motorola, Zilog, and 8051's in C and assembly language. He currently holds a BS in Computer Engineering and an MS in Computer Science.

Previous post by Kim Mansfield: First Post
all articles by Kim Mansfield


Comments


 

leblancmeneses wrote:

4/15/2008
 
How do you abstract the interpretor so that the hardware architecture is decoupled?

this way you can move your interpretor from an x86 to power pc machine.

How does the interpretor convert the instruction to a machine instruction... CISC, RISC ?????

can i have a simple hello world example?


How do you grant access to devices. DIO pins, TPU, ADC .. ect? this changes across hardware platform ....


Can you provide a uml diagram to describe the high level architecture?

I would love to be able to program in c# and run it on a freescale chip....
http://www.mono-project.com/Main_Page

Leblanc Meneses
http://www.mixhacks.com
 

kmansfie wrote:

10/29/2007
 
Actually, I found that contract in the Newspaper. I always scan the local papers for jobs that I might qualify for. Even if the company is looking for a full time employee you can usually come in as a contractor to see if you like the company and they like you.
 

elvis wrote:

10/29/2007
 
How did you get that consulting job?

Add a Comment
You need to login before you can post a comment (best way to prevent spam). ( Not a member? )