So I'm emulating an extra instruction in C for the MSP440 called IFcc, where cc is the condition. How it works is if the condition is true, then the 'true instructions' are executed, and the 'false instructions' are skipped, and vice versa if the condition is false. The instruction takes two arguments, TC which is the number of instructions to execute if condition is true, and FC which is the number on instructions to execute if the condition is false.
Here is an example of what the assembly code might look like:
CMP &ALPHA,&BETA
IFEQ 2,2 ; Execute the first and second instructions if ALPHA = BETA
; or the third and fourth instructions if ALPHA BETA
MOV #0,&ALPHA ; Executed if ALPHA = BETA
MOV #1,&BETA ; Executed if ALPHA = BETA
MOV &BETA,&ALPHA ; Executed if ALPHA ≠ BETA
ADD #1,&ALPHA ; Executed if ALPHA ≠ BETA
What I'm having trouble figuring out, is how to ignore the instructions that should not be executed. The assembly itself wouldn't be changed to use branches, because the point of the IFcc instruction is to eliminate the necessity for branches. Any help with this would be greatly appreciated.
I dont recognize that instruction, is this an instruction you are inventing within your emulator?
Assuming that is the case
The msp430 instruction set is variable word length so if you want the logic to simply say do or dont execute the next two instructions, you have to specify instructions, but you wont know until the first words of each are decoded to know how many words that is, but that doesnt matter you put a counter in and count down the number of instructions, and simply dont do the execute or write back stages of the pipe.
at the end of the day all you are doing here is a branch on condition or branch on not condition, how is this instruction different? not flushing the pipe vs flushing the pipe? who is to say that a branch flushes the pipe in current/modern designs, if the branch is near enough and the pipe is deep enough there may be an optimization in the design to not flush and refill but to instead just keep going and skip (for the very common cases where the branch is forward by some small number of words).
the simplest is to just branch, set the pc to the word after the instructions skipped, you should have already implemented this in a branch, but the ASSEMBLER should be the one responsible for computing how many words there are in the next N instructions. It may be that a skip two instructions in one case is skip over two words (add 4 to the pc) or it could elsewhere mean that skip over two instructions means skip 5 words. Just like the implementation of a branch where you specify a label and the assembler takes care of making multiple passes and finally computing the offset to where the label would be in the instruction flow. which basically means make this a branch with a label.
if you dont want to make this a branch with a label then you have to pretend to execute the next N instructions to the point that you decode them enough to know how many words wide they are and skip that many words, repeat for the number of instructions to skip. runtime there is no other way to do it.
It turned out I needed to just prevent the instruction from writing back to memory by putting some conditions around the memory write function. Depending on the state of the machine (unconditional , true condition, false condition), which would be set by IFcc, it would either write to memory or be prevented from writing to ememory
Related
I'm trying to redo the work of paper 'Neural Machine Translation Inspired Binary Code Similarity Comparison beyond Function Pair', but I failed to complete some components.
The author said 'We modify the backends to add the basic-block boundary annotator, which not only clearly marks the boundaries of blocks, but also annotates a unique ID for each generated assembly block in a way that all assembly blocks compiled from the same IR block '.
I don't know how to mark the boundaries of a block to determine if several assembly codes for different architectures come from the same source code with LLVM or other tools.
I appreciate every help.
Well, given a Function you can iterate over its BasicBlocks with .begin() and end(). This will give you a BasicBlock, for which you can always do .front() and .back() to obtain first and last instruction, respectively. This will give you "boundaries" of each block and the function.
UPDATE
I came up with an idea how to do it, if you want "boundaries" to be present in the compiled source.
At the begginning of each function you can generate store instructions that would store blockaddress value for each block of the function. If I'm not mistaken, these would turn into movs at assembly level, one operand of which would be a basic block starting point. This will allow you to infer "boundaries".
There are two parts to this problem:
which not only clearly marks the boundaries of blocks
Each basic block is terminated by a Terminator instruction. It can be a branch for example.
but also annotates a unique ID for each generated assembly block in a way that all assembly blocks compiled from the same IR block '.
This looks like some hashing mechanism. If you iterate over non-dbg instructions and hash_combine each of them to generate a unique ID for each basic block. That should serve the purpose. For example, see how MergeSimilarFunctions.cpp:profileFunction does hashing of each instruction.
One thing to keep in mind would be how to preserve the information created as a result of above hashing. You can add the information as a metadata or print the information to a file somewhere for later reference.
From An Integrated Approach to Software Engineering
By Pankaj Jalote
Clearly, no meaningful program can be written as a sequence of simple
statements without any branching or repetition (which also involves
branching). So, how is the objective of linearizing the control flow
to be achieved? By making use of structured constructs. In
structured programming, a statement is not a simple assignment
statement, it is a structured statement. The key property of a
structured statement is that it has a single-entry and a
single-exit. That is, during execution, the execution of the (structured) statement starts from one defined point and the execution
terminates at one defined point. With single-entry and single-exit
statements, we can view a program as a sequence of (structured)
statements. And if all statements are structured statements, then
during execution, the sequence of execution of these statements will
be the same as the sequence in the program text. Hence, by using
single-entry and single-exit statements, the correspondence between
the static and dynamic structures can be obtained.
The most commonly used single-entry and single-exit statements are
Selection: if B then S1 else S2
if B then S1
Iteration: While B do S
repeat S until B
Sequencing: S1; S2; S3;...
What do "single-entry" and "single-exit" mean in a structured statement?
Why are statements listed at the end are single-entry and single-exit?
For example, in if B then S1 else S2, why is it single exit, given it can terminates at either S1 or S2?
Can you give a statement which is not single entry?
Can you given a statement which is not single exit?
In many languages, the only statements that do not have a single entry are those which happen to contain labels for use with goto or switch statements located outside them, and the only statements that do not have a single exit are those which contain a goto to an outside location, trigger an exception, or otherwise force stack unwinding. Note that for any particular call of a function, the only "normal" exit point will be the code immediately following that call.
The notion of single entry/single exit may be unclear to those who have never worked with code that didn't use such an approach. Examples of the latter may be found when writing code for the platforms like the Atari 2600 where RAM space is often at an absolute premium. If a piece of code will be invoked from the code that shows the title screen, or from within the game logic, and there one can't afford the two bytes of stack space necessary for a subroutine-call instruction, it would not be uncommon to jump to the code (rather than using a "JSR" [jump to subroutine] instruction), and have the code exit by checking whether a game is in progress and jumping back to the appropriate spot in the "show title screen" or "perform game logic" code. Such a design may be awkward to maintain if it becomes necessary to invoke it from more places in the code, but such techniques may be necessary if RAM is really tight (e.g. one only has 128 bytes total, as on the Atari 2600).
I'm debugging the goldfish android kernel (version 3.4), with kernel sources.
Now I found that gdb sometimes jump back and forth between lines, e.g consider c source code like the following:
char *XXX;
int a;
...
if (...)
{
}
When I reached the if clause, I type in n and it will jump back to the int a part. Why is that?
If I execute that command again, it would enter the brackets in the if.
If possible, I want to avoid that part, and enter the if directly (of course, if condition matches)
When I reached the if clause, I type in n and it will jump back to the int a part. Why is that?
Because your code is compiled with optimization on, and the compiler can (and often does) re-arrange instructions of your program in such a way that instructions "belonging" to different source lines are interleaved (code motion optimizations attempt (among other things) to move load instructions to long before their results are needed; this helps to hide memory latency).
If you are using gcc-4.8 or later, build your sources with -Og. Else, see this answer.
loop
if rising_edge (CLOCK) then
fcounter := fcounter+1;
end if;
A<=fcounter(6); --fa=fclock/2^6
if rising_edge (A) then
counter_A:= counter_A+1;
end if;
CIKIS<=A; --40 consecutive "1" consignment to DIN for STARTUP RESET
exit when counter_A=101000; --40
end loop;
ISE gives "ERROR:Xst:1312 - Loop has iterated 64 times. Use "set -loop_iteration_limit XX" to iterate more." What does that mean and what should i do to get rid of it?
Unbounded loops are not generally synthesizable outside of generating constants. The error is telling you that the loop has iterated beyond the preset limit that guards against infinite loops. Increasing the limit will not fix anything because what you have described doesn't map naturally to hardware with the current crop of synthesis tools.
You need to restructure your logic to inhibit that block of code with an enable that is deactivated when the counter reaches its terminal value rather than use a loop.
Synthesizable constructs can't have compile time unbounded loops like this, they are only to be used in testbench code. The reason is that when they expand into hardware, something like this would require infinite resources (which you don't have). You seem to be trying to write this like a piece of software. When using a HDL, you need to be thinking of how it translates into hardware (assuming you plan to synthesize). Instead you might look at using a process where all activity happens inside an "if rising_edge(clock)", and use signals to explicitly use flip flops as opposed to variables which could go either way. It isn't entirely clear to me if you're trying to count when your fcounter rolls over 40 times (what you currently do) or when your fcounter exceeds 0111111 for 40 clock cycles, but you can use a signal indicating the state for either case instead of an exit statement, and an if/elsif statement on that signal to do something else when you don't want to have process counting. Sorry for the poor formatting, short on time.
I'm new to LabVIEW but have been building a signal analyser code that takes the required data and prints it out to text files after the data has been taken. The problem I'm having is that when it makes a new file it holds on to the data from the previous run and prints that too which is not what I want. I've attached the LabVIEW vi (ver.2009), and any help with this would be greatly appreciated.
Also if someone knows a better way of RMS-ing the data after each iteration than my mess of shift registers I'd be happy to see it.
frequency analyser (fixed).vi
To answer your main question: the part of the code that builds the string (for loop with a shift register) stores the previous data each time you re-run the vi. What you need is to initialise the shift register with an empty string :
Also a couple of notes/suggestions:
You could avoid using shift registers in this case. Divide the DAQ part of the code into say 3 parts: acquire data in the first for loop (store into array), modify the array (you could then perhaps use the build-in RMS vi), visualise on the UI
Build the code in smaller chunks, use subVi's
Keep the code small, nice and tidy (check coding standards), add comments - this will really help you later
Since you asked for advice on the RMS functionality you used I took a more detailed look of your code. And I may be harse, but it doesn't make sense (point by point):
You ask the end user for a number of runs, and then you subtract one. Why? I guess it's because the read data before the for loop. (remove that one).
The Frequency RMS function you use has support for avaraging, and has no limit of the number of averages. Specify the following configuration:
This will add RMS avaraging to you output data, and you can loose all your own calculation with shift registers.
The following code is just plain wrong:
You only shift the data, without actually changing the data. By incrementing the starting frequency you shift the FFT. So a signal that was detected at 55 Hz, no is plotted at 56 Hz. To your end user this is misleading.
One thing you need to be aware of in your code is that you don't have continious sampling. Each iteration of you for loop your data acquisition is started and stopped. You can verify this by plotting the t0's of the waveform that is captured. You'll notice they don't start at a constant interval.
A better aproach is to use the task created by the Express VI in the first iteration:
.
However you should then change the acquisition mode to 'continious samples':
Do not forget to close the task in the last iteration:
Instead of the shift register, you should work with an array which you empty before each run.