TUTORIAL: T0 – The Basics

The code below is a good starting point for looking at the basics of APRON syntax. APRON is an interpreted functional script, where all commands are of the form y = f(x1, x2, x3). Each line of APRON code directly translates to a “virtual” hardware instruction. The simulator provided in APRON emulates an ideal processor array, that is capable of many functions.

// Tutorial 0 - The Basics

// TUTORIALS ARE DESIGNED TO BE READ AND STEPPED THROUGH IN THE
// APRON SIMULATOR. THEY WILL NOT DO INTERESTING THINGS IF RAN!
// (c) David R W Barr 2011

// Welcome to APRON! This tutorial explains the basics of algorithm structure,
// program flow and variables. Please read to the end of this source file, following
// the instructions

// <- These double slashes are a comment. APRON does not have block comments, although
// Crimson Editor can "pretend" by selecting the text and hitting CTRL+M to comment, and
// CTRL+SHIFT+M to uncomment. Try it!

// Nearly all APRON programs need to specify they are going to use the APRON core
// for compilation and simulation. This is defined in the headerfile 'apron.aps'.
// Header files are placed directly in the code, line for line, when the pre-processor
// command "!include" is used. Be careful not to include files twice, or in the wrong order.
// The APRON compiler will catch recursive inclusions.

// Include the main APRON system
!include('apron.aps')

// The above line is a pre-processor command. We know this because it begins with !
// pre-processor commands are executed at compile time and are used to help form
// the algorithm through code-reuse, encapsulation and readability.

// Character strings in APRON are surrounded by single quotes - 'like this'
// APRON Script files have the extension "aps". There is no distinction between 
// source and header files, as headers are equally just source files.

// Variables in APRON are all 32-bit floating point numbers (even the integers!)
// They are implicitly defined when written to, but must have been defined when read.

a = 3 // Create a variable "a" and set it 3.

// APRON assumes variables implied this way are of type "VARIABLE"

// Basic mathematical operators are included in the APRON core.
// APRON is an interpreted assembly language. Therefore you cannot use long
// expressions.

b = a + 7 // is valid

// but "b = a + 7 + 6"  or "b = a + 2 * b" is not.

// Why? This makes an assumption that one line of APRON code performs more than one hardware
// level instruction. This will make more sense when you reach the advanced tutorials. For now,
// treat expressions in APRON as if you were using a simple calculator from the 70's.

// Frustratingly, "b = a + 7" is good, but "b = 7 + a" is not. APRON expressions should always be 
// variable = constant, 
// or variable = variable, 
// or variable = variable + constant, 
// or variable = variable + variable

// Again reasons for this will be explained when you start designing models of procesisng hardware

// As you step through the code in the simulator you will notice the variables are listed, and
// their values change accordingly. The simulator allows you to change the value of a variable
// by double-clicking on it. A single-click higlights the variable. This may be useful when your
// algorithms become larger.

counter = 0 // Create a variable called "counter"

// Labels are code locations. For example

#loop_one
	// It is conventional to indent after declaring a label
	
	counter = counter + 1 // Increment counter
	
	// Conditionally jump back to the label if true
	jumpif(counter, <, 5, #loop_one)

// Removing the indent helps segment the above code form the rest of the program. More often
// than not you will remove the indent after a jump, jumpif, or return statement
	
jump(#loop_two) // unconditionally jump to labelled location









// This is skipped - come back here in a bit...
#sneaky_subroutine
	counter = 500 
	return


	
	
	
	
	
	

#loop_two
	// We can use if..else..endif and if..endif blocks to optionally execute code
	if(counter, ==, 5)
		// The counter is at the correct value!
		counter = counter * counter
	else
		// The counter has been messed with!
		counter = 25
	endif
	
	// A call jumps to the given location, and places the previous location
	// on a stack. When a return statement is encountered, the current
	// location is swapped with the previous location.
	callif(counter, ==, 25, #sneaky_subroutine)
	// Like jump, calls do not have to be conditional
	
	// Now counter should be 500
	if(counter, >, 499)
		if(counter, <, 501)
			call(#all_good)
		else
			call(#all_bad)
		endif
	else
		call(#all_bad)
	endif
	
	
	
	
	// The "end" statement stops the simulation. Permenantly.
	end
	
	
	
	
	
	
	
#all_good
	// Excellent!
	score = 100 // points
	return
	
#all_bad
	// Booo!
	score = -100 // points
	return