Yes, it is very common in both assembly language and 'C' (and even C++, for that matter) to use IFDEFs to conditionally compile certain sections of code depending on the settings at compile-time. There's nothing sloppy about it. It's sloppier to NOT use IDEFs since doing so will include code that you're never going to use. This is especially true with an 8052 where your code memory is at a premium.

If your program is 190 pages long, it might be a good idea to break it up into smaller source files that are task-specific. As you mentioned, perhaps a source file for your interrupt-related code, perhaps a source file for your "main entry point," and whatever else can be logically broken up. On the other hand, there's something to be said for a single source file that is completely self-contained (as long as it is well documented!).

Also, if your interrupt routines are 25 pages long you'll probably want to review and perhaps improve them. Interrupt routines should generally be very short, get the interrupt task done quickly--any significant processing of the information collected in an interrupt routine should be done later by the main program outside of the interrupt itself. To do heavy or time-consuming processing within an interrupt routine is generally considered bad form and, in many cases, can even cause a process to fail because your interrupt routine may still be working on the previous interrupt when the next interrupt comes along. Bad thing.

The limit to "object oriented programming" in assembly language is really just writing code that has a single entry-point and re-using that code, and breaking up the source code into various modules. Beyond that, OOP is a higher-level language concept. Not everything that applies to C++ applies to assembly language, and those teachers that taught you that everything should be based on objects probably have never worked in assembly language.

Finally, if you're going to be modifying an existing operating system, be very careful. Keep good backups. It sounds like this is your first major project in assembly language and the operating system you are working with may be very "delicate," so be sure to thoroughly test any changes you make and keep backups every step of the way so you don't break it and find you have no way to get back...

Craig Steiner