I don't know what part of Japan your friends live in or what provider they're on, but my provider and all the providers I checked the last time I checked sell ADSL to the home. And business class (symmetric) connections are expensive. (1.5M/500K for about a tenth the cost of a 1M business connection, and about half the best price I last found in the US for 1.5M/250K ADSL).
which you shine on a thing to decide whether it is right or wrong. After you decide one way or another, then you have to decide whether you care that someone might be watching.
Whatever Heinlein might have said at various times, that voice that says someone might be watching can derive from a number of sources, many of them anything but benificent. That voice that says fear the watcher is pretty often working at odds with conscience (and freedom), the opinions of some of Heinlein's characters notwithstanding.
Were you or were you not the one who posted the idea that least-significant first is more efficient?
If you were, the reality behind that idea directly conflicts with the use of descriptors. Write down a descriptor, and then write down the macro expansion of the code required to navigate the descriptor. There you see what the corner cases really cost you.
Then re-write the code for a most-significant first datum (using, of course, a most-significant first CPU).
I'm sure it will feel as uncomfortable to you to write for most-significant first as it feels to me to write for least-significant first. And, yes, that lack of familiarity will lead to some bugs, bugs best avoided through careful use of macros. But it doesn't matter whether you are more familiar with one or the other. When you know what you're working with you tend to produce fewer bugs.
But you can't cover the corner cases without losing the advantage of "endian-ness" (whichever set of advantages you prefer). Either it's code (possibly hidden by macros) which covers the corners, or it's just simply making everything large enough to store a register.
But I really do think that the tendency to depend on integers looking the same whether read (from the same address) as byte, word, or long word, tends (without macros) to induce the programer to not think about the sizes of their integer variables. With most significant first, if you mix access sizes, you generally see variables that suddenly contain values much larger or smaller than they should, so you tend to see the bug early.
But the real world presents more options than an optimizer can deal perfectly with. The optimizer can only aim for a statistical best case and try to degrade gracefully when the guess misses. Generally, the more agressive the optimization is, the worse it degrades when the guesses miss.
You can't optimize completely at compile time. If you could, the resulting program would consist of a single instruction. Care to guess what that instruction would be?
That's arguing an absurdity, but the point is that for itanium to work you have to optimize so much that the resultant code will stall if it hits the real world.
But concerning buffer overflows, descriptors only help if you don't have control over the interpretation thereof. And unless those descriptors handle general arrays, you've still got buffer overflows. Unless, of course, the macro generates instructions to grab an address as a parameter and reach out into allocated memory, etc., in which case you are now talking about BASIC or C# levels of abstraction. And by that time, you don't care about bytes and words and byte order at all.
Most significant byte first, least first, either the variable is allocated assuming long word access, or it has to be moved when the variable size changes. The indirection of descriptors can't change that fact, either.
I will grant that with least significant first, iff you pre-allocate the thing to the register width and clear the whole thing first, and simply access it as a byte if you think it's a byte, the bit pattern doesn't vary when you access it as a word. But where's the advantage?
And you still have at least the problem of whether your code tries to interpret 0b10000000 as plus or minus 128, and that defintely is a problem when you don't know whether you're grabbing a byte or something larger in least significant first.
The problem I have with least significant first is pretty much derived from the (apparent) convenience you claim. My experience is that it tends to induce silent, data corrupting errors. A good compiler can pretty much cover those cases silently, but, as I say, whether the compiler or the programmer covers the boundary and corner cases, they have to be covered to have dependable code, and then you lose any real effect of the supposed convenience.
And your ordinary C compiler doesn't cover the corners and edges, and that's part of the reason Microsoft's code tends to be full of holes.
On the gforth mailing list just now, I saw some exchange from someone moving some code from pygmy forth to forth. Apparently, in pygmy forth, the entire heap, allocated or not, can be accessed without generating bus errors, so someone implemented a little random number routine that took the random number from the library routine and used it as an address. It seems to work.
I think it's the same with this particularly "advantage" of least significant byte first. It tends to foster programs that "seem" to work.
The one argument for least significant first that I will acknowledge (though I don't at this time agree that it makes it prefereable over most significant first in CPUs) is that it keeps the digit number and the power of the base the same. It is sort of aesthetically pleasing. Oh, and there's that metaphysical business of emphasizing the one over the many when reading from low addresses to high, which is the usual procession.
Or an off-by-one. Or one of several similar coding errors that lead to vulnerabilities.
And, since packed structures tend to change, and then new code on old structures tends to fail silently in least significant first CPUS precesiely when the count crosses the byte boundary, this kind of programming tends to corrupt data.
But you were aware of those, and assuming that real programmers never do such things?
By the time you take care of the corner cases, byte order advantages disappear. Better to just load and store what's there.
And, as far as trying to get a word or long word out of a byte string, why would you want to do that? What happens when you want three bytes, or five? Do you really want to let the CPU stall when you grab misaligned data? How much do you really gain by not having the patience to move the byte string one byte at at time?
You do understand that the block move optimization that checks the length of the block and shifts gears to register-wide moves for blocks that are long enough to justify the shift work just the same in any byte order?
I'm going to let your comment on VAX slide, because I don't remember whether or not the NUXI business was PDP or VAX or both, I don't have my source code from college that would tell me, and looking it up on the web reveals a lot of people building web pages on byte ordering who don't seem to understand teh NUXI problem at all.
> I don't think you understood that. > But, I would hope register renaming would catch that sequence. > Can segment registers be renamed?
> And there are processors that can do [what] you were thinking > about without any of those steps. Not all processors are equal.
No, processors are _not_ all equal.
And the x86 execution model is too limited (too few segments, too few stacks, too few index registers) and has perverted the run-time of every modern OS.
Except that the teacher's job is hard enough anyway, I'm not going to support making them spin their wheels thinking up _unique_ topics for term papers that fit the requirements of the class.
Shoot, picking the topic was part of the student's job when I was in high school and college.
The real solution is to simply walk through the thing with the student, including some short essays they have to write, in class, drawing from their research. If you watch them as they write, you know that it's them writing, and you can compare styles. (This, of course, adds to the workload, but if teachers don't have time to do this much they really have class loads that are too big to allow them to teach.)
Ultimately, however, as has been already said once, learning is the student's responsibility. We just have to figure out better ways to motivate kids to use their minds early, while they can still be persuaded. Unfortunately, the easy ways to motivate them all smack of religion, however.
If we can get them motivated, then they aren't really going to be cheating. Even if they borrow or collaborate, they'll be learning as they go, and that's the goal anyway.
was sample code and _cheap_ sample hardware. And it's still the same.
I know that, when you have embedded applications eating up all the output of your fab lines, it sees extra expensive to feed the guys who are eating dirt and going naked to build something in the garage, but some of those guys eating dirt and going naked today are building the killer applications that make the new markets tomorrow.
Besides, a CPU vendor that doesn't write (lots of) code for their own processors really won't have a grasp on the effects of various aspects of their own processors' designs.
And, why they dropped the 6809 and built on the 6801, I don't really want to know. But it was possibly their worst strategical error. (Spiting Hitachi? Competition with their own 68k?)
Except that, until we get the GPL ironed out, whatever is in embedded stuff isn't re-programmable, so it doesn't alter the momentum of the re-programmable sector.
for many applications (especially now that characters are not 8 bit), for people who knew the instruction set.
Theoretically, anyway. Too many of the optimization architects for the m68k compilers didn't seem to understand the instruction set, however, and Motorola wasted a lot of time playing with complicated addressing modes in silicon when they should have some college intern first analyze the effect by substituting proposed op codes into real code.
I have often thought that Motorola would have benefitted greatly if they had simply written more sample code for their CPUs. iNTEL's lead in the visible sector (as opposed to the sector of the market most people overlook, where they have no lead at all) was primarily fueled by a corporate attitude that fostered sample code and cheap sample hardware, and we still see them with a somewhat better relationship with the free software and open source software communities than Freescale and many of their other competitors.
(And it's the lack of cheap sample hardware that is slowing PPC and ARM in the desktop sector. It appears to me that the difficulty of getting cheap dev/test boxes is directly related to the popularity of the chip in the embedded sector. And it still bugs me that I can't re-program my wristwatch.)
m6809 was even more efficient, although the couldof's and the wouldof's make it impossible to discuss meaningfully any more.
(And if you want to look at efficient ISAs, look at the descendants of the 6805. EEEEUuuUUGGGHHH!)
Slashdot Mirror
I don't know what part of Japan your friends live in or what provider they're on, but my provider and all the providers I checked the last time I checked sell ADSL to the home. And business class (symmetric) connections are expensive. (1.5M/500K for about a tenth the cost of a 1M business connection, and about half the best price I last found in the US for 1.5M/250K ADSL).
Some people at Apple think it allows very high speed of development.
I know it has a learning curve, if I had patience to get over that curve I might be able to talk to the question from personal experience.
which you shine on a thing to decide whether it is right or wrong. After you decide one way or another, then you have to decide whether you care that someone might be watching.
Whatever Heinlein might have said at various times, that voice that says someone might be watching can derive from a number of sources, many of them anything but benificent. That voice that says fear the watcher is pretty often working at odds with conscience (and freedom), the opinions of some of Heinlein's characters notwithstanding.
Now who is it that is eating her consort(s)?
I'm sure geeks always enjoy a discussion of navel reactors.
Quick, somebody get a username steve_ballmer and upload it. bill_gates, too.
(Darkness Emitting Diode. Where did I put the spec sheet I had on that?)
Were you or were you not the one who posted the idea that least-significant first is more efficient?
If you were, the reality behind that idea directly conflicts with the use of descriptors. Write down a descriptor, and then write down the macro expansion of the code required to navigate the descriptor. There you see what the corner cases really cost you.
Then re-write the code for a most-significant first datum (using, of course, a most-significant first CPU).
I'm sure it will feel as uncomfortable to you to write for most-significant first as it feels to me to write for least-significant first. And, yes, that lack of familiarity will lead to some bugs, bugs best avoided through careful use of macros. But it doesn't matter whether you are more familiar with one or the other. When you know what you're working with you tend to produce fewer bugs.
But you can't cover the corner cases without losing the advantage of "endian-ness" (whichever set of advantages you prefer). Either it's code (possibly hidden by macros) which covers the corners, or it's just simply making everything large enough to store a register.
But I really do think that the tendency to depend on integers looking the same whether read (from the same address) as byte, word, or long word, tends (without macros) to induce the programer to not think about the sizes of their integer variables. With most significant first, if you mix access sizes, you generally see variables that suddenly contain values much larger or smaller than they should, so you tend to see the bug early.
Yes, you can optimize at compile time.
But the real world presents more options than an optimizer can deal perfectly with. The optimizer can only aim for a statistical best case and try to degrade gracefully when the guess misses. Generally, the more agressive the optimization is, the worse it degrades when the guesses miss.
You can't optimize completely at compile time. If you could, the resulting program would consist of a single instruction. Care to guess what that instruction would be?
That's arguing an absurdity, but the point is that for itanium to work you have to optimize so much that the resultant code will stall if it hits the real world.
is the only real solution, hard-wired to only connect to the bank (checks via one-time pad and similar arrangements).
Since the browser won't even connect if the server can't answer, there are no display issues.
The browser and one-time pads are distributed at a physical branch office, probably on CD, probably written in Java.
And then you talk of descriptors and macros.
I sense some confusion.
But concerning buffer overflows, descriptors only help if you don't have control over the interpretation thereof. And unless those descriptors handle general arrays, you've still got buffer overflows. Unless, of course, the macro generates instructions to grab an address as a parameter and reach out into allocated memory, etc., in which case you are now talking about BASIC or C# levels of abstraction. And by that time, you don't care about bytes and words and byte order at all.
Most significant byte first, least first, either the variable is allocated assuming long word access, or it has to be moved when the variable size changes. The indirection of descriptors can't change that fact, either.
I will grant that with least significant first, iff you pre-allocate the thing to the register width and clear the whole thing first, and simply access it as a byte if you think it's a byte, the bit pattern doesn't vary when you access it as a word. But where's the advantage?
And you still have at least the problem of whether your code tries to interpret 0b10000000 as plus or minus 128, and that defintely is a problem when you don't know whether you're grabbing a byte or something larger in least significant first.
The problem I have with least significant first is pretty much derived from the (apparent) convenience you claim. My experience is that it tends to induce silent, data corrupting errors. A good compiler can pretty much cover those cases silently, but, as I say, whether the compiler or the programmer covers the boundary and corner cases, they have to be covered to have dependable code, and then you lose any real effect of the supposed convenience.
And your ordinary C compiler doesn't cover the corners and edges, and that's part of the reason Microsoft's code tends to be full of holes.
On the gforth mailing list just now, I saw some exchange from someone moving some code from pygmy forth to forth. Apparently, in pygmy forth, the entire heap, allocated or not, can be accessed without generating bus errors, so someone implemented a little random number routine that took the random number from the library routine and used it as an address. It seems to work.
I think it's the same with this particularly "advantage" of least significant byte first. It tends to foster programs that "seem" to work.
The one argument for least significant first that I will acknowledge (though I don't at this time agree that it makes it prefereable over most significant first in CPUs) is that it keeps the digit number and the power of the base the same. It is sort of aesthetically pleasing. Oh, and there's that metaphysical business of emphasizing the one over the many when reading from low addresses to high, which is the usual procession.
joudanzuki
I live in Japan. My wife does not want to move. She knows about global warming.
I find myself watching this argument and wondering how one person is going to laugh at the other when the water hits the fan.
This is the wrong way to solve the problems.
waiting to happen.
Or an off-by-one. Or one of several similar coding errors that lead to vulnerabilities.
And, since packed structures tend to change, and then new code on old structures tends to fail silently in least significant first CPUS precesiely when the count crosses the byte boundary, this kind of programming tends to corrupt data.
But you were aware of those, and assuming that real programmers never do such things?
By the time you take care of the corner cases, byte order advantages disappear. Better to just load and store what's there.
And, as far as trying to get a word or long word out of a byte string, why would you want to do that? What happens when you want three bytes, or five? Do you really want to let the CPU stall when you grab misaligned data? How much do you really gain by not having the patience to move the byte string one byte at at time?
You do understand that the block move optimization that checks the length of the block and shifts gears to register-wide moves for blocks that are long enough to justify the shift work just the same in any byte order?
I'm going to let your comment on VAX slide, because I don't remember whether or not the NUXI business was PDP or VAX or both, I don't have my source code from college that would tell me, and looking it up on the web reveals a lot of people building web pages on byte ordering who don't seem to understand teh NUXI problem at all.
joudanzuki
Was overrated at one? You've got to be kidding.
> I don't think you understood that.
> But, I would hope register renaming would catch that sequence.
> Can segment registers be renamed?
> And there are processors that can do [what] you were thinking
> about without any of those steps. Not all processors are equal.
No, processors are _not_ all equal.
And the x86 execution model is too limited (too few segments, too few stacks, too few index registers) and has perverted the run-time of every modern OS.
It's time to junk it.
Except that the teacher's job is hard enough anyway, I'm not going to support making them spin their wheels thinking up _unique_ topics for term papers that fit the requirements of the class.
Shoot, picking the topic was part of the student's job when I was in high school and college.
The real solution is to simply walk through the thing with the student, including some short essays they have to write, in class, drawing from their research. If you watch them as they write, you know that it's them writing, and you can compare styles. (This, of course, adds to the workload, but if teachers don't have time to do this much they really have class loads that are too big to allow them to teach.)
Ultimately, however, as has been already said once, learning is the student's responsibility. We just have to figure out better ways to motivate kids to use their minds early, while they can still be persuaded. Unfortunately, the easy ways to motivate them all smack of religion, however.
If we can get them motivated, then they aren't really going to be cheating. Even if they borrow or collaborate, they'll be learning as they go, and that's the goal anyway.
Explain yourself.
because it requires a fundamental change in the basic run time to justify the extra OS stuff to support it.
And everyone is scared of change.
that IBM built based on the M68K, and, yes, it cost about twice as much, as I recall.
http://www.old-computers.com/museum/computer.asp?s t=1&c=623
was sample code and _cheap_ sample hardware. And it's still the same.
I know that, when you have embedded applications eating up all the output of your fab lines, it sees extra expensive to feed the guys who are eating dirt and going naked to build something in the garage, but some of those guys eating dirt and going naked today are building the killer applications that make the new markets tomorrow.
Besides, a CPU vendor that doesn't write (lots of) code for their own processors really won't have a grasp on the effects of various aspects of their own processors' designs.
And, why they dropped the 6809 and built on the 6801, I don't really want to know. But it was possibly their worst strategical error. (Spiting Hitachi? Competition with their own 68k?)
But embedded isn't re-programmable in the market at large, so the effect on market inertia is zero.
Zip.
Nada.
Of course, embedded is also much more free from the effects of market inertia.
are the culprits, I think
embedded base.
Except that, until we get the GPL ironed out, whatever is in embedded stuff isn't re-programmable, so it doesn't alter the momentum of the re-programmable sector.
The real problem with itanium is that you simply can't optimize the entire program at compile time.
If you could, you would only need one instruction, but that would not be a very exciting world for computer scientists.
(NOOP, if you have to ask.)
for many applications (especially now that characters are not 8 bit), for people who knew the instruction set.
Theoretically, anyway. Too many of the optimization architects for the m68k compilers didn't seem to understand the instruction set, however, and Motorola wasted a lot of time playing with complicated addressing modes in silicon when they should have some college intern first analyze the effect by substituting proposed op codes into real code.
I have often thought that Motorola would have benefitted greatly if they had simply written more sample code for their CPUs. iNTEL's lead in the visible sector (as opposed to the sector of the market most people overlook, where they have no lead at all) was primarily fueled by a corporate attitude that fostered sample code and cheap sample hardware, and we still see them with a somewhat better relationship with the free software and open source software communities than Freescale and many of their other competitors.
(And it's the lack of cheap sample hardware that is slowing PPC and ARM in the desktop sector. It appears to me that the difficulty of getting cheap dev/test boxes is directly related to the popularity of the chip in the embedded sector. And it still bugs me that I can't re-program my wristwatch.)
m6809 was even more efficient, although the couldof's and the wouldof's make it impossible to discuss meaningfully any more.
(And if you want to look at efficient ISAs, look at the descendants of the 6805. EEEEUuuUUGGGHHH!)
joudanzuki