Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:Call me crazy (Score 1) 115

by Nyall (#48779669) Attached to: Closure On the Linux Lockup Bug

Sorry for the bad post. Yes, the first link does not work, but it is what is documented in hpet.c as the reference. A sentence went missing somewhere saying that I couldn't find it. The second link, which does work, is what I've found so far. I have yet to find something newer which documents the latching behavior that was claimed.

Sorry again for the bad post.
-Nyall

Comment: Re:Call me crazy (Score 1) 115

by Nyall (#48779627) Attached to: Closure On the Linux Lockup Bug

OK then. Where in this return statement are the lower 32 bits read first? I don't believe the bitwise or operator is a sequence point. (The logical one is)

return readl(addr) | (((unsigned long long)readl(addr + 4)) http://www.intel.com/hardwared...

but I did find the following, which documents the race condition I explained above.

http://www.intel.com/content/d...

I will search for newer documentation than a 1.0a.

Comment: Call me crazy (Score 4, Interesting) 115

by Nyall (#48779371) Attached to: Closure On the Linux Lockup Bug

Sorry if I've found the wrong stuff. I'm doing this via a quick googling...

Is this really the code for reading and writing the HPET?

http://www.cs.fsu.edu/~baker/d...

I've been a powerpc programmer in aviation for a while. If you need to read the time base register (also a 64 bit up counter) you have to be aware that your read might coincide with the lower 32 bits incrementing and carrying into the upper 32 bits. So you read the upper 32 bits, read the lower 32 bits, then re-read the upper bits and make sure the upper bits didn't change. If they did repeat this process. But if they are the same then you combine the 32 bit halves into a 64 bit time and call it good.

Comment: Re:It's a question that WAS relevant (Score 3, Interesting) 161

by Nyall (#47774071) Attached to: Research Shows RISC vs. CISC Doesn't Matter

I think a large part of the confusion is that CISC often means accumulator architectures (x86, z80, etc) vs RISC which means general purpose register (ppc, sparc, arm, etc) In between you have variable width RISC like thumb2.

As an occasional assembly programmer (PowerPC currently) I far prefer these RISC instructions. With x86 (12+ years ago) I would spend far more instructions juggling values into the appropriate registers, then doing the math, then juggling the results out so that more math could be done. With RISC, especially with 32 GPRs, that juggling is near eliminated to the prologue/epilogue. I hear x86 kept taking on more instructions and that AMD64 made it a more GPR like environment.

-Samuel

Time to take stock. Go home with some office supplies.

Working...