For what values of x is the following equation true?   x = |x| (absolute value)

Most people would say, the above equation is value for x >= 0.

For what values of x is the following equation true?   |x| < 0

Most people would claim there are no such values of x, and they would be correct. Except when dealing with computers.

Numbers within a computer are confined to a limited range, dependent on the number of bits in memory that has been allocated. Integers typically get 32-bits and longs get 64-bits. This allows for 4294967296 (integer) and 1.84467440737096E19 (long) possible combination of values to store numbers in. The numbers are encoded with a format known as 2's complement for addition/ subtraction simplicity within the processor, but there is a subtle problem. 4294967296 is an even number. One pattern is used to represent zero, leaving 4294967295 patterns for storing both the positive and negative values. In other words there are 2147483648 patterns for one side and 2147483647 for the other. There is not an even pairing between positive and negative.

As a direct result of the 2's complement number encoding, it is clear to see there is one more possible negative value than positive value. A positive integer maxes at 2,147,483,647 and negative values bottom out at −2,147,483,648.

What happens when we want to take the absolute value of −2,147,483,648? The is not a positive pattern that can represent the number 2,147,483,648. In some programming languages, taking the absolute value of this smallest possible value, results in getting the smallest value back. This can cause problems if your application has logic that requires a positive value and assumes Math.abs() works as expected.

Good static analysis tools like Findbugs have rules to identify a class of errors that can result from Math.abs(), but they aren't fool proof.

I advocate abandoning sized numbers where ever possible. If an application isn't directly interfacing with a network, the file system, or some other hardware component, we should stick to number classes which do not impose an arbitrary limit (like BigInteger in Java).

If we must stick with what fits into a single RAM slot, then I would argue we should arbitrarily shrink the size of MIN_VALUE by one (disallowing 0x80000000). That way Math.abs(Int.MIN_VALUE) == Int.MAX_VALUE. Conveniently, we would then have a free pattern to natively represent the value, NOT_A_NUMBER.

For the past month, I’ve been working part time on a Microprocessor selection tool (micro-tool) that my company plans to use to reduce the time it takes to run a trade study for selecting microprocessors for new projects. The primary aim of the program is to encourage/ force the technical leads to re-use processors from old projects to reduce the learning curve of new parts. This will facilitate code re-use, will allow re-use of existing compilers, and will decrease the time to a final schematic layout. (Surprise, parts often don’t work exactly like the spec. sheets state, and prototype boards must be built to discover differences between real parts and the spec sheet.)

I was the third developer to work on the code, the first being an intern who left at the end of last summer; the second was a junior developer who was let go during layoffs in November. Needless to say, the code was not in great shape. I spent a day looking over the code, held a meeting with the project sponsor, wrote up a short requirement description and got to work.

After two weeks time, the program was running. Searches returned the correct data, the user could enter their trade study criteria, rank the various results against each criteria, and everything was exported to an excel spreadsheet so the artifacts could be archived for future reference. The project sponsor was thrilled, “Now, let’s get this running with the production database tables…”

“Tables?” I asked. Turns out, contrary to what everyone had said previously, the micro-tool would be searching not against one table, but five. Furthermore, the five tables were not homogeneous.

1. Same type of data was encoded with different data types in different tables. Integer in two, floating point in two, and a string in the last.
2. Values were stored with different scales. RAM size was stored as bytes in four tables and as words in the fifth.
3. Key search values, such as ROM size, did not exist in all five tables.

Liberal usage of projecting new columns, renaming columns, and unions allowed me to extend my search routine to all five tables within a day. In a similar amount of time, I extended the display portion of the program to notify users from with database table a result originated.

I recommended merging the various tables, or at least fixing the data types to make them the same across all tables and was given a big red light. Supposedly, there are applications that the electrical engineers use that are tied to the current schema, and they don’t want to risk them breaking. Even after I explained how database views could be used to prevent changes in existing applications. While taking advantage of adding data consistency to the database. It would help if the database administrator was a trained in database management, instead of electrical engineering.

The other day I ran into a very strange issue while debugging a problem at work. We were evaluating a new microprocessor for use in one of our products and had been trying to exercise all the different functionalities the processor had to offer.

I was testing out the input capture functionalities and discovered that the first capture (rising edge of input pulse) always worked correctly, but the second edge was never detected. After some digging, it appeared as though the I2C communication routines were interfering with the capture.

I turned on debugger, ran code and it broke inside the I2C routine, hanging waiting for a reply which was never going to come (test code had no time outs). I commented out all calls to the I2C code within the program, reran it, and the debugger once again broke inside the I2C routine. Somehow, the program counter was jumping to an unused block of code. I know it was unused because the compiler complained about the unused segment.

Putting on my debugger hat, I placed a break point immediately after the first capture, and stepped through the code, one line at a time. On the following line, something strange happened

counter += 1;

Instead of advancing to the next instruction, the program jumped almost to the beginning of memory (15 bytes after the end of the memory mapped register range). I repeated this several times, always with the same result. As an experiment, I rearranged a few lines of code and reran. This time, the code jumped on a different line, but landed in the same location.

The only thing I know of in microprocessor land which can change your execution point is a faulty processor, or more likely, a interrupt occurring. After poking though the map file, I realized the I2C routine was the first executable block in code, and the decoded instruction 0xFF which fills all unused space is a move instruction.

MOV A, B

It makes sense, that a bad jump into unused space would eventually land the code in the I2C routine, but that was triggering the interrupt? A five minute search yielded the solution.

The code we were using was based on example code provided by the vendor. I hacked the various pieces together and changes from interrupt driven function to polling driving functions. Unfortunately, I missed the line in the initialization routine where the input capture interrupt occurred. Most surprisingly, the compiler allows us to enable an interrupt, without defining an interrupt handler. (In this processor, all interrupt controls had direct bit access. They were not grouped together requiring a byte mask.)

The interrupt event occurred and the program counter was loaded with the default value from the interrupt table. We have no idea how 0xFFFF from the table was translated into 0x034A which is where execution picked back up. Commenting out the interrupt enable line resolved our issue and we were able to finish evaluating the board.

Morals:
1) Interrupts are evil. They introduce too much variability into the execution process.
2) Sample code is a great place to start from, but don’t base your demonstration code on it
3) Debugging takes time and patience, take a break once in a while to relax and clear your thoughts

Lately, I’ve been playing around with JavaScript, creating a visualizer for my next AI game competition (in the fall?). I’ve decided to deviate from my past setup; instead of displaying live games on the over head, I will instead be recording player action to a log file and then replaying the results on the overhead. This log file can then be provided to the participant, allowing them a detailed look at all the steps their AI took during a sample game.

The problem I discovered involved the rate at which changes are painted to the screen.

$(".note").html("Message one");
sleep(5000); // example 5 second sleep routine  
$(".note").html("Message two");  

With the above code snippet, one would expect Message one to appear, be displayed for five seconds, and then get replaced with Message two. Instead, something surprising happens. When the script is run, no message appears, the page freezes for five seconds, and then the second message appears. The first message is never displayed.

The cause for this is quite surprising. It appears most browsers (the three I tested) wait until the JavaScript function has completed running before it starts updating the displayed page. I believe this was the case initially because the JavaScript interpreter and the page rendered ran in the same thread, so the two tasks could not be accomplished concurrently. Today, this behavior is probably maintained the same for backwards compatibility. I cannot fathom why this behavior would be written into a JavaScript specification, so that is probably not the culprit.

The fix appears simple, but can get quite complicated. JavaScript provides a time routine, that runs a function of your choosing during each timer tick. (JavaScript does allow for multiple timers to run in parallel)

var id = setInterval ( "desiredAction()",1000 );  
function desiredAction ( ){  
    // action code  
    if(lastAction){  
        clearInterval( id );  
    }
}

This is great if you want to perform the same operation for each tick, but in my case, sometimes I wanted to update text, other times move images. To solve this problem, as I parsed the log file, I queued up all the different events in an array. During the timer tick, I removed the first item in the queue and called the associated function pointer to perform the desired specific action.

function performEventQueueAction(){  
    // verify there are actions left  
    if(window.game.eventQueue.length > 0){  
        var action = window.game.eventQueue.shift(); // remove item in front of array  
        action.func( action.data ); // use function pointer with saved data  
    }  
    // stop rendering when actions complete  
    else{  
        clearInterval( window.game.eventInterval ); // stop timer  
    }  
}  

With this tasking, the page stays responsive because the event handler is available to respond to mouse clicks for browsing to the different portions of the page, and all the game display events occur in the order desired, in the approximate time desired.

I’ve been working on developing a small Java utility for use at my place of work. The utility is used for parsing log files and extracting useful engineering data. Often, this work is performed out in the field literally in the middle of a desert] and most of the time the laptop they are using is handed to them as they are walking out the door to the test range. For this reason, the utility we’ve created has been designed to be as stand-alone as possible, requiring no install.

One of the most requested features is the ability to graph the change of a variable over time. The students on my team identified an open source graphing library that worked perfectly. The problem was we now had to ship two files to the test range, not much, but twice as many as before.

Solution

Using Netbeans we were able to modify the build process to embed the library inside the resulting Jar file. Place the following code in your build.xml file, modifying only the red text to match the name of the final Jar.

<target name="package-for-store" depends="jar">

<!—

http://java.sun.com/developer/technicalArticles/java\_warehouse/single\_jar/

Change the value of this property to be the name of your JAR, minus the .jar extension. It should not have spaces.

<property name="store.jar.name" value="MyJarName"/>

-->

<property name="store.jar.name" value="Bundled_JAR"/>

<!-- don't edit below this line -->

<property name="store.dir" value="store"/>

<property name="store.jar" value="${store.dir}/${store.jar.name}.jar"/>

<echo message="Packaging ${application.title} into a single JAR at ${store.jar}"/>

<delete dir="${store.dir}"/>

<mkdir dir="${store.dir}"/>

<jar destfile="${store.dir}/temp\_final.jar" filesetmanifest="skip">

<zipgroupfileset dir="dist" includes="\*.jar"/>

<zipgroupfileset dir="dist/lib" includes="\*.jar"/>

<manifest>

<attribute name="Main-Class" value="${main.class}"/>

</manifest>

</jar>

<zip destfile="${store.jar}">

<zipfileset src="${store.dir}/temp\_final.jar" excludes="META-INF/\*.SF, META-INF/\*.DSA, META-INF/\*.RSA"/>

</zip>

<delete file="${store.dir}/temp\_final.jar"/>

</target>

What’s happening behind the scenes?

Netbeans performs the following actions to build the final Jar. (Which you can do with a script if you feel so inclined.)

1. Compile all source files to class files
2. Extract all class files from library Jar files
3. Compress all class files (include library files) into new single Jar file