What does od mean in mean in pseudo-code? - pseudocode

My lecturer has presented me with the following pseudo-code:
at each timer interrupt
do
• perform analog-to-digital
conversion to get y;
• compute control output u;
• output u and do digital-to-analog conversion;
od
I am wondering what od could mean in this context?
Maybe it is part of the programming language I am not aware of?

'do' and 'od' is a "mirror" text block instruction that start with "do" and read software lines and end instruction with "od", because symbols "{" , "}" not is allowed,not exist, or means other type of instruction. some pseudo-code type with a limited set of instructions like architecture 'RIS' has compilators that read it.

Seems to be the end of the do block. At first I thought it was a loop but it may just be a block that executes once.

Related

How to ignore one or more output bus pins for a module instantiation

I want to ignore one or more bits in an array argument for a module in SystemVerilog.
module x(in a, out [0:3] z);
...
endmodule
module tb;
logic my_a;
logic [1:3] my_z;
// I want to stop having to do this next line:
logic ignore_this_bit;
x myx(.a(my_a), .z({ignore_this_bit, my_z}));
endmodule
What is the proper syntax to do this? I have been doing it just as shown above with a declaration of ignore_this_bit and simply never connecting to that net. But it seems there should be a simpler way. Something like just using a comma and no variable name in the arguments for the module instantiation or maybe using something like 1'bX instead of an output argument bit, or something like that.
Is this affected by the fact that I am using big-endian bit ordering for the vectors here? (I hate it, but I am building code for an old CPU that uses that ordering and it's way easier to match my code to the existing than to fix it.)
This is a hard concept to search for, and I have tried. Does anyone have expertise that can help me know how to do this "the right way"? Thanks.
There is no special way in verilog for ignoring bits of the output. So, your way of using concat with an unneeded variable is a good way for doing it ({ignore_this_bit, my_z}). Naming of this variable is important for readability reasons.
It is not affected by the range description order. It looks like you are ignoring the left-most bit. And the bits are always ordered in the same way, no matter how you describe the range:
bits: 0011
[3:0]: 3 0
[0:3]: 0 3
concat: {ign, 0, 1, 1};
The other way around is to use a variable big enough to connect to the output and then use its bits:
logic [1:3] my_z;
logic [0:3] their_z;
x myx(.a(my_a), .z(their_z));
assign my_z = their_z[1:3];
You should not need to do anything here. This should just work truncating the MSB z[0]
x myx(.a(my_a), .z(my_z));
Think of an output port as an implicit continuous assignment
assign my_z = myx.z;
But if the MSB is not the bit you want to ignore, there is no simple solution. You might want to look at the net alias feature.

Halide::Expr' is not contextually convertible to 'bool' -- Storing values of functions in variables

I am new to using Halide and I am playing around with implementing algorithms first. I am trying to write a function which, depending on the value of the 8 pixels around it, either skips to the next pixel or does some processing and then moves on to the next pixel. When trying to write this I get the following compiler error:
84:5: error: value of type 'Halide::Expr' is not contextually convertible to 'bool'
if(input(x,y) > 0)
I have done all the tutorials and have seen that the select function is an option, but is there a way to either compare the values of a function or store them somewhere?
I also may be thinking about this problem wrong or might not be implementing it with the right "Halide mindset", so any suggestions would be great. Thank you in advance for everything!
The underlying issue here is that, although they are syntactically interleaved, and Halide code is constructed by running C++ code, Halide code is not C++ code and vice versa. Halide code is entirely defined by the Halide::* data structures you build up inside Funcs. if is a C control flow construct; you can use it to conditionally build different Halide programs, but you can't use it inside the logic of the Halide program (inside an Expr/Func). select is to Halide (an Expr which conditionally evaluates to one of two values) as if/else is to C (a statement which conditionally executes one of two sub-statements).
Rest assured, you're hardly alone in having this confusion early on. I want to write a tutorial specifically addressing how to think about staged programming inside Halide.
Until then, the short, "how do I do what I want" answer is as you suspected and as Khouri pointed out: use a select.
Since you've provided no code other than the one line, I'm assuming input is a Func and both x and y are Vars. If so, the result of input(x,y) is an Expr that you cannot evaluate with an if, as the error message indicates.
For the scenario that you describe, you might have something like this:
Var x, y;
Func input; input(x,y) = ...;
Func output; output(x,y) = select
// examine surrounding values
( input(x-1,y-1) > 0
&& input(x+0,y-1) > 0
&& ...
&& input(x+1,y+1) > 0
// true case
, ( input(x-1,y-1)
+ input(x+0,y-1)
+ ...
+ input(x+1,y+1)
) / 8
// false case
, input(x,y)
);
Working in Halide definitely requires a different mindset. You have to think in a more mathematical form. That is, a statement of a(x,y) = b(x,y) will be enforced for all cases of x and y.
Algorithm and scheduling should be separate, although the algorithm may need to be tweaked to allow for better scheduling.

What is the purpose of the pipe character in Go's os.OpenFile flag argument?

When using the OpenFile function in Go's os package, what exactly is the purpose of the pipe character?
Example:
os.OpenFile("foo.txt", os.O_RDWR|os.O_APPEND, 0660)
Does it serve as a logical OR? If so, does Go choose the first one that is "truthy"?? Being that the constants those flags represent, at the heart of them are just integers written in hexadecimal, when compiled how does Go choose which flag to apply?
After all, if the function call were to go by the largest number, os.O_APPEND would take precedence over all other flags passed in as seen below:
os.O_RDWR == syscall.O_RDWR == 0x2 == 2
os.O_APPEND == syscall.O_APPEND == 0x400 == 1024
os.O_CREATE == syscall.O_CREAT == 0x40 == 64
UPDATE 1
To follow up on the comment below, if I have a bitwise operator calculation using os.O_APPEND|os.O_CREATE will that error if the file exists, or simply create/append as needed?
UPDATE 2
My question is two fold, one to understand the purpose of the bitwise operator, which I understand now is being used more as a bitmask operation; and two, how to use the os.OpenFile() function as a create or append operation. In my playing around I have found the following combination to work best:
file, _ := os.OpenFile("foo.txt", os.O_RDWR|os.O_CREATE|os.O_APPEND, 0660)
file.WriteString("Hello World\n")
file.Sync()
Is this the correct way or is there a more succinct way to do this?
It is a bitwise, not a logical OR.
If you write out the numbers in binary, and assign each a truth value 0/1, and apply the logical OR to each of the bits in place i between the arguments, and then reassemble the result into an integer by binary expansion - that's the | operator.
It is often used in a way that is commonly described as a "bitmask" - you use a bitmask when you want a single int value to represent a (small) set of switches that could be turned on or off. One bit per switch.
You should see in this context, A | B means "all the switches in A that are on, as well as all the switches in B that are on". In your case, the switches define the exact behavior of the file open/creation function, as described by the Go manual. (And probably more in detail by the Unix manpage I linked above).
In a bitmask, constants are typically defined that represent each switch - that's how those O_* constants are determined. Each is an int with exactly one bit set and represents a particular switch. (though, be careful, because sometimes they represent combinations of switches!).
Also:
^A // All of the "switches" not currently on in A
A&^B // All of the "switches" on in A but not on in B
A^B // All of the "switches" on in exactly one of A or B
, etc.
The operator | itself is described in the Go manual here.
It is a bitwise OR operator. Its purpose being used here is to allow for multiple values to be passed as a bitmask. Thus you can combine flags to create a desired result such as using the OpenFile() function to create a file if it does not exist or append to it if it does.
os.Openfile("foo.txt", os.O_RDWR|os.O_CREATE|os.O_APPEND, 0660
The constants being passed as arguments from the os package are assigned values from the syscall package. This package contains low-level operating system independent values.
Package syscall contains an interface to the low-level operating system primitives. The details vary depending on the underlying system, and by default, godoc will display the syscall documentation for the current system. If you want godoc to display syscall documentation for another system, set $GOOS and $GOARCH to the desired system. For example, if you want to view documentation for freebsd/arm on linux/amd64, set $GOOS to freebsd and $GOARCH to arm. The primary use of syscall is inside other packages that provide a more portable interface to the system, such as "os", "time" and "net".
https://golang.org/pkg/syscall/
As noted by #BadZen, a bitwise OR operator, in this case the '|' character, acts at the binary level changing any 0 values to 1's that are not already ones.
You should see in this context, A | B means "all the switches in A that are on, as well as all the switches in B that are on".
By doing this as the function above displays, you are manipulating the behavior of the function to create a file (os.O_CREATE) with the given name of foo.txtor open the file for reading/writing (os.O_RDWR) and any value written to it will be appended (os.O_APPEND). Alternatively you could pass along os.O_TRUNC in order to truncate the file before writing.
The bitwise OR operator allows you a powerful solution to combining different behaviors in order to get the result from the function that you are desiring.

When should endfile be used, before or after reading?

While looking for examples of reading text from a file (using readline and read), I constantly see code like the following, but haven't found information on what exactly endfile does.
while not endfile(in_file) loop
readline(in_file, in_line);
read(in_line, in_data);
end loop;
In all other languages I know, end of file would be checked after reading the line from the file, not before.
What exactly are the semantics of endfile that make this usage correct?
From the IEEE VHDL Standard:
3.4.1 File operations ... Function ENDFILE returns FALSE
if a subsequent READ operation on an open file object whose access mode is read-only can retrieve another value from the file; otherwise, it returns TRUE.
So checking endfile prior to reading from the file is correct, since endfile returns false as long as another value/line can be read.
There are several languages which use an eof function or statement to determine the end of a file. These languages or library have no special return value (-1, null, nil, ...) or even a exception mechanism to report a failed read(..), so in this case its necessary to test eof before a read(..) and proof that one more read(..) won't crash the program.
Edit 1
zennehoy asked for some language examples, which use this kind of EOF statement/function:
Example 1: QBasic
open "file.txt" for input as #1
do until eof(1)
input #1,name$,street$, ...
loop
close #1
Example 2: Windows Scripting Host (WSH), alias VBA, alias VB Script:
do until fileHandle.atEndOfStream
[...]
loop
Example 3: if I remember correctly this would be Pascal
Ansi-C has also a eof functionality, but in many cases its not necessary to use it, because you can determine the end of a file, if read(..) returns less bytes than the requested bytes.
But this won't function if you are reading from streams/pipes/... because read can return less bytes and after several milliseconds there are more bytes and you can read again. A test for EOF will assure you, that a writer on a stream is closed.
Another example language where the end of file status is tested first is Ada as in while not End_Of_File loop, where End_Of_File is a function in package Ada.Text_IO and the default value for it's single argument of type File_Mode is In_file. As of Ada95, End_Of_File only operates on files of mode In_File or Inout_File otherwise generating an exception. (While endfile will return FALSE for WRITE_MODE in VHDL).
Early implementations of VHDL included preprocessors for Ada in the days of big iron. You can see the influence throughout the LRM. For instance there is no coupling between bit positions and integer values or description of a float format. These happen to allow VHDL to operate on a computer with native decimal ALUs.

state chart of brainfuck interpreter

i have written an alpha version of an brainfuck ide. i wrote my own interpreter although i had massive help from my teacher regarding loops in the code because i had a really hard time understanding it in the "IT way". now for my report i need a state chart of the algorithm of the interpreter, how he handles each char.
i have come up with the following diagram, only thing missing is how the interpreter handles loops. i looked at the code my teacher wrote almost by himself but i dont understand it. i hope you can point me in the right direction here, i dont want a finished answer just a few sidenotes what is being done when an [ or ] is encountered in the code.
codeZeiger = codePointer (the pointer which moves through the code)
memoryZeiger = memoryPointer (the pointer wich moves through the memory stack)
memory = the memory stack
code = the code as a string oject
i = counter of the interpre() method (single chars are read from the string and then parsed through a switch statement whose statechart you see below)
You should really try to understand the looping mechanism. In brainfuck, loops are enclosed with [ and ]. That means the code inside the brackets will execute and start all over again if a certain condition is met. For example:
1: [
2: cmd1
3: cmd2
4: ]
5: cmd3
Line 1 checks whether memory[memoryZeiger] is equal to 0. If it is, it jumps to line 5. If not, it executes cmd1, cmd2, and so on up to line 4. If your interpreter is on line 4, it automatically jumps to line1 (or it could check the condition and move one step further - but let's keep it simple and assume it jumps to line1). Then the whole process starts again.
So to answer your question about the state diagram. You need something like this:
_____________________________
| code[codeZeiger] == '[' |
-----------------------------
/ \
/ \
memory[memoryZeiger] == 0 memory[memoryZeiger] != 0
| |
"go to matching ']'" codeZeiger++
The other case for ] should be equivalent.
Btw, "matching ]" is important. Those brackets can be nested!
1) you don't need a statechart, as your compiler does not have states (only memory, memory pointer and code pointer and possibly two for finding the matching bracket) - a simple table like on wikipedia (german like your variable names) would be enough
2) if you stick to a statechart don't put conditions (like code[codeZeiger]=='+') into states but on the transitions
3) i must be changed to codeZeiger instead
4) The code to interpret brainfuck should be very simple. If you don't understand it read e.g. the wikipedia page and try to interpret the program given there without a software. Let it run on paper :)

Resources