First, check out http://en.wikipedia.org/wiki/Gamut for reference. The sample gamut picture in the top right shows a typical CRT--lets assume for the sake of argument that LCDs are similar.
If you add a yellow LED to that it just isn't going to add much. The yellow part of the spectrum is already fairly well represented.
*But* if they also change the hue of the green LED toward the blue spectrum then it has a good chance of really opening up the gamut.
The people saying RGB is enough don't understand chromaticity--go look for gamut plots of your favorite output devices and see how little of the full spectrum of colors they can actually reproduce. Printers are especially embarrassing. Your eyes can really see a whole lot of color detail.
It is exceedingly easy to test the Throttle Positioning Sensor in modern vehicles. In fact, your ECU probably tests idle throttle position every time you turn the key on for a while without staring the engine. The ECU will also log 'implausible signal' for TPS that get an out of range reading, or inconsistent reading throughout the range.
You are basically correct. I have first hand hacking experience with the drive by wire throttle because my Grand Challenge team automated a Toyota Prius for the last Grand Challenge. There are 2 completely independent signals that go from 2 independent sensors on the pedal to the computer throttle component. The signals have to move in lock step with each other or the computer will detect a fault. If a fault is detected the throttle goes completely off and the car has to be turned off and turned back on to recover.
So for the throttle to stick down both pedal sensors have to fail in the same way at the same time, which seems highly unlikely to me. Or there could be a bug in the computer control section, bus as a software engineer I can assure you that that would be impossible.;-)
I remember this coming up a number of years ago when they first put this clause in the ticket sale license. It was discussed to death back then and so it's kind of funny to me that it has suddenly come up again. The (possibly apocryphal) reason that my more in-the-know burner campmates told me way back when:
The year before a bunch of guys went around with a video camera and tried to release a "Girls of Burning Man" video in the style of "Girls Gone Wild". This was widely viewed as poor form. So the organizers put the clause in specifically to nip that kind of behavior in the bud. They didn't want people (women in particular) to have to worry about unwittingly becoming part of some cheesy softcore porn video.
When I tried to sign up for Verizon's wireless data service they wouldn't let me pass the credit check without a land line. I tried to tell them I didn't have a land line but they couldn't cope with that. Eventually the girl at the counter gave her sister's apartment number to the credit check guys (she didn't have a land line either). Got to love unbending bureaucracy.
I installed this update and rebooted and now it kernel panics every time I try to boot! It happens early enough that I can't even boot into single user. Grrr.....
Nice! I also loved those 2 games. I also get the feeling most people haven't played them. Both of those are good solid games worthy of replaying. Thanks for making remember those!
I loved the original Deus Ex and played all the way through it twice and played just the first few levels a number of times since then. I would definitely consider playing it all the way through again! It's a shame the second one wasn't as good as the first.
The sad thing is I have it for the Mac and it only runs in classic mode now. When the intel move becomes ubiquitous they aren't going to do classic and I'm going to lose Deus Ex (as well as all my nostalgic classic apps). Very sad.
I know what you mean about the power lines. In my car I can hear the disk spin up so clearly. I noticed that I only get that if the iPod is plugged in--when it's running on batteries the noise is gone/really quiet.
Those are all very good suggestions, even the idea that I just want to hear it. I've had all those ideas myself too, and tried a number of different things to eliminate them:
Eq: Turned off the eq. Distortion is still there. Made sure the file didn't have a specific eq setting in iTunes, even though I'm not sure that setting affects the iPod.
Too loud: The distortion happens at low volumes and high volumes.
Bad headphones: I have a nice set of over the ear headphones. The distortion is still there.
Compression artifact: I listened to the original file with headphones from itunes (everything flat): no distortion. Back and forth between iPod and Mac, distortion is clearly there on the iPod, not on the Mac.
My own mind: I've had other people listen to the particular song and they confirm they are hearing the distortion too.
A problem with my iPod: I've tried friends and family members iPods (up to 4th gen) and they all had the same problem.
The distortion I am hearing is clearly digital clipping. It doesn't sound like compression artifacts or analog clipping. I've used 2 or 3 different headphones, my own stereo system, my work speakers, and my card stereo and the distortion is there, but not on the original file on a computer. On my list of things to do is to encode some sample tones and look at them on an oscilloscope. Maybe take some pictures and put up a little page about my findings.
I believe what I am hearing is some hard coded digital amplification that happens somewhere early on along the iPod's audio path. This makes the iPod's sound quality fundamentally flawed, which is one huge reason I've never bought one (the one I have is a hand-me-down).
I know maybe you're joking, but it has nothing to do with volume. It's happening somehwere in the digital part, before the analog amplification stage. It's distorted even at the lowest volume settings. And it's clearly digital distortion--it has a distinct sound.
I should've mentioned that the first thing I tried was getting rid of the EQ. With everything flat I still get the distortion. I also made sure the track had no special eq settings in iTunes.
With the EQ on it's so much distortion I can't even believe it.
My first gen iPod (not very helpful to the original poster, I know) actively distorts sound! No environment, headphones, or ears are going to help that. It's like they have a hardcoded digitial amplification going on which just kills any music that recorded at at full volume. Which is to say, any rock album that came out in the last 5 or 10 years. Music older than that wasn't so heavily compressed (and I'm not talking about the mp3 sense), and so it doesn't distort. But Jeez, just try listening to anything with some good normalized bass and the iPod will digitally distort the crap out of it. It's really really horrible and it's not something you have to be an audiophile to hear. I would never recommend an iPod to anyone who is remotely concerned about sound quality.
Curiously, turning down the volume has no effect on the distortion. I also put a.wav on it to see if it was somehow related to the aac encoding, but it even a pure.wav distorted.
I even tested with my friends 4th gen iPod and it still has this problem. My mom just got a video, but I haven't tested that to see if it sucks too.
Interestingly, my iPod shuffle doesn't do this. It must have a completely different audio path.
But wouldn't it be possible to pipe the input of one 1394 port to the output of another and vice versa putting them through one of the Tee commands mentions up ^^ there?
It doesn't work that way. If packets are received by the ohci card but are addressed to other nodes on the bus then they get thrown away in hardware before the software gets a chance to get a hold of them.
The repeater function of firewire is also completely handled by hardware so when a packet comes in one port and gets put out to another port it's still completely isolated from software.
Besides, "tee" is in a completely different realm than firewire packets.
-David
Also, I'm talking about asynch bus packets here. Isoch packets (and asynch stream packets) have no destination address (just a channel number) and so any node can listen in on them.
Because of the way endpoints and bus controllers are determined, and how data flows you may have to be careful about the placement of the snooping computer on the bus.
Wrong. FireWire is a broadcast protocol and the Phys are like ethernet hubs not ethernet switches. So every device on the bus gets all data delivered to it.
The real trick is getting the chipset datasheet from the manufacturer.
99% of all 1394 cards follow the OHCI spec (hence no need to get data from the manufacturer). The OHCI spec does not allow snoop mode. Annoying, eh?
For some moronic reason (I've heard it was bowing to pressure from content providers to make the firewire bus hard to sniff for the commoner--take that with a grain of salt), the OHCI spec (which 99% of all cards adhere to) does not include a way to enter promiscuous mode. So if you buy a cheap card you will not be able to monitor the bus.
TI used to make a non-OHCI chip called the PCI Lynx that had a sniffing mode. Apple has a nice FireWire protocol analyzer called FireBug that works with the Lynx chip. I believe I may have seen Linux software at some point that does similar packet sniffing. But these PCI Lynx based cards can be hard to find. At my old job (where we did lots of Firewire stuff) we bought a big bulk purchase of Cardbus Lynx cards and converted a bunch of cheap old powerbooks into mobile firewire analyzers.
Yes, and the first hit for "premature optimization is the root of all evil" demonstrates my point exactly. To paraphrase, a good software developer will have developed a feel for where performance issues will cause problems.
Yes, I totally agree with you and the linked essay on this.
Making it easy to hand optimize can only help one to develop the feel.
I disagree here. Read the page you linked to again. The point is that you have to have a feel for the overall design of the program you are making and how that design will work in the end. It is not about how fast you can make memcpy() go (for example)--that can only get you so far. Take for example:
Because QB always maintained the length of a string, I knew that the fastest way to find an unsorted string was to [search linearly]. Interesting how that doesn't come up as a potential solution for you in your string performance scenario.
That is because in the context of C (which the discussion is about) the lengths of strings are not known (quickly). For large numbers of strings your algorithm is still orders of magnitude slower than keeping the strings sorted and doing a binary search. That was my real point, and Knuth's point. That optimizing your overall algorithm can yield vast improvements that hand optimizing little sections of code just cannot come close to. This is what the linked essay says that good programmers develop a feel for, not silly little tricks to speed up a single for loop. That's the kind of thing you do very last and only if you have an intensely speed critical application and you've already exhausted optimizing your algorithms--because you're only going to speed things up by small percentages.
C has a conflict of interest. If it has structures to allow you to write beautiful hand-optimization it loses its reason for existing, so guess what, it doesn't. Ugly hand-optimization is a fault of C, not of hand-optimization.
If the reason you are talking about is some semblance of portability then you are right. Have you ever read the C rationale? It explains the reasoning of the decisions the C committee made and helps you see things from their point of view. It was very enlightening for me when I first read it. It apparently used to be part of the C standard but they broke it off into a separate document at some point.
That's not true at all. There is nothing inherently wrong with hand-optimizing just because you feel like it.
Have you ever heard the saying, "premature optimization is the root of all evil?"
The problem is that when you profile a piece of code, quote often the slowest routine is something you never would have expected. Hand optimizing a routine that gets run 1% of the time is pointless. Quite often this sort of hand optimization makes code ugly, and why make your code ugly for no reason?
Another argument is that generally you don't ever have to do crazy platform specific optimizations to make your program run blazingly fast. For instance, if you determine that the slowest point of your program is the part that for loops through 1000 strings looking for a specific one, the smart thing to do isn't to go nuts hand optimizing the assembly of the loop or making the sure the strings are cache aligned or something. Switch your algorithm so the strings are kept sorted and then do a binary search. Or maybe make a hash table. Either way it's going to be an instant order of magnitude speedup--way way more than you could ever get by hand optimizing the original for loop.
You also say that size and speed are mutually exclusive. While that is generally the case on current x86 architectures, that doesn't always have to be the case. I don't know what causes the penalty for unaligned reads, but Intel could redo its architecture to grab 32 or 64 bits at a time from any base byte, but the current tools that blithly accept the current limitation and don't let coders explore how their code might be different if such a barrier was removed doesn't give Intel an incentive to do so, and that's one of my points.
I'm not sure I understand your assertion that the tools are holding you back. Take this structure:
struct {
char a;
short b;
long c; } d;
There is no implied packing in the C standard--C specifically strives to be platform neutral. Every compiler I've seen will put padding bytes in there to make the accesses fast (or doable at all--must ARM busses can't do unaligned transfers). But if Intel magically put together some hardware that made unaligned accesses just as fast as aligned accesses then the compiler would be able to remove the padding bytes on that architecture.
If you don't need the speed and need your structure smaller then you can tell the compiler to pack the structure (on gcc I think it's something like __attribute__((packed))). So there's nothing holding you back--they just make the default sane for most situations.
The point of C is to let the compiler do the stupid little architecture optimizations for you. So it seems to me like your main point is that you don't trust the compiler. Maybe you should try some of your ideas out in assembly and see if they are worthwhile. If you can show that a particular optimization is worthwhile write it up and send it to the gcc guys.
You can fit two 16 bit integers in the space of a 32-bit register or any other memory device.
Yes. Most compilers let you optimize for size, or speed--that is, they are mutually exclusive. What you are suggesting is hand optimizing for size. This isn't necessarily bad, but is pointless for structures that exist in 1 or 2 places (what, you're saving 2 bytes total?). In a huge multi-megabyte array it can make a dramatic size difference. But it can also slow the crap out of your code in certain situations, so you'd have to know your architecture well before making the judgement call. Most architectures (though possibly not x86) require double the instructions to load a non-machine word length number. You first have to load it in, then you have to sign extend or unsigned extend. These are almost always separate instructions.
That being said, most times you wont care about size or speed and so ints will do just fine. You shouldn't be hand optimizing at all unless you've determined that something is too large or too slow.
This is the compiler's job. If your compiler targets a particular processor poorly, get a better compiler.
Hear hear. You are 100% correct here.
There's no reason, apart from esoteric algorithm tweaking, to code something in a processor specific manner.
Agreed, but it sometimes takes some thought to even realize you are coding in a processor specific manner. For instance, if you've ever programmed for a Mac or written networking code on a PC you realize that all binary data formats were created with a certain endian in mind, and if your processor's endianness is different you have to swap some bytes. No, it's not hard to do, but if you're implementing, say, a FAT filesystem on a little endian machine you might not even notice. And then, boom, your lovely code turns out to be not very portable after all.
Portabillity is only useful for people who don't want to keep buying software and are fed up with it.
No, portability is more useful to those writing software that has to run in 2 (or more) environments. Say I want to write a game that runs on the xbox and the ps2. The more portable I make my code, the happier I will be in the long run (and the cheaper the price will be for the port to whichever platform comes second).
This depends more on the bus than the CPU architecture. I know some 32 bit busses have lines to say whether the transfer is 8, 16, or 32 bits. If you read a byte of data on the bus--lets call it 0x0d, then 0x0d0d0d0d is actually sent across the bus. Other busses will work like you said and transfer 32 bits of data from a rounded address and then let the CPU pick out the correct byte. Some will just transfer 0xXXXXXX0d where XX is something random.
folks: use ajax, it really is The Next Big Thing (tm). but let the real lesson be how technology can be neglected and then suddenly be thrust into the spotlight, simply because someone influential (google in this case) put their seal of approval on it
I wouldn't say google put their seal of approval on it--It's more like they put out an app (Google maps) that really showed off what you could do with the technology. I'm sure some of people have been using XMLHttpRequest since 1999 or whenever it came out, but *a lot* more people had never heard of it. Google maps opened a lot of eyes, including my own. I started looking into javascript for the first time after being wowed by Google maps and to my suprise I found it to be quite a nice little language. It even inspired me and a friend to write a bunch of our own javascript games.
r = result.status; if (r == Http.Status.OK)
data = eval(result.responseText);
Done. And it can be an arbitrarily complex data structure too, not just a flat array like your text example. It's quite lovely, really.
I'm with you though, XML is a horrible thing to pass back to a javascript. I've used all these techniques in some solitaire games me and a friend wrote and I found that the JSON method is just nice.
Slashdot Mirror
First, check out http://en.wikipedia.org/wiki/Gamut for reference. The sample gamut picture in the top right shows a typical CRT--lets assume for the sake of argument that LCDs are similar.
If you add a yellow LED to that it just isn't going to add much. The yellow part of the spectrum is already fairly well represented.
*But* if they also change the hue of the green LED toward the blue spectrum then it has a good chance of really opening up the gamut.
The people saying RGB is enough don't understand chromaticity--go look for gamut plots of your favorite output devices and see how little of the full spectrum of colors they can actually reproduce. Printers are especially embarrassing. Your eyes can really see a whole lot of color detail.
It is exceedingly easy to test the Throttle Positioning Sensor in modern vehicles. In fact, your ECU probably tests idle throttle position every time you turn the key on for a while without staring the engine. The ECU will also log 'implausible signal' for TPS that get an out of range reading, or inconsistent reading throughout the range.
You are basically correct. I have first hand hacking experience with the drive by wire throttle because my Grand Challenge team automated a Toyota Prius for the last Grand Challenge. There are 2 completely independent signals that go from 2 independent sensors on the pedal to the computer throttle component. The signals have to move in lock step with each other or the computer will detect a fault. If a fault is detected the throttle goes completely off and the car has to be turned off and turned back on to recover.
So for the throttle to stick down both pedal sensors have to fail in the same way at the same time, which seems highly unlikely to me. Or there could be a bug in the computer control section, bus as a software engineer I can assure you that that would be impossible. ;-)
I remember this coming up a number of years ago when they first put this clause in the ticket sale license. It was discussed to death back then and so it's kind of funny to me that it has suddenly come up again. The (possibly apocryphal) reason that my more in-the-know burner campmates told me way back when:
The year before a bunch of guys went around with a video camera and tried to release a "Girls of Burning Man" video in the style of "Girls Gone Wild". This was widely viewed as poor form. So the organizers put the clause in specifically to nip that kind of behavior in the bud. They didn't want people (women in particular) to have to worry about unwittingly becoming part of some cheesy softcore porn video.
When I tried to sign up for Verizon's wireless data service they wouldn't let me pass the credit check without a land line. I tried to tell them I didn't have a land line but they couldn't cope with that. Eventually the girl at the counter gave her sister's apartment number to the credit check guys (she didn't have a land line either). Got to love unbending bureaucracy.
Emacs and etags are your friend. Meta-. zips to the function under the cursor. C-s for incremental search. Meta-x grep-find for any other search.
Also, run the program with a debugger and step through it. Or put some print statements in key places and see what it produces.
I find that's all I ever need.
I installed this update and rebooted and now it kernel panics every time I try to boot! It happens early enough that I can't even boot into single user. Grrr.....
-David
-David
I loved the original Deus Ex and played all the way through it twice and played just the first few levels a number of times since then. I would definitely consider playing it all the way through again! It's a shame the second one wasn't as good as the first.
The sad thing is I have it for the Mac and it only runs in classic mode now. When the intel move becomes ubiquitous they aren't going to do classic and I'm going to lose Deus Ex (as well as all my nostalgic classic apps). Very sad.
-David
I know what you mean about the power lines. In my car I can hear the disk spin up so clearly. I noticed that I only get that if the iPod is plugged in--when it's running on batteries the noise is gone/really quiet.
Those are all very good suggestions, even the idea that I just want to hear it. I've had all those ideas myself too, and tried a number of different things to eliminate them:
Eq: Turned off the eq. Distortion is still there. Made sure the file didn't have a specific eq setting in iTunes, even though I'm not sure that setting affects the iPod.
Too loud: The distortion happens at low volumes and high volumes.
Bad headphones: I have a nice set of over the ear headphones. The distortion is still there.
Compression artifact: I listened to the original file with headphones from itunes (everything flat): no distortion. Back and forth between iPod and Mac, distortion is clearly there on the iPod, not on the Mac.
My own mind: I've had other people listen to the particular song and they confirm they are hearing the distortion too.
A problem with my iPod: I've tried friends and family members iPods (up to 4th gen) and they all had the same problem.
The distortion I am hearing is clearly digital clipping. It doesn't sound like compression artifacts or analog clipping. I've used 2 or 3 different headphones, my own stereo system, my work speakers, and my card stereo and the distortion is there, but not on the original file on a computer. On my list of things to do is to encode some sample tones and look at them on an oscilloscope. Maybe take some pictures and put up a little page about my findings.
I believe what I am hearing is some hard coded digital amplification that happens somewhere early on along the iPod's audio path. This makes the iPod's sound quality fundamentally flawed, which is one huge reason I've never bought one (the one I have is a hand-me-down).
-David
I know maybe you're joking, but it has nothing to do with volume. It's happening somehwere in the digital part, before the analog amplification stage. It's distorted even at the lowest volume settings. And it's clearly digital distortion--it has a distinct sound.
-David
I should've mentioned that the first thing I tried was getting rid of the EQ. With everything flat I still get the distortion. I also made sure the track had no special eq settings in iTunes.
With the EQ on it's so much distortion I can't even believe it.
-David
Apparently you've never heard an iPod. :-)
.wav on it to see if it was somehow related to the aac encoding, but it even a pure .wav distorted.
My first gen iPod (not very helpful to the original poster, I know) actively distorts sound! No environment, headphones, or ears are going to help that. It's like they have a hardcoded digitial amplification going on which just kills any music that recorded at at full volume. Which is to say, any rock album that came out in the last 5 or 10 years. Music older than that wasn't so heavily compressed (and I'm not talking about the mp3 sense), and so it doesn't distort. But Jeez, just try listening to anything with some good normalized bass and the iPod will digitally distort the crap out of it. It's really really horrible and it's not something you have to be an audiophile to hear. I would never recommend an iPod to anyone who is remotely concerned about sound quality.
Curiously, turning down the volume has no effect on the distortion. I also put a
I even tested with my friends 4th gen iPod and it still has this problem. My mom just got a video, but I haven't tested that to see if it sucks too.
Interestingly, my iPod shuffle doesn't do this. It must have a completely different audio path.
-David
The repeater function of firewire is also completely handled by hardware so when a packet comes in one port and gets put out to another port it's still completely isolated from software.
Besides, "tee" is in a completely different realm than firewire packets.
-David
Also, I'm talking about asynch bus packets here. Isoch packets (and asynch stream packets) have no destination address (just a channel number) and so any node can listen in on them.
99% of all 1394 cards follow the OHCI spec (hence no need to get data from the manufacturer). The OHCI spec does not allow snoop mode. Annoying, eh?
-David
For some moronic reason (I've heard it was bowing to pressure from content providers to make the firewire bus hard to sniff for the commoner--take that with a grain of salt), the OHCI spec (which 99% of all cards adhere to) does not include a way to enter promiscuous mode. So if you buy a cheap card you will not be able to monitor the bus.
TI used to make a non-OHCI chip called the PCI Lynx that had a sniffing mode. Apple has a nice FireWire protocol analyzer called FireBug that works with the Lynx chip. I believe I may have seen Linux software at some point that does similar packet sniffing. But these PCI Lynx based cards can be hard to find. At my old job (where we did lots of Firewire stuff) we bought a big bulk purchase of Cardbus Lynx cards and converted a bunch of cheap old powerbooks into mobile firewire analyzers.
-David
Warren Spector + Source Engine?
I'm feeling giddy!
I disagree here. Read the page you linked to again. The point is that you have to have a feel for the overall design of the program you are making and how that design will work in the end. It is not about how fast you can make memcpy() go (for example)--that can only get you so far. Take for example:
That is because in the context of C (which the discussion is about) the lengths of strings are not known (quickly). For large numbers of strings your algorithm is still orders of magnitude slower than keeping the strings sorted and doing a binary search. That was my real point, and Knuth's point. That optimizing your overall algorithm can yield vast improvements that hand optimizing little sections of code just cannot come close to. This is what the linked essay says that good programmers develop a feel for, not silly little tricks to speed up a single for loop. That's the kind of thing you do very last and only if you have an intensely speed critical application and you've already exhausted optimizing your algorithms--because you're only going to speed things up by small percentages.
If the reason you are talking about is some semblance of portability then you are right. Have you ever read the C rationale? It explains the reasoning of the decisions the C committee made and helps you see things from their point of view. It was very enlightening for me when I first read it. It apparently used to be part of the C standard but they broke it off into a separate document at some point.
-David
The problem is that when you profile a piece of code, quote often the slowest routine is something you never would have expected. Hand optimizing a routine that gets run 1% of the time is pointless. Quite often this sort of hand optimization makes code ugly, and why make your code ugly for no reason?
Another argument is that generally you don't ever have to do crazy platform specific optimizations to make your program run blazingly fast. For instance, if you determine that the slowest point of your program is the part that for loops through 1000 strings looking for a specific one, the smart thing to do isn't to go nuts hand optimizing the assembly of the loop or making the sure the strings are cache aligned or something. Switch your algorithm so the strings are kept sorted and then do a binary search. Or maybe make a hash table. Either way it's going to be an instant order of magnitude speedup--way way more than you could ever get by hand optimizing the original for loop.
I'm not sure I understand your assertion that the tools are holding you back. Take this structure:There is no implied packing in the C standard--C specifically strives to be platform neutral. Every compiler I've seen will put padding bytes in there to make the accesses fast (or doable at all--must ARM busses can't do unaligned transfers). But if Intel magically put together some hardware that made unaligned accesses just as fast as aligned accesses then the compiler would be able to remove the padding bytes on that architecture.
If you don't need the speed and need your structure smaller then you can tell the compiler to pack the structure (on gcc I think it's something like __attribute__((packed))). So there's nothing holding you back--they just make the default sane for most situations.
The point of C is to let the compiler do the stupid little architecture optimizations for you. So it seems to me like your main point is that you don't trust the compiler. Maybe you should try some of your ideas out in assembly and see if they are worthwhile. If you can show that a particular optimization is worthwhile write it up and send it to the gcc guys.
-David
That being said, most times you wont care about size or speed and so ints will do just fine. You shouldn't be hand optimizing at all unless you've determined that something is too large or too slow.
-David
Agreed, but it sometimes takes some thought to even realize you are coding in a processor specific manner. For instance, if you've ever programmed for a Mac or written networking code on a PC you realize that all binary data formats were created with a certain endian in mind, and if your processor's endianness is different you have to swap some bytes. No, it's not hard to do, but if you're implementing, say, a FAT filesystem on a little endian machine you might not even notice. And then, boom, your lovely code turns out to be not very portable after all.
-David
-David
This depends more on the bus than the CPU architecture. I know some 32 bit busses have lines to say whether the transfer is 8, 16, or 32 bits. If you read a byte of data on the bus--lets call it 0x0d, then 0x0d0d0d0d is actually sent across the bus. Other busses will work like you said and transfer 32 bits of data from a rounded address and then let the CPU pick out the correct byte. Some will just transfer 0xXXXXXX0d where XX is something random.
-David
-David
I wouldn't say google put their seal of approval on it--It's more like they put out an app (Google maps) that really showed off what you could do with the technology. I'm sure some of people have been using XMLHttpRequest since 1999 or whenever it came out, but *a lot* more people had never heard of it. Google maps opened a lot of eyes, including my own. I started looking into javascript for the first time after being wowed by Google maps and to my suprise I found it to be quite a nice little language. It even inspired me and a friend to write a bunch of our own javascript games.
-David
I'm with you though, XML is a horrible thing to pass back to a javascript. I've used all these techniques in some solitaire games me and a friend wrote and I found that the JSON method is just nice.
-David