Final Project Proposal Section 2

Features

The domain of our language will be real-time programs that needs some sort of deadline enforced. For example, there could be a program that controls a mechanical arm that reacts to a sensor input. However, if for some reason the arm does not react fast enough, the safety of the system cannot be guaranteed and the arm needs to reset to a default position or shut down.

We will extend the 164 language to have a sense of execution time. We can encapsulate code into deadline objects which are essentially functions with timers in them. If a timer goes off before the function returns, then we throw an exception that the programmer must handle.


Implementation Ideas

1. Create a deadline clause that includes the code needed to run within the deadline. These clauses will have associated "catch" that will execute if the deadline is not met.
   
• Frontend: We will parse and interpret our code using the Project 3 language parser and interpreter
• Core Language: We will be extending the function objects of the Project 3 language to allow for timers to run in parallel to the code that will ensure deadlines are kept track of. The deadline clauses will be sugar for argument-less, return-less functions and an immediate call.
• Internal Representation: This will be kept in byte code similiar to Project 3.
  
• Interpreter/Compiler: We will use the same tool chain as the 164 language we developed in Project 3. The new clause requires that we build it into the language and the 164 language is simple to modify since we already have a good understanding of how it works.
• Debugging: We will test the code using small programs and using infinite loops to test deadline functionality.
  


2. Create a special deadline object that starts a timer and interrupts the control flow if the timer goes off. When it goes off, the object will call a function that it was built with.
   
• Frontend: We will parse and interpret our code using the Project 3 language parser and interpreter.
• Core Language: We will be extending the Project 3 language with new deadline objects. These objects will be similiar to coroutines in that they will be executed outside of the normal control flow and will return the control after it completes.
  
• Internal Representation: This will be kept in byte code similiar to Project 3.
• Interpreter/Compiler: We will use the same tool chain as the 164 language we developed in Project 3. The new internal objects require that we build it into the language and the 164 language is simple to modify since we already have a good understanding of how it works.
• Debugging: We will test the code using small programs and using infinite loops to test deadline functionality.

Final Project Proposal

The Problem
Real-time programming can be difficult enough ensuring the code actually can complete running within the time limit, without worrying about ensuring the time itself is correct as well. There is also the alert system to deal with, should the deadline actually be reached - what kind of message should be sent? What is the right alert to help the programmer fix the issue?

The Idea
Our final project seeks to alleviate the real-time programmer's workload regarding deadlines. Rather than having the programmer deal with the messy plumping of creating a deadline timer each time, we intend to extend the Project 3 code and create a generalized deadline construct that will wrap around whatever code is real-time dependent and set off a notice if the deadline is reached before the code has finished running. The programmer merely needs to provide the time-sensitive code he or she wants to wrap, as well as the amount of time in milliseconds said code can take the run.

Roadblocks
Timers themselves can be potentially tricky business, but when one throws in code to keep track of on top of that, the construct will need to ensure it has everything straight. In addition, if the deadline is hit and the code has not finished running, the construct must deal with interrupting the code, and dealing with the consequences as the programmer would like to. Too, one must have some simple and straightforward message system to alert the user when the deadline is hit.

Why?
This project is worth working on because real-time computing itself is important, and any steps to make it easier can only help the larger issue.

Comparisons Against Current Solutions
For Java, RTSJ has introduced two new thread types, RealtimeThread and NoHeapRealtimeThread, as an extension of Java's Thread class. RTSJ also creates two timer classes - OneShotTimer and PeriodicTimer - in which the thread is then managed.

Why create our solution then, which seemingly does the same thing? Issues of Java aside, the timer and thread classes RTSJ provides still necessitate a lot of busy work and ugly plumbing, where a coder can easily make an error. We seek not only to offer a solution, but provide a clean, elegant solution that is simple to use.

Sources
RTSJ homepage