About OBJ generation

[Neo]

Besides run-time or load time relocations there is another kind of relocations that are generated inside the OBJ. Unlike the run-time kind of relocations those kind of compile time relocations are mandatory if you generate OBJ's and link multiple modules.

Ah, I forgot about those, since I don't bother generating OBJ's, it just creates the executable directly.  The longest assembling time I've run into in my IDE is 4-6 seconds, and that's for a test case file that's over 300,000 lines long (and that was assembling with only one thread, since the file has only has one function), so I haven't yet put in any support for OBJ files.  It'll use as many threads as CPU cores for projects with more functions.

• You don't need the standard lib files at all if the assembler knows that it can call the functions through the import table, which is why you don't need any lib files to assemble Windows apps with Inventor IDE.

Ok, this is nice advertising for your Inventor IDE... I will check it out. Is it written in full ASM?

Sadly no; it's in Java and so it takes up a ton of RAM (like 50MB-400MB depending on the project and whether it includes the equivalent of Windows.inc).  Also, I'll warn that it has basically no macro support, though soon it'll support them as inline functions.  I'll be posting about it once version Alpha 5b is out, since it doesn't currently let you change the output type or change the external include files from within the IDE... a bit of an issue  :lol

A friend of mine is working on getting a C/C++ version, though it'll be a ton of work given the features in Inventor IDE.  Error detection and refactoring aren't particularly complicated, but there's a lot of code to get them working smoothly in so many different cases, especially to handle things in a language-independent way (since I'm aiming to have support for C in some Beta release).

However and assembler that can NOT produce OBJ's in order to be linked together by a linker has a huge miss feature. "Most" professional projects out there involve generating OBJ's and then linking them together to create the final executable.

I'll agree that most projects out there generate OBJ's and link them together separately, but there are a lot of bugs that crop up this way.  I didn't believe that compiler/linker toolchains were so stupid as to break on the following when I first heard this, but testing it out confirms it with the ones I tried it on:

• Change a constant in an include file that's included by 5 C/CPP files.
• Change one of the 5 C/CPP files, and build.
• Only one of the OBJ files was updated, and it gets linked together with the old OBJ files.
• Crazy errors ensue at runtime.

It's fairly simple to avoid this while still using OBJ files, but I haven't found a toolchain that handles it properly.  Basically, it just involves keeping track of references, and recompiling everything that could be dependent on changes.  I'll have that down the road in Inventor IDE (and much sooner in a semi-related capacity).

I prefer jump tables because the run time speed improvement is not worthy in this case, the size of the executable/dll is potentially smaller, the compilation speed is bigger, the load time is faster and OBJ size is smaller. If i want speed then I choose better algorithms, write my own functions to reduce API's overhead but I do not try to optimize every opcode/byte/cycle.

True, but the size difference is usually only a few bytes (or none if it doesn't go over a 512-byte boundary), the difference in compilation time and load time is likely less than 1ms except in extreme cases, so I tend to favour the miniscule runtime performance improvement... as much as it really doesn't matter to me either.  :wink

[Vortex]

Hi Neo,

I haven't yet put in any support for OBJ files.

Static libraries are built from object modules. What's your method to create code libraries? I guess you have your include files storing the source code of all the frequently used subroutines needed to build your projects.

[BogdanOntanu]

I didn't believe that compiler/linker toolchains were so stupid as to break on the following when I first heard this, but testing it out confirms it with the ones I tried it on:

    * Change a constant in an include file that's included by 5 C/CPP files.
    * Change one of the 5 C/CPP files, and build.
    * Only one of the OBJ files was updated, and it gets linked together with the old OBJ files.
    * Crazy errors ensue at runtime.

It's fairly simple to avoid this while still using OBJ files, but I haven't found a toolchain that handles it properly.
...

You have not checked correctly.

The most ancient type of IDE: the makefiles do handle this properly if you use dependency.
Every C/C++ IDE out there that I ever used does handle this kind of issue properly (including Visual studio 6 from 1997).

IF you change 1 include file that is used by 5 other source modules THEN all modules that depend on that changed file are automatically compiled again.

Trust me... I do this every day as a professional programmer.

[PBrennick]

It's fairly simple to avoid this while still using OBJ files, but I haven't found a toolchain that handles it properly.

I remember the issue and got into the habit of purging the OBJ files. In a C program there can be tons of OBJ files but we are talking assembly source files so it is not really an issue. Just purge.

Paul

[Neo]

Hi Neo,

I haven't yet put in any support for OBJ files.

Static libraries are built from object modules. What's your method to create code libraries? I guess you have your include files storing the source code of all the frequently used subroutines needed to build your projects.

What prevents you from creating libs straight from the source if you have all of the code?  I don't currently support creating any lib file formats as output files from the source, but I think that it'd be about the same as creating executables from the source.  If I include a megabyte of code (which I probably wouldn't), it only increases the build time a tiny amount.  That said, I'll eventually need to support obj files as input and/or output files; it's just not critical initially.  I'd also want to support lib files as input and/or output files, but then that's roughly equivalent to supporting obj files anyway (since you can use obj files as static libs).

You'll find that I'm rather quick to throw away legacy that doesn't help, and that can tend to annoy people, so hopefully I don't come off as a jerk for stirring things up.  :wink

[Neo]

The most ancient type of IDE: the makefiles do handle this properly if you use dependency.

Okay, I'm willing to take your word for it, but I can't recall ever seeing any makefiles using dependencies on include files, so I wasn't aware that it was an option with any makefile systems.  I do know that the build system for the Operating System Group at RIM (a hideous monstrosity of makefiles and scripts) does not handle this properly.  Plus it can take over an hour to build the bloated code at RIM once, so I was very angry when I discovered that the problem was that it only recompiled one of several files using a modified include file.  :'(

Every C/C++ IDE out there that I ever used does handle this kind of issue properly (including Visual studio 6 from 1997).

I've just tested with VisualC++ 2005 and you're right on that count, so thanks for calling me on it  :U  though I'm still sure that I've run across a case where doing a regular build produced something incorrect and doing a full rebuild produced something correct.

However, gcc does have issues like this one that are almost unbelievably stupid, like if you give it the wrong signature for a function in another file that's already been compiled, it won't even give a warning or linker error, so at runtime, you get a stack imbalance.  It took hours to debug a friend's program because of one mistake in a function declaration.  One guy tried to tell me that such behaviour was required by the C standard, and therefore VisualC++ was bad for not following the standard... by telling you when you've made a mistake.  ::)

Trust me... I do this every day as a professional programmer.

Not a criticism, but just as a recommendation, I would try to avoid using that type of line too much, partly because the "this" is ambiguous, but mostly it's an argument technique that tends to be used by people making claims about something about which they aren't really qualified to make a judgement, but they want to make it sound like they are.  A YouTube commenter re the D-Wave quantum computing demo:

Total bullshit. I'm a EE masters student and we study quantum physics. ... If you think that this company has technology decades ahead of what the most famous quantum researchers have from universities and labs all over the world, then you are extremely gullible. ... There's so many other reasons why this is fake but I'm not going to go into it.

I wasn't going to include an example, but then I figured that'd be awfully hypocritical of me.   :lol

[BogdanOntanu]

...
However, gcc does have issues like this one that are almost unbelievably stupid, like if you give it the wrong signature for a function in another file that's already been compiled, it won't even give a warning or linker error, so at runtime, you get a stack imbalance.  It took hours to debug a friend's program because of one mistake in a function declaration.  One guy tried to tell me that such behaviour was required by the C standard, and therefore VisualC++ was bad for not following the standard... by telling you when you've made a mistake.  ::)

GCC is a C/C++ compiler NOT an IDE and not a linker (well... almost a linker).

IMHO depending on your exact scenario the linker should have generated a warning.

However C is  a system programing language or a language that is relatively low level and in this regard very close to ASM.
Hence YES you can shoot your self in the foot with C or ASM with no problems and many times with NO warnings before pushing the trigger.

This kind of behavior is required because sometimes you DO WANT to perform some very "questionable" actions in system or low level programming and the compiler is NOT supposed or should NOT know better than you.

If you want "baby sitting" and a compiler that "will hold your hand" and "cry on your shoulder" then I suggest using Java, C# or similar very HLL programming languages. C/C++ as well as ASM is not for "everybody" .

Of course that Visual Studio and Microsoft compilers usually do walk one "extra mile" and try to help programmers for an extra buck even if this does break the "standards" sometimes... and yes I do prefer Visual Studio IDE to GCC+whatever Unix/Linux IDE ... but most of the times this is not my choice to make .... hence I do know both worlds.

Trust me... I do this every day as a professional programmer.

Not a criticism, but just as a recommendation, I would try to avoid using that type of line too much, partly because the "this" is ambiguous, but mostly it's an argument technique that tends to be used by people making claims about something about which they aren't really qualified to make a judgement, but they want to make it sound like they are.  ...

Could be ... but  :green 

In this case the word "this" means exactly: I am changing an #define or a function signature in an C include that is used by multiple C source modules and then building a big C project in Visual Studio IDE many times per day ... and it always works correctly.

In my case this is simply the truth. I am not "proud" to be a professional. It simply means that I do earn my money for a living from programming and I do this for a lot of years now (most of my life) and that I do work with C/C++ compilers and IDE's every day and hence I am used with them. 

Also I am under my real name here... hence my credentials and work experience can be checked.

I was just giving a friendly advice that would save you a lot of trouble because I noticed wrong understandings, dreams and assumptions ;)

I will not care what you or others think of me. I only care if what I write is correct, anything else is irrelevant.