Thursday, April 16, 2015

Illegal Instruction in IBM iSeries (AS400) PASE

Perhaps, most of those who had develop application(s) in iSeries PASE have encountered this very irritating error: "illegal instruction .. bla bla bla .." . Usually, the error shows up at runtime, not when compiling code on PASE. I was very confused back then too. However, upon closer inspection I found out that the culprit is mostly down to this fact:
  • An operating system API defined in AIX also present in iSeries PASE header files.
  • PASE doesn't implement the said API. However, due to  the presence of unaltered AIX header in PASE, the compiler doesn't complain.
  • At runtime, the runtime loader (and "linker") complained that the said API doesn't exist in the OS. This is the source of said "illegal instruction .. bla bla bla .." error.
I have to give credit (sic) to IBM that the error made me nervous back then as I thought the compiler I used + IBM supplied linker "combination" created wrong binary which causes the illegal instruction to be emitted upon linking. Only upon closer inspection that I found the culprit explained above. 

Maybe, you want to ask me: then how the hell am I going to be sure the API I needed is supported or not?
Well, you can consult IBM Redbooks. But, AFAIK, you have to test your binary to be 100% sure because there's no detailed explanation on which API are supported and which are not for recent iSeries OS versions (>= iSeries v5.3).

Friday, March 20, 2015

Shared Memory in Unix - System V vs POSIX API

Many Linux/Unix developers these days already forget the "Unix" war of the 80s and 90s, whereby System V camp (i.e. the "commercial" camp) fought against the opensource (BSD) camp. Recently, I found the relic of those days, lingering in IBM Unix-like API. The system I worked on is not exactly Unix per se, but it has compatibility APIs for IBM AIX API.

Enough with the background story. Now, the task at hand need me to craft a solution requiring shared memory and semaphore API. I was surprised that the said environment doesn't support shm_open() POSIX API. Upon further scrutiny, the system doesn't support all shm_XXX() API. This is where I took a step back and try to look back into the platform history to get the big picture. Then I realize that this system is what was once described as System V compliant. This "standard" predates POSIX to some extent, before Linux and other BSD-derived Unix took to the enterprise. In those times, the enterprise Unix market was mostly served by big Unix vendors, i.e. IBM, HP, Sun, SCO, etc. That was when the System V standard were "ratified" for their customers. Now, back to the problem. If shm_XXX() POSIX APIs are not supported, then what API I'm supposed to use? The answer is the shmXXX() API. Instead of shm_open() and such, you get shmget() and such. Linux and most BSD-derived Unix of today also support the System V API as well. So, these System V APIs could be thought of as portable among most operational Unix system of today.

These are several links explaining how to use the System V shmXXX() family of APIs:
Hopefully, this saves the days of those poor souls (who were like me) trying to use shared memory in "Legacy" Unix-like systems. 

Tuesday, March 10, 2015

GLSL 3.30 in Intel Haswell CPU

This error could show up while trying to run your OpenGL program that uses GLSL on Haswell:
$ error GLSL 3.30 not supported.. 
It's very probably because you don't specifically ask the OpenGL implementation (in this case mesa) for Core Profile because only Haswell OpenGL core profile supports GLSL 3.30, as shown in this Haswell glxinfo dump:
....
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.4.5
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
....
OpenGL version string: 3.0 Mesa 10.4.5
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
....
As you can see, the non-core profile only supports up-to GLSL 1.30. Now, how do you go about asking core profile in your OpenGL application? If you are using freeglut, you can use these functions:

...
#include <gl\freeglut.h>
...
int main(int argc, char * argv[])
{
...
glutInitContextVersion(3,3);
glutInitContextProfile(GLUT_CORE_PROFILE);
...
}
Remember that the initialization code above must be called when you initialize your OpenGL environment. Also, it only applies if you use freeglut library.

Sunday, March 8, 2015

Using Windows Key in Fluxbox

It's easy to add Windows-specific key to Fluxbox. All you have to do is as follows:
  1. Find out how Xorg server recognizes the key. You can use xev for this. You can run xev from xterm or other terminal and observe the name of the specific-key shown in xev log. For example, the Windows key in my laptop is recognized as Super_L by Xorg.
  2. Add the key to ~/.fluxbox/keys file. 
Let me give you an example. Let's add Windows key (Super_L) to my Fluxbox keys configuration file and let the key invokes Fluxbox "root" menu when pressed. This is the snippet from ~/.fluxbox/keys file for this function to work.
#  Windows Key -- show root menu
Super_L :RootMenu

That's it. That's all you need to make Windows key to work as you expected (analog to how the Windows key work in Windows).