Interpreters Good and Bad
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
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
- Comments
- Write a Comment Select to add a comment
[ - ]
Comment by ●October 28, 2007
How did you get that consulting job?
[ - ]
Comment by ●October 28, 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.
To post reply to a comment, click on the 'reply' button attached to each comment. To post a new comment (not a reply to a comment) check out the 'Write a Comment' tab at the top of the comments.
Please login (on the right) if you already have an account on this platform.
Otherwise, please use this form to register (free) an join one of the largest online community for Electrical/Embedded/DSP/FPGA/ML engineers:
