Have you seen the reprint of K&R 2? It's the same number of pages as the copy I bought several years ago, but they used such a thick stock that the book is actually thicker than O'Reilly's "C++: The Core Language". It's nearly 3x as thick as my original copy. Absurd.
(Ok, so maybe the pages aren't 3mm thick, but still...)
Something tells me the author did the calculation for 3nm, not 30nm...
Sure would be nice if the fact checking at space.com were just a tad better than/.:)
Get YOUR facts straight, bub. The 83 million mile figure applies to Pioneer 6 which is orbiting the sun and is 35 years old, not Pioneer 10 which is 28 years old and has left the Solar System.
--Joe (getting a little peeved that the side reference to Pioneer 10 in the article has thrown everyone off.) -- Program Intellivision!
Lots of the early probes failed, IIRC, it's just that nobody remembers the early failures.
Yeah. It's too bad MTV doesn't air the rocket-crashing-on-the-launchpad "M" commercial
anymore. (You know, one of the classics from the 80s.) Now I got that damn theme going though my head: Dum, Da Dum, Da dum, Da da da daDUM, Da Dum, Da dadada, Da dadadaDUM, Da Dum, Da dadada, Da dadada...
Ok, so my posts tonight aren't exactly value-added. It's Saturday, ok?
Whatever.
Whenever I close workman, the tasklist_applet
just "goes away". I ended up adding a button down there to restart it, otherwise I can't bring my windows back once I've minimized them.
Actually, my computer won't detect > 8.4GB, and
there's no BIOS upgrade for it either. (It's a Gateway OEM version of a prereleased Intel board. The final release Intel mobo has BIOS upgrades available, but the Gateway version does not.)
Anyway, I refused to install any of that EZ-BIOS / MaxBlast / Whatever crap on my system to avoid the exact problems you're having booting multiple OSes.
The funny thing is, I can't so much boot a DOS / Windows floppy let alone boot Windows if my 17GB Maxtor is enabled in the BIOS. It hangs right
after "Starting MS-DOS..." or "Starting Windows..." when it goes to query the BIOS for
drive info. Whoo hoo! Even funnier is the fact
that LILO has no issues with the drive, and I just
tell Linux what the correct geometry is and life is good for Linux.
So, what I do is this: In those rare (about twice a year) cases that I boot Windows, I just disable the IDE controller in the BIOS and boot from my SCSI drives. (Yes, I have both in my system -- SCSI for all the important stuff, IDE for my CD-ROM master images and other non-critical bulk storage.) To boot Linux, I re-enable the IDE and
LILO takes over from there. Tada!
Anyway, I feel your pain. If you want to dual-boot Linux / Windows on your EZ-BIOS machine, I'm sorry, but you can't. (At least, no way that I know of.)
And why doesn't Linux work on your spacious machine? I started out with a 486 DX/33 with 8MB RAM, and I even ran X.
(Well, ran probably isn't the right verb, but you get the idea.)
The hugely annoying thing here in DFW is not knowing whether a number is supposed to be long distance or not. I've got a bunch of friends who live in Arlington, and I live in Plano, and it's a
pain to remember who I need to dial 1 to call, and who I don't. Never mind the fact that when I call "long distance" (40 miles to Arlington), I get charged more than when I place phone calls to
Boston or Sacramento.
I feel your pain. I live in North Richland Hills and work in Dallas. I pay SWB an extra $17 a month for "Extended Local Calling" because NRH seems to be a vacuum as far as reasonable phone service goes. My ZIP code shows up as a Fort Worth ZIP code because I'm so close to Fort Worth, yet even Fort Worth is long distance w/out the extended calling area. Bleh.
Thankfully, they're all local calls on my cell-phone. I'm thinking of calling SWB and taking my land-line down to "lifeline" status -- eg. a dialtone and 911 access, not much more.
Right now, I pay $80/mo for that phone, and don't
use it nearly as much as I use my cell phone.
(Yes, $80/mo for ONE LINE, with extended local calling area, call waiting, and touch-tone service. Yes, touch-tone is still "optional".)
It might have to do with how the LATAs are structured in your area.
If the call is within the same LATA (Local Access and Transport Area), then you shouldn't need an area code. If it's inter-LATA, you may need an area code, even if the area code number is the same. LATAs are structured differently than area codes, and so make things even more confusing. Wheee....
Right, but there aren't any 724 exchanges in there, I'd imagine. Unless you have 10-digit dialing, you can't have an exchange and an area code be the same, unless you want to rely on a flaky system of timeouts to disambiguate.
Typically, if your call is within your area code, you don't need to dial the area code, just 1 followed by the last 7 digits. If the number isn't long-distance, you only dial the last 7 digits. This is referred to as "7 digit dialing." In the larger metroplexes, where the metroplex itself is covered by multiple area codes, this just starts getting silly, because a number can be local, but not in your area code. Many of these metroplexes have converted to 10-digit-dialing, which means for all local calls, you must dial all 10 digits, and for long-distance calls, 1 plus the remaining 10 digits.
To give you an idea of the current state of the universe, in the D/FW area we have 972, 214, and 817. Chicagoland has several, none of which I can remember. Detroit has 810 and 313 (and maybe more since last I looked). It's getting freakin' ridiculous. And I've done nothing to make it better -- my fiancee and I both have mobile phones.
One of the nice things about 10-digit dialing is that it now opens up new exchanges and new area codes. It used to be that area codes always had a 0 or 1 as a middle digit, and that exchanges never did. This allowed the switch to be able to tell an area code from an exchange. In areas w/ 10-digit dialing, they can bring in new area codes which violate this rule (eg. 972 in the Dallas area). Once 10-digit dialing is establised, they can start brining in exchanges which violate this rule as well (for instace, my fiancee's cell phone is in the "817-800-xxxx" exchange.)
We have 10-digit dialing here in the D/FW metroplex, and it works fine as far as I'm concerned. I've often wondered when they'd go ahead and just switch the whole nation.
It's rather annoying to have to remember as you're traveling whether a given area is 10-digit or 7-digit. I haven't heard anyone complain about 10-digit dialing being annoying as comparied to 7-digit.
So who was making the fuss? Any legitimate reason other than "I don't like it"?
Yes, but the standard didn't need extending at all.
Strictly, no. Pragmatically, yes. There is (unfortunately) too much code which uses long where int would suffice (at least on modern machines).
long could just have been made 64-bit (or 128 or 256 or whatever).
Agreed. Indeed, that's what TI's compiler does for the C6000-family DSPs. The long type is 40-bits wide, since the DSP supports a 40-bit type in hardware (for high-precision filters). Unfortunately, it breaks code which assumes long is exactly 32 bits, and it causes code which only needed 32-bits (but which otherwise doesn't break) to run much less efficient. It's very annoying when a customer compiles their code and says "the output is big and slow, your compiler sucks", when really the problem is that their variables are declared as longs rather than ints.
That said, you could
argue the case for needing a new type to hold integers larger than the machine's word length
Personally, I'd be happy if there was a portable way to get at something like a carry bit, so that arbitrary precision arithmetic isn't so painful. Right now, if I want to do arithmetic at a size larger than the largest available integer type, I either have to jump through hoops to figure out what the carry was supposed to be and do math at the maximum machine word size, or do math at some smaller size and use upper bits to represent the carry. Annoying, annoying, annoying.
and retain a traditional unsigned long as the word length (so that you can cast to and from pointers).
Ick! Ick! Ick! Actually, on the platforms I'm interested in, sizeof(int) == sizeof(void *) , but not necessarily sizeof(long) == sizeof(void *). Assuming you can typecast a pointer to an integer type and back is asking for trouble.
(Although historically (and for old K & R C compatibility), typecasting between a pointer and an int is usually possible and fairly reliable across 32-bit environments.)
Cool! I had missed that in C99. I knew about some of the other features (some of the initializer stuff, restrict pointers, the new complex type, etc.) but I had missed that one.
For cases where you have lots of little things packed together, you have bitfield structure members. (Not that those have nice packing guarantees, but they are implementation-defined and thankfully the implementations I've worked with are sane.)
Ideally, your code shouldn't rely on data types being exactly some width, but rather rely on them being at least some width. After all, signed integer overflow is actually undefined by ANSI, though every platform I've run into says it behaves as you'd expect 2s complement arithmetic to behave.
Of course, none of that stops people (including myself) from writing code that relies on the specific width of the data types.
What we really need are the "unspecified width integral types" such as we have today in int and friends, and a new set of types (or type aliases) for "exact width integral types". The latter might not get complete support from a conforming compiler, but at the same time, could make life for a bitfidler like me much nicer.
... didn't get the joke.
The mother language of B and (later) C was BCPL.
So it stands to reason that the next two languages should be P, and then L.
Of course, some in the perl community have claimed they're the PL...
ObPun: Back before C was called C, it was called New B. I guess even Ritchie and Thompson aren't immune from l33t sp33k.
i.e. The "long long" hack in C99 is just plain stupid. How is C/C++ going to be patched *cough hacked cough* to support 128-bit integers? "long long long"?
You could make long long 256-bit, long 128-bit, int 64-bit, and short 32-bit if you really, really needed to. The standard certainly permits that.
What really grinds me is that so many people assume sizeof(long) == 4 or worse sizeof(long) == sizeof(int) == 4. On the C6000-family DSPs, long is actually 40-bits long whereas int is 32-bits. You'd be surprised how many people this trips up.
Huh? Token Ring vs. Ethernet only makes a difference for your local segment of LAN, and represents only the lowest layer of the protocol stack, the PHY (Physical) layer. You still get
TCP and IP layered over that if you wish.
You're only going to run Token Ring to a router
or thereabouts.
Sheesh. Kids these days. They type "winipcfg" and they think they know networking.
Register windows and rotating registers are
two different things entirely. The former is used for context switching between functions. The latter is for hardware-assisted, software-controlled register renaming in software pipelined loops.
Register windows slide up and down, providing a (theoretically infinite) stack in the register file. Each positioning of the window provides a "context", which represents the set of registers provided to a function at the function-call boundary. The chip implements a fixed number of contexts, and if you exceed the sliding window in one direction or the other, you take a fault and the fault handler slides the context for you. Presumably, you stay within the chip's implemented contexts most of the time and avoid faults. Such a technique saves you from having to push/pop as many registers around function calls.
Rotating registers work in a modulo fashion, with N registers (configured by the user on IA-64, as I recall) rotate every time a special branch is taken. (On IA-64, they have a "software pipeline branch" which triggers register rotation.) That's a completely different purpose.
A separate facility that IA-64 provides is a set of rotating predicates that can be used to provide "stage predicates." This gives you a mechanism for generating prologs and epilogs from a software pipeline kernel. This is the "avoiding bloat" bit you referred to. While this is still part of the rotating registers, it deserves special mention because it's a distinct use from the other uses of rotating registers that I've discussed elsewhere on this article.
And as for bitwise rotation, the IA-64 does provide that with the shrp instruction.
You just provide the same argument to both halves of the pair.
Uhm, the code you posted looks just like what I posted, unless my tired eyes missed something.
Anyway, the point is that yes, the adds must occur in order, but the adds from one iteration can now occur in parallel with a future iteration.
Let me illustrate "graphically" what a single-cycle version of this loop might look like on an infinite resource machine. I'll use || to show instructions in parallel. I'll put the
first full iteration in bold -- the subsequent iterations which are placed in parallel will be left unbolded.
b = *a++
b1 = b || c = b + t || b = *a++
b2 = b1 || d = c + u || b1 = b || c = b + t || b = *a++
b3 = b2 || e = d + v || b2 = b1 || d = c + u || b1 = b || c = b + t || b = *a++
loop: *g++ = e + b3 || b3 = b2 || e = d + v || b2 = b1 || d = c + u || b1 = b || c = b + t || b = *a++ || if (i++ < N) goto loop
The last cycle of that mess is the actual loop "kernel", which is the part that will do most of the iterating. The kernel in this loop produces one new output every cycle -- the initiation interval is 1. This loop wouldn't've been possible in a single cycle if we didn't move b to b1 to b2 to b3 unless we had rotating registers (which would've done the same, implicitly).
Note that there is a considerable "pipe-up" to the loop kernel. They don't call this software-pipelining for nothing!
Slashdot Mirror
Have you seen the reprint of K&R 2? It's the same number of pages as the copy I bought several years ago, but they used such a thick stock that the book is actually thicker than O'Reilly's "C++: The Core Language". It's nearly 3x as thick as my original copy. Absurd.
(Ok, so maybe the pages aren't 3mm thick, but still...)
Something tells me the author did the calculation for 3nm, not 30nm...
--Joe--
Program Intellivision!
Did you mean "One point twenty one gigawatts!!!!"
Now get back to work on that flux capacitor.
--Joe--
Program Intellivision!
Get YOUR facts straight, bub. The 83 million mile figure applies to Pioneer 6 which is orbiting the sun and is 35 years old, not Pioneer 10 which is 28 years old and has left the Solar System .
--Joe (getting a little peeved that the side reference to Pioneer 10 in the article has thrown everyone off.)--
Program Intellivision!
Yeah. It's too bad MTV doesn't air the rocket-crashing-on-the-launchpad "M" commercial anymore. (You know, one of the classics from the 80s.) Now I got that damn theme going though my head: Dum, Da Dum, Da dum, Da da da daDUM, Da Dum, Da dadada, Da dadadaDUM, Da Dum, Da dadada, Da dadada...
Ok, so my posts tonight aren't exactly value-added. It's Saturday, ok?
--Joe--
Program Intellivision!
Hell, just the three-way TCP handshake would tie it up for quite awhile... (think RTT).
--Joe--
Program Intellivision!
My English teacher once told me that I was using double negatives. I said to her, "No I'm not!"
--
Program Intellivision!
Whatever. Whenever I close workman, the tasklist_applet just "goes away". I ended up adding a button down there to restart it, otherwise I can't bring my windows back once I've minimized them.
--Joe--
Program Intellivision!
Actually, my computer won't detect > 8.4GB, and there's no BIOS upgrade for it either. (It's a Gateway OEM version of a prereleased Intel board. The final release Intel mobo has BIOS upgrades available, but the Gateway version does not.) Anyway, I refused to install any of that EZ-BIOS / MaxBlast / Whatever crap on my system to avoid the exact problems you're having booting multiple OSes.
The funny thing is, I can't so much boot a DOS / Windows floppy let alone boot Windows if my 17GB Maxtor is enabled in the BIOS. It hangs right after "Starting MS-DOS..." or "Starting Windows..." when it goes to query the BIOS for drive info. Whoo hoo! Even funnier is the fact that LILO has no issues with the drive, and I just tell Linux what the correct geometry is and life is good for Linux.
So, what I do is this: In those rare (about twice a year) cases that I boot Windows, I just disable the IDE controller in the BIOS and boot from my SCSI drives. (Yes, I have both in my system -- SCSI for all the important stuff, IDE for my CD-ROM master images and other non-critical bulk storage.) To boot Linux, I re-enable the IDE and LILO takes over from there. Tada!
Anyway, I feel your pain. If you want to dual-boot Linux / Windows on your EZ-BIOS machine, I'm sorry, but you can't. (At least, no way that I know of.)
--Joe--
Program Intellivision!
And why doesn't Linux work on your spacious machine? I started out with a 486 DX/33 with 8MB RAM, and I even ran X. (Well, ran probably isn't the right verb, but you get the idea.)
--Joe--
Program Intellivision!
I feel your pain. I live in North Richland Hills and work in Dallas. I pay SWB an extra $17 a month for "Extended Local Calling" because NRH seems to be a vacuum as far as reasonable phone service goes. My ZIP code shows up as a Fort Worth ZIP code because I'm so close to Fort Worth, yet even Fort Worth is long distance w/out the extended calling area. Bleh.
Thankfully, they're all local calls on my cell-phone. I'm thinking of calling SWB and taking my land-line down to "lifeline" status -- eg. a dialtone and 911 access, not much more. Right now, I pay $80/mo for that phone, and don't use it nearly as much as I use my cell phone. (Yes, $80/mo for ONE LINE, with extended local calling area, call waiting, and touch-tone service. Yes, touch-tone is still "optional".)
--Joe--
Program Intellivision!
It might have to do with how the LATAs are structured in your area. If the call is within the same LATA (Local Access and Transport Area), then you shouldn't need an area code. If it's inter-LATA, you may need an area code, even if the area code number is the same. LATAs are structured differently than area codes, and so make things even more confusing. Wheee....
--Joe--
Program Intellivision!
Right, but there aren't any 724 exchanges in there, I'd imagine. Unless you have 10-digit dialing, you can't have an exchange and an area code be the same, unless you want to rely on a flaky system of timeouts to disambiguate.
--Joe--
Program Intellivision!
Typically, if your call is within your area code, you don't need to dial the area code, just 1 followed by the last 7 digits. If the number isn't long-distance, you only dial the last 7 digits. This is referred to as "7 digit dialing." In the larger metroplexes, where the metroplex itself is covered by multiple area codes, this just starts getting silly, because a number can be local, but not in your area code. Many of these metroplexes have converted to 10-digit-dialing, which means for all local calls, you must dial all 10 digits, and for long-distance calls, 1 plus the remaining 10 digits.
To give you an idea of the current state of the universe, in the D/FW area we have 972, 214, and 817. Chicagoland has several, none of which I can remember. Detroit has 810 and 313 (and maybe more since last I looked). It's getting freakin' ridiculous. And I've done nothing to make it better -- my fiancee and I both have mobile phones.
One of the nice things about 10-digit dialing is that it now opens up new exchanges and new area codes. It used to be that area codes always had a 0 or 1 as a middle digit, and that exchanges never did. This allowed the switch to be able to tell an area code from an exchange. In areas w/ 10-digit dialing, they can bring in new area codes which violate this rule (eg. 972 in the Dallas area). Once 10-digit dialing is establised, they can start brining in exchanges which violate this rule as well (for instace, my fiancee's cell phone is in the "817-800-xxxx" exchange.)
--Joe--
Program Intellivision!
We have 10-digit dialing here in the D/FW metroplex, and it works fine as far as I'm concerned. I've often wondered when they'd go ahead and just switch the whole nation. It's rather annoying to have to remember as you're traveling whether a given area is 10-digit or 7-digit. I haven't heard anyone complain about 10-digit dialing being annoying as comparied to 7-digit.
So who was making the fuss? Any legitimate reason other than "I don't like it"?
--Joe--
Program Intellivision!
Strictly, no. Pragmatically, yes. There is (unfortunately) too much code which uses long where int would suffice (at least on modern machines).
Agreed. Indeed, that's what TI's compiler does for the C6000-family DSPs. The long type is 40-bits wide, since the DSP supports a 40-bit type in hardware (for high-precision filters). Unfortunately, it breaks code which assumes long is exactly 32 bits, and it causes code which only needed 32-bits (but which otherwise doesn't break) to run much less efficient. It's very annoying when a customer compiles their code and says "the output is big and slow, your compiler sucks", when really the problem is that their variables are declared as longs rather than ints.
Personally, I'd be happy if there was a portable way to get at something like a carry bit, so that arbitrary precision arithmetic isn't so painful. Right now, if I want to do arithmetic at a size larger than the largest available integer type, I either have to jump through hoops to figure out what the carry was supposed to be and do math at the maximum machine word size, or do math at some smaller size and use upper bits to represent the carry. Annoying, annoying, annoying.
Ick! Ick! Ick! Actually, on the platforms I'm interested in, sizeof(int) == sizeof(void *) , but not necessarily sizeof(long) == sizeof(void *). Assuming you can typecast a pointer to an integer type and back is asking for trouble. (Although historically (and for old K & R C compatibility), typecasting between a pointer and an int is usually possible and fairly reliable across 32-bit environments.)
--Joe--
Program Intellivision!
Cool! I had missed that in C99. I knew about some of the other features (some of the initializer stuff, restrict pointers, the new complex type, etc.) but I had missed that one.
Thanks for the pointer!
--Joe--
Program Intellivision!
For cases where you have lots of little things packed together, you have bitfield structure members. (Not that those have nice packing guarantees, but they are implementation-defined and thankfully the implementations I've worked with are sane.)
Ideally, your code shouldn't rely on data types being exactly some width, but rather rely on them being at least some width. After all, signed integer overflow is actually undefined by ANSI, though every platform I've run into says it behaves as you'd expect 2s complement arithmetic to behave. Of course, none of that stops people (including myself) from writing code that relies on the specific width of the data types.
What we really need are the "unspecified width integral types" such as we have today in int and friends, and a new set of types (or type aliases) for "exact width integral types". The latter might not get complete support from a conforming compiler, but at the same time, could make life for a bitfidler like me much nicer.
--Joe--
Program Intellivision!
... didn't get the joke. The mother language of B and (later) C was BCPL. So it stands to reason that the next two languages should be P, and then L. Of course, some in the perl community have claimed they're the PL...
ObPun: Back before C was called C, it was called New B. I guess even Ritchie and Thompson aren't immune from l33t sp33k.
--Joe--
Program Intellivision!
You could make long long 256-bit, long 128-bit, int 64-bit, and short 32-bit if you really, really needed to. The standard certainly permits that.
What really grinds me is that so many people assume sizeof(long) == 4 or worse sizeof(long) == sizeof(int) == 4. On the C6000-family DSPs, long is actually 40-bits long whereas int is 32-bits. You'd be surprised how many people this trips up.
--Joe --Joe--
Program Intellivision!
And don't forget, randomly switching from night to day to night. "You stupid, stupid people!"
--Joe--
Program Intellivision!
Hehehehe! :-) Thanks for the
chuckle. 'Course, I'm only 25.
--Joe--
Program Intellivision!
Huh? Token Ring vs. Ethernet only makes a difference for your local segment of LAN, and represents only the lowest layer of the protocol stack, the PHY (Physical) layer. You still get TCP and IP layered over that if you wish. You're only going to run Token Ring to a router or thereabouts.
Sheesh. Kids these days. They type "winipcfg" and they think they know networking.
--Joe--
Program Intellivision!
Hey, no problem! I guess it would've just been nice to at least mention software pipelining if you're going to mention rotating registers at all. :-)
In any case, no worries.
--Joe--
Program Intellivision!
Register windows and rotating registers are two different things entirely. The former is used for context switching between functions. The latter is for hardware-assisted, software-controlled register renaming in software pipelined loops.
Register windows slide up and down, providing a (theoretically infinite) stack in the register file. Each positioning of the window provides a "context", which represents the set of registers provided to a function at the function-call boundary. The chip implements a fixed number of contexts, and if you exceed the sliding window in one direction or the other, you take a fault and the fault handler slides the context for you. Presumably, you stay within the chip's implemented contexts most of the time and avoid faults. Such a technique saves you from having to push/pop as many registers around function calls.
Rotating registers work in a modulo fashion, with N registers (configured by the user on IA-64, as I recall) rotate every time a special branch is taken. (On IA-64, they have a "software pipeline branch" which triggers register rotation.) That's a completely different purpose.
A separate facility that IA-64 provides is a set of rotating predicates that can be used to provide "stage predicates." This gives you a mechanism for generating prologs and epilogs from a software pipeline kernel. This is the "avoiding bloat" bit you referred to. While this is still part of the rotating registers, it deserves special mention because it's a distinct use from the other uses of rotating registers that I've discussed elsewhere on this article.
And as for bitwise rotation, the IA-64 does provide that with the shrp instruction. You just provide the same argument to both halves of the pair.
--Joe--
Program Intellivision!
Uhm, the code you posted looks just like what I posted, unless my tired eyes missed something. Anyway, the point is that yes, the adds must occur in order, but the adds from one iteration can now occur in parallel with a future iteration.
Let me illustrate "graphically" what a single-cycle version of this loop might look like on an infinite resource machine. I'll use || to show instructions in parallel. I'll put the first full iteration in bold -- the subsequent iterations which are placed in parallel will be left unbolded.
- b = *a++
- b1 = b || c = b + t || b = *a++
- b2 = b1 || d = c + u || b1 = b || c = b + t || b = *a++
- b3 = b2 || e = d + v || b2 = b1 || d = c + u || b1 = b || c = b + t || b = *a++
- loop: *g++ = e + b3 || b3 = b2 || e = d + v || b2 = b1 || d = c + u || b1 = b || c = b + t || b = *a++ || if (i++ < N) goto loop
The last cycle of that mess is the actual loop "kernel", which is the part that will do most of the iterating. The kernel in this loop produces one new output every cycle -- the initiation interval is 1. This loop wouldn't've been possible in a single cycle if we didn't move b to b1 to b2 to b3 unless we had rotating registers (which would've done the same, implicitly).Note that there is a considerable "pipe-up" to the loop kernel. They don't call this software-pipelining for nothing!
--Joe--
Program Intellivision!