|
charlieg wrote: C000005s to death
Memory error.
Standard problem. The environment is different so the execution flow is different. It didn't show up before because you got lucky. Now it does. If you have a testing framework you can use a memory check library to debug.
Other than that you might also want to set it up for a delayed start. Or better if there are other dependent services make sure those are in the dependency list. The start up order is not deterministic unless explicit ordering is in place.
|
|
|
|
|
Yeah, I know what it means , and clearly you are correct that the environment has changed. As I said in another comment, its sister program works fine and is nigh identical to the one misbehaving.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Recently, I have been working with C++ includes and while examining those used in LLVM, I came across several H header files that caught my attention. I noticed that they were not templated and contained both declarations and definitions with code. To my surprise, I found that these header files were included in multiple CPP source files. Although they only define classes, I am concerned that this may result in code bloat since each source file must generate the binary for each class implementation. In my own work, I prefer to place the implementation of any non-templated class in its own CPP source file and let the linker handle it. I consider this to be essential. However, since the writers of LLVM are undoubtedly more knowledgeable, experienced, clever, and intelligent than I am, I wonder if there is something that I do not understand. Thank you.
|
|
|
|
|
Quote: I came across several H header files that caught my attention. I noticed that they were not templated and contained both declarations and definitions with code.
Do you mean member functions implemented inside the class definitions (they are inlined, so multiple inclusion is allowed)?
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
|
Richard MacCutchan wrote: There is plenty of information...
Am I misreading that? Seems like the project is focused on compilation?
Thus why would the OP ask the question in the first place?
An enterprise system will be vastly bigger than the compiler. That is going to be true for all but the very smallest of product companies. Service companies would probably always be bigger than that.
Even a system which is doing dynamic compilation as part of the business logic should still restrict that part to a very small subset of of the system, and probably a company library.
So am I just not understanding what LLVM is?
|
|
|
|
|
jschell wrote: why would the OP ask the question in the first place? The question makes specific reference to LLVM, so I assume that is what he is concerned about. I stand ready to be corrected.
|
|
|
|
|
Roughly speaking adding two 32 bit numbers requires 32 Boolean gates.
Why do you need millions of transistors? I know there is also substraction, division, multiplying, comparison etc. Some operations probably require way more Boolean gates than the number of bits the numbers involved in the operation are made of.
Also my guess is there is a comparison based mathematical operation type selector that directs the bits to the correct area on the processor pill. Still it’s difficult to imagine where millions of transistors go.
If I think about it more I get it, this is just Alu. There is also non mathematical stuff that needs to be taken care of as well.
|
|
|
|
|
Calin Negru wrote: If I think about it more I get it, this is just Alu. There is also non mathematical stuff that needs to be taken care of as well. Not to mention the floating point stuff, memory cache, multiple cores, and so on, and so on...
The distance between a modern day CPU and a schoolbook design is larger than the distance between a Ford T and a Formula 1 car.
Mircea
|
|
|
|
|
Indeed, and all the peripheral systems, ADC, Timers, UARTs, I2C, SPI, DMA, PWM, DAC, to name but a few.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
A large part of the silicon real estate is occupied by large/huge caches, in some chips 3 levels deep.
|
|
|
|
|
Well, a little more than 32 (unless you count a full adder as one gate? but I wouldn't). Especially if you use any type of fast adder which is often mandatory to hit frequency targets. Subtraction doesn't cost much extra, you can reuse your adder by turning it into an adder-subtractor. Comparisons don't cost extra, comparison is subtraction. Multipliers are bigger.
So it costs a few more gates than you estimated, but also there are far more transistors: billions, these days.
(Scalar) ALUs are not a big part of a modern high-performance CPU, even after accounting for there being a handful of them (I mean multiple per core, of course there are usually multiple cores too). Here's a fun article showing how big various parts of a CPU actually are, keep in mind it's showing a super obsolete Pentium 4: Intel’s Netburst: Failure is a Foundation for Success – Chips and Cheese
|
|
|
|
|
Thank you guys for sharing
> harold “fast adder”
That must be a recent improvement ( I have no clue, just a wild guess ) I’m just starting to understand what is probably the classical model.
> tronderen “real estate”
I like to think in somewhat similar terms
|
|
|
|
|
Not that recent. The 8008 used carry lookahead for example. And several 74181 (a 4-bit ALU chip which you can use multiple of in a group to build a wider ALU) could be combined with the 74182 (lookahead carry generator) to build an ALU with carry lookahead. These things are ancient (70's era tech).
That does not mean that carry lookahead addition was always used everywhere, some chips were really trying to save on transistors and didn't use it. But anything modern, probably has some sort of fast adder. Ripple carry adders do not scale well (imagine a 64-bit ripple carry adder, yikes) and transistors are significantly cheaper than a dime a dozen.
|
|
|
|
|
If you take a look at multicore procesors that’s probably a lot more things going on and not suited as an entry level lesson. If you want to learn anything you need to strip down all the fancy things.
|
|
|
|
|
PIEBALD pulls his copy of Code by Charles Petzold off the shelf behind him.
Chapter Twelve describes implementing A Binary Adding Machine from simple logic gates.
His descriptions of logic gates use relays rather than transistors.
I haven't counted, but it looks like a simple 32-bit adder built according to his diagrams might require a bit more than a hundred relays?
I can't comprehend a full modern ALU though.
|
|
|
|
|
My (14 years old) son designed and implemented a 4-bit adder. For all but the LSB he used three XOR and two AND gates.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
|
Hi All,
Question about the Switch Case, I always treated the default section of a switch case a 'I have no idea what to do'
for(i=0; i<= 100; i++)
{
myServo.write(i);
val = myServo.read();
switch(val)
{
case 0:
break;
case 50:
break;
case 100:
break;
default:
break;
}
What appears to be happening it goes to the default when not caught by a catch. In the example when i = 50,
I need a method for catching values out side of the the range 1 to 100. As if the servo returns value outside of the range 0 to 100. Could I do with an if... if(( i < 0) && (i >100)) would this take care of anything 0 - 100??? I will try that.
|
|
|
|
|
In your instance (if this is the actual code), all values that are not 0, 50, or 100 will end up at the default statement. There's also a missing closing bracket for the switch statement, probably a copy/paste thing.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
glennPattonWork3 wrote: Could I do with an if... if(( i < 0) && (i >100)) I'm afraid that test will never be true. No value of i can be less than zero AND greater than 100 at the same time.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
It could, if it was val not i as I typed. Solved
|
|
|
|
|
According to that code as written, any value that is not 0, 50 or 100, will go to the default statement. If that is not happening then there must be some other code that we can't see.
|
|
|
|
|
That was the thing. Typing it out made me see it.
|
|
|
|
|
... oops (wrong forum red-flag-accessed-by-moi)
For some reason I thought I was in the Lounge and have disappropriated some points that shouldn't be mine. Sorry!
Is "What do I do now" an appropriate C/C++/MFC question?
Thanks (answered myself),
|
|
|
|