|
CO538 Anonymous Questions and Answers |
This page lists the various questions and answers. To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.
We have taken the liberty of making some minor typographical corrections to some of the questions as originally put. Although most of the questions here will have been submitted anonymously, this page also serves to answer some questions of general interest to those on the course.
When asking questions, please do not simply paste in your code and ask what is wrong with it, as these types of question are hard to answer in a public forum (resulting in either no answer, or an answer which will only be of use to the person asking the question). In many cases, a question about code can be formulated in general terms. For example, if you have an `IF' block that results in an `incorrect indentation' error, you might ask, ``what is the correct syntax for an occam `if' statement ?''. Questions of this form are easier to answer, and are meaningful to all.
Questions that are not suitable for these public pages (i.e. those that contain assignment-specific code), should be mailed to your seminar-leader.
What *exactly* does SEQ do and when is it *not* necessary?
occam lets us write parallel code with the same fluency as it (and other languages) lets us write sequential code. So, whenever we have a collection of statements, we have to say whether they are to be executed in SEQuence (in the order written) or in PARallel (in which case, the order written is irrelevant). For example, the statements:
in ? n -- input from channel, in, to variable, n
a := 2*n -- multiply n by 2 and assign the answer to a
only make sense for SEQuential execution. The way we specify SEQuential execution is to indent them as the body of a SEQ construct:
SEQ
in ? n -- input from channel, in, to variable, n
a := 2*n -- multiply n by 2 and assign the answer to a
On the other hand, the following statements:
in ? n -- input from channel, in, to variable, n
a := 2*b -- multiply b by 2 and assign the answer to a
are logically independent from each other. In this case, we can choose whether to have them executed in SEQuence (as above) or in PARallel:
PAR
in ? n -- input from channel, in, to variable, n
a := 2*b -- multiply b by 2 and assign the answer to a
Aside: occam does not allow us to specify PARallel execution of statements that interfere with each other's variables (or channels) - these rules are made precise in section 4.2 of the occam2.1 Checklist. So, the construct:
PAR
in ? n -- input from channel, in, to variable, n
a := 2*n -- multiply n by 2 and assign the answer to a
would be rejected by the compiler.
Note: the statements controlled by a SEQ (or a PAR) must be indented by two spaces. There can, of course, be any number of statements -- not just two as in the above examples. The end of the construct is indicated by outdenting back to the level of the controlling SEQ (or PAR).
Keywords: seq , sequential-execution
Referrers: Question 28 (2003) , Question 56 (2003) , Question 3 (2000) , Question 28 (2000)
Is PAR used *only* when connecting all PROCs to build the final one big PROC?
No. See the above answer for an example use of PAR to build some very fine-grained parallel code. It all depends on the code you write into the components of the PAR. In the above, they are short-lived primitives (a channel input and an assigment). If the statements controlled by the PAR and instances of PROC calls and those PROCs are long-lived (e.g. they contain loops - possibly infinite), then we get a long-lived process network. See, for example, slide 4-26 from the course notes. [BTW - has everyone found the deliberate mistake on slide 4-26?]
occam lets us easilly build parallelism at any level in the system - this is much more flexible than Java, for example, whose Thread mechanism is considerably more complex to set up.
Keywords: par , process-networks
What is the scope of declarations? In my code:
SEQ
BOOL running:
running := TRUE
WHILE running -- compiler says running is not declared!
... body of the loop
the compiler says the running variable is not declared on the "WHILE" line - even though it has just been declared and initialised!
Following a declaration (e.g. of your "running" flag), the item declared has scope in any subsequent declarations (which must all remain at the same level of indentation) and in the executable code that follows it (also at that same level of indentation).
In your case, the executable code following the declaration is only the initial assignment and not the WHILE-loop. It can't be both since two statements, without an enclosing SEQ or PAR, do not make up a legal executable - see Question 1 (2000).
Your declaration is in the wrong place. It should be:
BOOL running:
SEQ
running := TRUE
WHILE running -- running is still in scope
... body of the loop
The scope of "running" is the executable following its declaration. This time, that executable is the whole SEQ construct - not just its initial assignment.
Keywords: variable-scope
Referrers: Question 54 (2004) , Question 21 (2003) , Question 29 (2000)
For questions on source code (q*.occ etc) should I be emailing you or the supervisor?
Mail your supervisor in the first instance - then me or the newsgroup or this anonymous question page.
Keywords: questions , getting-help
Was Q1 a little bit over our Occam level, or is it just me? :)
We still have not covered enough occam in the lectures to answer this. However, by looking ahead in the slides a little bit and reading the first 6 or so pages of the occam2.1 Chekclist ... and by working with friends, you should be able to crack it! It's a challenge and is not for assessment. You should certainly be able to do it by the end of next week (27th. October) ...
Keywords: q1
I am trying to do question 1. Is there a way of signifying the end of an IF statement? Below, I have covered all cases and want to continue running after having been though one of the paths in the IF block. But the compiler keeps telling me that the line "a ! value" is incorrectly indented - I don't want it to be part of the IF block! To me the to 'backdent' the lines seems fairly logical as they are no longer part of the IF block.
-- if state is false do function f, else do function g
IF
state = FALSE
SEQ
IF
value = 0
SEQ
value := 1000
value > 0
SEQ
value := 2*value
state = TRUE
SEQ
value := value/3
-- output this, invert state & loop
a ! value
state := NOT state
Your problem is that you wish to execute the "a ! value" after executing the IF block. Probably you want to execute the state assignment afterwards as well. See question 1 above. To do this, you have to enclose these three statements inside a SEQ block:
SEQ
-- if state is false do function f, else do function g
IF
state = FALSE
SEQ
IF
value = 0
SEQ
value := 1000
value > 0
SEQ
value := 2*value
state = TRUE
SEQ
value := value/3
-- output this, invert state & loop
a ! value
state := NOT state
By the way, your inner SEQs (all four of them) are redundant since they only enclose one statement - excuting one statement is sequence with nothing is just executing one statement! So, it simplifies to:
SEQ
-- if state is false do function f, else do function g
IF
state = FALSE
IF
value = 0
value := 1000
value > 0
value := 2*value
state = TRUE
value := value/3
-- output this, invert state & loop
a ! value
state := NOT state
Your first comment has redundant information describing the way the IF statement works. The rest of its information is useful but should be localised to where it is relevant. Your choice of state name is not very meaningful and could be improved. Also, when testing booleans, extra bits like "= TRUE" are redundant. In the following, your state boolean is replaced by f.next, whose value is the inverse of your state:
SEQ
IF
f.next
IF -- do function f
value = 0
value := 1000
value > 0
value := 2*value
TRUE
value := value/3 -- do function g
a ! value
f.next := NOT f.next -- end of loop
Now that's a bit simpler and clearer ... ;-)
But ... it's still not the simplest way to program this PROC A ... :-(
Keywords: incorrect-indentation
How can I cast an INT to a BYTE ?
If x is an INT variable whose value is between 0 and 255 inclusive, then (BYTE x) is its BYTE equivalent. If x were outside the BYTE range, then (BYTE x) would give a run-time error.
In general, to cast from one primitive type to another, use the target type name as a prefix unary operator. For casting between certain types, rounding considerations become necessary (as the precision available in the target type is less than that of the source) and we have to state how the least significant bit is to be resolved (either by ROUNDing or TRUNCation). The details are low-level but, for some applications, crucial to get right. If you want to know more, look at the file:
examples/casting.occ
which you should already have copied from the co516 course directory.
A key point to remember is that there is no automatic casting between data types in occam - what-you-see-is-what-you-get!
Keywords: cast
Referrers: Question 32 (2012) , Question 87 (2003) , Question 10 (2002) , Question 8 (2000) , Question 66 (2000) , Question 74 (2000)
In PROC B from question 1 of the OCCAM EXERCISE SHEET, I have got the program to work by using the procedure:
out.int (x, field, out) -- the out channel is connected to the screen
However I was wondering if there is any way to do it without using that procedure?
Well, you certainly can't:
out ! x -- won't compile!
since out must be a channel carrying BYTEs and x must be an INT.
Casting it into a BYTE (see Question 7 (2000)) won't help either:
out ! BYTE x -- will compile but is wrong!
Suppose x were the INT 65. What we want to do is output the ASCII codes for the characters '6' and '5' to the screen - this is what the PROC out.int does. If you cast x into a BYTE as above and send that to the screen, what you would see on the screen is the character 'A'!
So, you have to use out.int (or something that does a similar job).
Keywords: q1
When I compile some occam and the compiler generates loads of error messages, they flash past too fast for me to read?
The simplest solution is to get a scroll bar on your window. For a normal eXceed window, make sure you have focus (i.e. when you type, you type into the window) and just do [CTL & LEFT-MOUSE-CLICK]. A scroll bar should appear. To operate it, point and drag with the MIDDLE mouse button.
Now, when all those error messages flash by, you can scroll them back and have a chance to look at them!
Tip: only bother with the first one or two messages. Fix them and re-compile. Often, the later ones were not reporting real errors - it's just that the compiler was thrown too badly by your initial mistake(s).
Keywords: compiling
Referrers: Question 13 (2000)
How do I see the /usr/local/work/co516 files from Windows? I want to print some of them and I want to do that from Windows ...
I assume you have mapped your home (raptor) directory so you can see it from Windows. Set up a unix soft link as follows. On raptor, change to your home directory. Then, type the command:
ln -s /usr/local/work/co516 co516
This will create a file (in your home directory) called co516. This file acts like a directory. If you cd to it, you will find that you are taken to the course directory.
What's more, co516 looks like a sub-folder when you view your (raptor) home directory from Windows. Double-click on it to browse through the course sub-folders.
Keywords: raptor
We were told in our class that there is a process called minus that we can use in answering question 2. If this is the case, then where is the process as it's not in demo_nets or demo_cycles? If this is not true, then can we make up process called minus?
You must have mis-heard. There is no process called minus in the course library. For question 2, you must make up your own - use the process called plus, which is in the library (in demo_cycles) and which was presented in today's lecture (slide 5-5), as a model.
Keywords: q2
Having missed the lecture, I can't understand the operation of the nos, int and pairs networks. I can't match them to te sequential version. Some help, please?
I'm afraid these pages are for more specific questions than this - not to repeat the lecture notes. Please get to the lectures because things get explained there that might not be obvious from just looking at the course slides. However, nos and int, at least, are discussed in the Occam Approach to Transputer Engineering paper in the course book ... and you are also talking about these things in your seminar groups.
Keywords: legoland , process-networks
I am doing q2. When I run it I can't tell if it is working properly because once I break, I can't scroll up and see whether the 0 appears in the output. Is there any way of dumping my ouput to a file so I can see it all?
The simplest answer is to get a scroll bar - see the answer to Question 9 (2000) to find out how to get one.
It is possible to redirect your output to a file - but, in this case, that's not a good idea since the output is infinite and you will flood the disc!
Simpler is to pipe your output through the Unix more utility:
q2 | more
Now, you only get a screenful at a time. Press carriage-return to see one more line or space for a further screenful. To end your program, type ctl-C. Warning: do not type q to quit the more program. That sends a broken pipe signal to the occam process which doesn't handle it properly. Your occam program will exit but not reset keyboard input to echo mode. That means that you get back to the Unix prompt and type in commands ... but you won't see those commands. To restore things to normal, type in (blindly!):
stty sane
and you will now be able to see what you type again.
An alternative to all this is to slow down the output so that you can read it! For example, put in a tenth of a second delay after printing each output line. Then, only 10 lines per second will be displayed and you will have time to check if your output sequence starts with a zero. One way to do this is to modify the tabulate.int (see the latest version of q2.occ) as follows:
PROC tabulate.int (CHAN OF INT in, CHAN OF BYTE out)
WHILE TRUE
INT n:
SEQ
in ? n
out.int (n, 15, out)
out.string ("*c*n", 0, out)
--{{{ delay 100 milliseconds
TIMER tim:
VAL INT milliseconds IS 1000: -- TIMERs measure microseconds
INT t:
SEQ
tim ? t
tim ? AFTER t PLUS 100*milliseconds
--}}}
:
Referrers: Question 24 (2003) , Question 7 (2001)
I have completed q2.occ and as far as I can make out, it works!!!
My class supervisor said we had to produce 2 chip diagrams to hand in as part of our assignment. Am I right in thinking they are:
Is there any particular program I should use to create the diagrams? I done them in Word, using the flowchart symbols, but it don't look that great.
Also, how do I print my source code from Origami on a public PC????
Yes to your first question - you do have to submit these two diagrams as well as your code listing.
No to your second question - the quickest thing is simply to draw them neatly by hand on your listing (next to the occam code that implements each diagram).
Origami doesn't have a print command. The files it produces are, of course, plain text. So you could pick up q2.occ (say) in a Windows editor (e.g. PFE) and print from there. Or you can print the file directly from Unix.
To help with the latter, there are two commands (pt and pq) in the etc directory in the course area:
/usr/local/work/co516/etc/pt /usr/local/work/co516/etc/pq
If you haven't already done so, make a bin directory in your home directory and copy the above files over to it:
mkdir ~/bin cp /usr/local/work/co516/etc/p* ~/bin
Then, set this ~/bin directory to be the first item in your path environment variable. This can be done by editing the definition of that variable in the .cshrc file in your home directory (if you are using the C-shell) or the .bash_profile file in your home directory (if you are using bash). If your unix command prompt ends with %, then you are using C-shell - if it ends in $, you are using bash. The syntax of how to set these environment variables is different for the different shells - but you can work it out from how they are already defined.
Once the above has been done, to print a file (say q2.occ) to a printer (say myprinter), the command is:
pt q2.occ myprinter
To inspect the print-queue on a printer (say myprinter), the command is:
pq myprinter
Keywords: diagrams , q2 , printing
Referrers: Question 15 (2000)
Please could you tell me who, and where, do we submit this assignment (q2) to?
As explained in the seminars, you must submit hard copy listing plus diagrams (see answer to Question 14 (2000)), attached to a cover sheet, to the CAS office by their close of business this Thursday (9th. November). Cover sheets were given out during seminars or may be obtained from the Co516 pigeon hole near CAS reception.
Keywords: q2 , submission
I'm having trouble using the tabulate.int procedure. I have a simple piece of code like:
CHAN OF INT c:
WHILE TRUE
PAR
numbers (c)
tabulate.int (c, screen)
:
which compiles but prints nothing to the screen when it is run. What am I doing wrong?
Firstly, the above code fragment cannot compile. The final colon cannot be at the same level of indentation as the CHAN declaration. It must be the terminating colon of a PROC declaration and, so, must be aligned with the PROC header line which must be to the left of the above code fragment.
Secondly, there is not enough information here to answer your question. Where is the screen channel declared? Is the instance of this process properly connected to the screen channel parameter of the main (q2) PROC?
Finally, the WHILE TRUE line serves no purpose. Its body never terminates - so the body never gets repeated! Delete that redundant WHILE-loop.
On q4, when I convert plus to minus in pairs ... should the output from pairs be one greater than the output from numbers along the same row of data? For example, if the current numbers value is 7, then the value in the pairs column on the same line is 8 ...
Yes. (I'll say a bit more when the q2 submission deadline is over ...)
Keywords: q4
You say that when any other key is pressed for q4, then it should bleep ... How do we do this?
If out is the parameter channel (that will be connected to the Unix screen channel), to get a bleep from your terminal:
out ! BELL
where BELL is the ASCII BEL character, already declared in the (#INCLUDEd) consts.inc file as follows:
VAL BYTE BELL IS 7:
Referrers: Question 21 (2002) , Question 11 (2001)
Can you remind me where the occam files are stored which we should copy to update ours?
This information was posted to the newsgroups on the 3rd. November and should still be viewable. A copy of that posting was also saved on raptor:
usr/local/work/co516/news/2.txt
For a more permanent record, the important parts - plus some new information - are given here.
The starter files (q*.occ) in the occam/exercises directory in the course area on raptor have been updated. Please could everyone take a new copy. First, change to your version of this directory - e.g.:
cd occam/exercises
Then, copy over the updated files:
cp /usr/local/work/co516/exercises/q*.occ .
You will now have new versions of q1.occ through q7.occ. The difference between these new versions and the old ones is that the nested PROC declarations have been pulled to the outermost level of each file. The nested PROCs were perfectly legal and correct ... but I now think that flattening out these declarations leaves things a little neater and, therefore, easier to follow. There was no need for them to have been declared nested within the top-level PROC, so let's not do it.
The new version of q2.occ has one other change. It replaces the peculiar PROC layout.max.chans (which has more functionality built into it than you need for this question) with the simpler PROC tabulate.int.
[layout.max.chans tabluates an array of max.chans integer input streams to a text output stream that displays max.chans columns of numbers - with (the ASCII text form of) each input stream integer displayed on each row. The tabulate.int process does the same for just one integer input stream, producing a single column of numbers.]
Also: the example files in the occam/examples directory in the course area on raptor have been given similar treatment. Please take new copies. First, change to your version of this directory - e.g.:
cd occam/examples
Then, copy over the updated files:
cp /usr/local/work/co516/examples/*.occ .
You will now have new versions of these files - however, only the following are different:
demo.occ sort_pump.occ sort_inside.occ casting.occ
Thise differences are just the movement of inner PROC declarations to the top level - apart from casting.occ, where only the formatting of its comments have changed.
Keywords: raptor , course-files
Any chance that next time you clear the question/answer page you could place new questions/answers at the top of the page? This makes it easier to see new submissions, rather than having to scroll to the bottom.
Will do! But the completed pages will be archived in ascending order - it makes more sense to review those questions in the order they were asked (which roughly corresponds to course order). However, the current page of questions will, in future, be built up in reverse order.
|
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. |
