CRiSP Weblog

Been playing with threads for CRiSP..to see how we could offload some processing to other threads. Its a big issue as it involves lots of changes to the code base. But with the advent of dual core chips and more in 2005 and beyond, we need to look ahead to see if we can utilise some of the spare processing power on a machine.

CRiSP originated on a 12MHz 80286 CPU and performance has always been a consideration. As we have zoomed into the tens, hundreds, and now, thousands of gigahertz, CRiSP has maintained its highly optimised performance even when faced with huge tasks (such as syntax coloring and dynamic tagging).

CRiSP runs adequately fast enough on 300MHz CPUs and below, and is more or less instantaneous for all tasks on todays multi-gigahertz CPUs.

But out of curiosity, it is interesting to see what could be done to some parts of the contents window or other macros which can take a long time to execute due to filesystem or network latency.

The internal model will be that of POSIX threads - it should be easy enough to emulate the required functionality using Win32 thread primitives.

But this brings on to the portability issues, e.g. the C compilers. How do you convert a single threaded app to a multi-threaded app without throwing all the code base away?

Its a very tricky issue and has plagued software development for decades. One issue is thread local storage. Having a single variable used in the code which has a different value, depending on which thread is executing. This is kind of weird as it compartmentalises the value, but for most code, this can be the correct thing to do. (Other alternatives are passing pointers around throughout function calls which can be heavyweight).

GNU C provides __thread to declare a thread local variable, e.g.

__thread int x;

Microsoft C/C++ uses declspec(thread):

declspec(thread) int x;

Fortunately, this can be hidden by a #define operation.

But in any case, threading is a an issue - it makes an application an order of magnitude more complex (consider race conditions, debugging, etc).

Found a small issue with the VS .NET addin today.

But what is Visual Studio actually called? 2001? 2002? 2003? 2005? Theres numerous versions around which makes it difficult to ensure we support all versions properly. The differences appear to be subtle registry entries...

Oh how I hate the registry! Its almost such a good idea, but navigating it is tedious and difficult - it looks like a file system, but once you hit the classes (HKCR), its very difficult to navigate around. Microsoft should have split the top level trees into more categories (e.g. by prefixes or by subject).

In addition, the registry should be part of the filesystem - not a special file. This is what makes it so difficult to backup a machine or its applications, because the registry is so detached from the folder structure.

CYGWIN (a brilliant and free product) does the correct thing - provides a filesystem view of the registry, which means things like "tar" and "cd" can be used to navigate around it, back it up, etc.

Microsoft will never learn - they insist on fresh installs of all your apps instead of making OS migration and upgrading easier.

Happy Xmas all!

New release of CRiSP contains a possibly useful feature to allow you to set the margin for line numbers. (Saw this one in the comp.editors newgroup).

Someone asked for the ability to map differently from , so thats there now.

Now multiple-threading....

I've just completed adding Visual Studio .NET integration into CRiSP. Its taken an age to get it working. I already had integration for Visual C++ 5 and 6, but with the .NET series, everything had changed and tracking down the info was a pain.

Microsofts use of C++ represents everything I dislike about C++ - unreadable code, and code which is so very sensitive to being exactly right.

What they have done is admirable - providing a class structure to allow addins to do complex things, but its a difficult slog, trying to find examples of each class. Especially when the same thing is available in Visual Basic, C#, and C/C++. Many examples are difficult to translate between languages until you learn the idioms.

I gave up using the Microsoft installer for the addin - it totally doesn't handle the differences between VS 2002 and 2003, and in turn would have added more than a megabyte to the size of the distribution. As it is, the teeny amount of code adds up to about 150K.

Instead, I am relying on CRiSP to install the registry entries - then I have something reusable and can more easily support the issues in the field.

Happy Xmas!