Plov : Some thoughts

At this point, we have a fairly complete programming language. In many aspects it is bigger than any commercial BASIC (targetted at the same group of processors). In other, it still isn't. And as a seasoned assembly and Modula-2 programmer I still miss some little gems. And they are related to bit manipulations. In microcprocessors, bit manipulations are of a second importance. In microcontrollers, bit manipulations are the highest importance. So we need to spend some time on this.

In Modula-2 we have the 'set' concept. A machine word is considered as a set of bits. And each bit can be manipulated. Like so: 

	IF 23 IN BITSET (flagword) THEN  Signal (SigSegv)		END;
	IF TL IN TestsToDo THEN     Goto (20, 63);  Print ("ħħ")	END;
	INCL (set, element);
	EXCL (PortB, bit7);
The first line checks if bit 23 is SET in 'flagword' and if so, a SigSegv id generated.
The second line tests if element 'TL' is present in the set 'TestsToDo' and if so, something is printed on screen.
The third line will include a '1' in the set 'set' at position 'element'.
The fourth line will remove a '1' (which is swiss for "include a '0'") at bit 7 of PortB.

In the ideal case, this is how Plov could handle things. But it won't. Plov is a simple language with just one type (Cardinal), as opposed to a real Modula-2 implementation. So some other means must be chosen.

Plov : IO port manipulations

I have thought about this issue elaborately. The following ideas crossed my mind:

  1. Introduction of a simple SET concept, especially for IO Ports. It would resemble the INCL and EXCL operators from Modula-2. It would look like 'PortB := { Con1 ... Conx }' where each Coni would be a constant representing a bit position. This would be easy since it starts with a '{' and MUST end with a '}'. So it could span multiple lines.
    I abandoned the idea since it would make the language too high level. The distance to assembler or BASIC would become too big. Also, it would mean major surgery to the 'Assignment' function.
  2. Use of an infix notation like used in C and similar languages. The idea would be to make something like 'PortB := XOR Bit7' boiling down to a line like 'PortB := PortB XOR Bit7'.
    The idea lived very shortly. Too unstructured.
  3. Introduction of a new keyword: MASK, possibly in three variant: MASKXOR, MASKOR and MASKAND bu I thought this to be too artificial. Plov would get very complex here. I played with the MASK word in some other forms (like setting a MASK in a seperate line) but this is not what Professor Wirth would have done.
  4. Introduction of a new keyword 'PORTS' in which ports could be declared. The Ports would be taken up in the symbol table, like variables. This was a nice concept but contradictory to the nature of Plov. It would necessitate the introduction of at least one other TYPE. And the basic concept of Plov is 'One datatype'.
  5. Introduction of three new operators in 'TermOperator' : AND, OR and XOR. This would do the trick. But it would draw down Plov too much towards pure assembler. High level programmers need not be bothered with intrinsic spinoffs of logical operators.
    Also, it would mix bitwise operators with numeral operators. For a C compiler this is perfectly acceptable. But not for a Wirthian language.
  6. Introduction of keywords 'SET', 'CLEAR' and 'TOGGLE' behind the assignment operator. I think my blood sugar must have been critically low then, to come up with such a stupid thought.
  7. Introduction of three intrinsic functions with names yet to be invented. Most probably the names will be SET, CLEAR and TOGGLE. All of them will accept two parameters: variable name and bit position.
For Plov, option G will be most likely. It's rather easy to implement. And it will add three low level functions to an entry level compiler.

Plov : How does the compiler know the port names?

Luckily I am not doing such a thing for the first time. Two years ago I wrote a disassembler for the AVR. There are many AVR processors and most of them differ to a certain degree so I needed a way to make the disaasembler symbolic. So I made a lot of configuration files in which (among other things) I listed all portnames and portnumbers. These files now come in handy.

Yet, there is one thing that pops up: How does Plov know which processor it is compiling for? Ideally this would not be necessary. For a mmicroprocessor it wouldn't be needed. But a microcontroller is littered with special purpose registers and ports, each with a different name. Plov is for microcontrollers so it needs a new keyword. The most logical is to name it 'CPU' and that's what it will be called.

When the compiler is invoked, it will read the CPU specific definitons file to find out which portnames and registernames exist. These will be stored in the symbol table. The backend will later reread the right CFG file to map the portnames in the registerspace.

For an example look here: ../AVR/disman.html, made for the ATmega8515 processor.

Page created on 24 September 2008 and

Page equipped with GoogleBuster technology