Thanks for your substantial reply, as well as the link to the Alpha Architecture Handbook. I'll look into it.
Although I'm not a hardware designer, myself, I've co-authored the extASM ARM assembler, currently being updated to ARMv7. The assembler is itself written in ARM assembly, about 20,000 lines of it, so I've got quite a bit of experience with writing ARM code.:)
I understand what you mean about the shifter and the page tables, now.
As you allude to, the designers of the ARM weren't stupid when they made this design, but as it often is, what may have been an advantage (or an efficient design) at one time, may turn into a disadvantage (or contributing to less efficiency) later, as the field evolves.
One such thing I was recently made aware of is the SWI (system call) instruction. At the time, it was a reasonable design: Encode the system call number in the instruction (thereby saving a move instruction before the call). At the time, there were no instruction/data caches. However, with today's separate instruction/data caches, using the SWI instruction leads to "polluting" the data cache, as it needs to read the instruction (thus fill a data cache line) to find out the system call number.
Also, historical reasons and market factors may contribute to making a design that was once simple and clean/elegant, become rather more complex and loose some of its elegance. In the ARM's case, it has become rather a lot more complex (I know that all too well, having to implement all of its instructions in extASM...:) ), but that has also made it more powerful (such as the addition of long multiply, SIMD, and floating point support).
Crazy page table formats.
[...]
ARM has a more uniform encoding, but actually has a large number of instructions, and does crazy things like put a rotating shifter in the load address path.
Could you have expanded on these two statements? What's "crazy" about its page table format?
As for the ability to shift the address offset of a load/store, what's the problem with that? x86 has the same, except that their shifts are limited to a few places (at least it used to be that way).
Look, I wish the architecture made a difference. For one, we'd all probably be using Alpha. That was a great, elegant, beautiful processor architecture.
I don't know much about the Alpha, as it's been hard to find an assembly reference online, but some of what I think makes the ARM design elegant is:
- Three-register architecture, where you may operate on two registers, and store the result in a third.
- Conditional execution of all instructions (not for some of the new classes of instructions, such as the SIMD instructions, though).
- Optional PSR updating.
- Optional shifting of one of the operands by a constant, or a fourth register.
The combination of features like this makes for very elegant, powerful, and compact code.
The question is, can the Alpha do things like this?
I think you'll find that what is considered the most "elegant" and "best" processor tends to be highly subjective...
Furthermore, describing design choices as "crazy" doesn't sound very objective or balanced...
P.S. I won't go into a lot of your points, since your criticism is so shallow (a pity, as a good discussion of C++'s development could actually be useful, rather than just "mud slinging", which is just time-wasting...) - based on a shallow understanding or treatment of C++ and other languages and design alternatives (but some of it good points, if we had the manpower to do it...), but to pick one:
"Languages that implement generics correctly (Haskell, Ml, Erlang, Ada, etc) have sold these problems many moons ago."
How do you define "correctly"? It has been argued that Ada's generics "killed Ada", because they turned out to be so cumbersome to use (for one thing, you have to explicitly instantiate each generic type, while that happens implicitly in C++). Secondly, Ada's generics _have_ been considered, in the context of the C++ "concept" proposals, but have been found to provide little, if any help, in the case of C++: They're just too limited, to be useful for C++'s rich type system.
This was a long rant... You are aware of that C++ is developed essentially as an "open source" project (like PHP, Python, etc.)? This means that the people working on it get absolutely _no pay_ for their volunteer work, and in fact, have to pay to be allowed to work for free (!) by paying their own expenses (unless their employer contributes) for attending standards meetings, fees to ISO, etc.
If you're dissatisfied with the development of C++ (myself, I'm excited about the development), then YOU can do something about it, rather than just complaining, by contributing to the standards work. Maybe you'll then get an appreciation for the amount of work that goes into standards work.
A lot of the things you mention has been suggested to the committee, but there's a limited amount of manpower to work on these things, so for things to get into the standard requires someone to work for it: Write papers, present it to the committee, perhaps make prototype implementation to get real-world experience with it, etc. (the latter has been done for one of the "concept" proposals, by the way). All this can be a lot of work, for people who have ordinary jobs like others, and who's only "compensation" is the same as other open source work.
However, I guess it's easier to be an uninformed "armchair quarterback"...
Oh, and by the way, your encouragement of the committee's work is much appreciated... </sarcasm>
I've hardly posted to Slashdot, before, but I felt I wanted to, now, because finally I've found somebody else mention this problem, as well.
As others have pointed out, it's a limit of the GDI-resources, and it's independent of how much memory you have.
I actually got 256 MB more in my PC (so I now have 384 MB), because I thought it was a memory problem, without it helping, at all.
I have 384 MB RAM, and I can't have 100 windows?! That's stupid!
This is actually one of the worst things I know about Windows, and yes, I'm using Windows 2000, the same limitation is there.
I had 4 MB RAM on my Acorn Archimedes computer, and I never ran into this problem, there. I had just as many windows open.
They got this right in 1989. Now, 12 years later, and with incredibly more powerful hardware, they still haven't got it right, in Windows. That says some.
It was asked for an example of how this limit would affect anybody, and I'll happily give that.
I tend to run into this limit, daily, and I think this limit, and the feature that you can't have the input focus at any other window than the top one (it automatically pops to top), to be some of the most annying things about Windows.
How I run into this limit?
It's simple. I tend to open IE windows in separate windows, so I don't get interrupted from the current one, and don't have to wait for them to load, to continue.
That also makes it easy to go to the other pages, instantly.
It's very convenient.
For example, I can read an article, and open any links in it, in new windows, so I don't get interrupted from the current article, and can go to them, later.
That means I don't get interrupted, and don't have to hunt for links, later.
Unfortunately, this conveniency is limited by the stupid limit in Windows.
Has anybody else had problems with this limit? Or are you all just using one window, and jumping in and out of the current article, when following links, and using the Back-button to get back?
Isn't that very disturbing on the reading?
Wouldn't it be better to have it in separate windows?
I've found using separate windows to be a better way of using the browser.
Regards,
Terje
P.S. Has anybody else found all this "My"-stuff to be incredibly infantile? "My Computer", "My Documents", My, My, My! Like a baby.
This is also similar to the "network effect": That the value for each node in a network, raises exponentially with the number of nodes in the network, due to the interconnectedness of the nodes.
This is the reason why closed, proprietary subnets (like AOL, MSN, etc.) have failed, while the Internet has succeeded.
>Current standards aren't safe _because_ of the
>current (a.k.a. nonexistent) W3C patent policy.
>As it stands right now, any company could come up
>with a 'torpedo' patent and lay claim to CSS or
>HTML or SVG. In fact one company has
>already "patented" the combination of W3C XForms
>and W3C XML signatures. When this happens,
>everyone looses.
>At least with a written policy, no company can claim ignorance.
Actually, they can. The proposal only covers the member corporations. Anyone else can come with patent claims, after the standard has come into effect.
This can happen, both with and without the proposal.
The proposal seems like burning the village, to save the village. In essence, they say that, "Ok. To avoid that you come with patent claims, later, we'll let you use patents, now."
And they still don't stop possible others, coming later, as mentioned.
This doesn't solve the problem with "submarine patents" (unknown patents).
We're discussing patented standards, not patents, in general.
Regarding patented standards, I've already posted a comment to another posting.
From "Reality Master":
>Certainly we have a body of research that was
>created from public investment. It's not a
>question of whether you can get research from
>public investment, it's a question of
>efficiency. For example, no one doubts that the
>government could produce a "universal
>automobile" to compete with the major car
>companies. However, no one also doubts (that is
>sane, that is) that it would be a huge space-
>station-style, unbelievable disaster.
Since you mention it...
Where do you think we would have been, today, if each of the automobile companies patented their way of arranging the controls, such as accelerator, brakes, steering wheel, etc.?
In an unbelievable mess, that's where.
Each car would be incompatible with each other car, and you would require training, to learn to use each new car you were going to use, before you could use it.
Would this promote innovation, and lead to widespread use of the technology? NO!
It would lead to a balkanization of the car industry, that would seriously had hampered progress, and prosperity.
The same is the threat, today, if this happened to the Internet standards.
Thanks to cars working the same way, and TCP/IP being free for everyone to use, as well, we have avoided this.
Thanks for your substantial reply, as well as the link to the Alpha Architecture Handbook. I'll look into it.
Although I'm not a hardware designer, myself, I've co-authored the extASM ARM assembler, currently being updated to ARMv7. The assembler is itself written in ARM assembly, about 20,000 lines of it, so I've got quite a bit of experience with writing ARM code. :)
I understand what you mean about the shifter and the page tables, now.
As you allude to, the designers of the ARM weren't stupid when they made this design, but as it often is, what may have been an advantage (or an efficient design) at one time, may turn into a disadvantage (or contributing to less efficiency) later, as the field evolves.
One such thing I was recently made aware of is the SWI (system call) instruction. At the time, it was a reasonable design: Encode the system call number in the instruction (thereby saving a move instruction before the call). At the time, there were no instruction/data caches. However, with today's separate instruction/data caches, using the SWI instruction leads to "polluting" the data cache, as it needs to read the instruction (thus fill a data cache line) to find out the system call number.
Also, historical reasons and market factors may contribute to making a design that was once simple and clean/elegant, become rather more complex and loose some of its elegance. In the ARM's case, it has become rather a lot more complex (I know that all too well, having to implement all of its instructions in extASM... :) ), but that has also made it more powerful (such as the addition of long multiply, SIMD, and floating point support).
Regards,
Terje
Crazy page table formats. [...] ARM has a more uniform encoding, but actually has a large number of instructions, and does crazy things like put a rotating shifter in the load address path.
Could you have expanded on these two statements? What's "crazy" about its page table format?
As for the ability to shift the address offset of a load/store, what's the problem with that? x86 has the same, except that their shifts are limited to a few places (at least it used to be that way).
Look, I wish the architecture made a difference. For one, we'd all probably be using Alpha. That was a great, elegant, beautiful processor architecture.
I don't know much about the Alpha, as it's been hard to find an assembly reference online, but some of what I think makes the ARM design elegant is:
- Three-register architecture, where you may operate on two registers, and store the result in a third.
- Conditional execution of all instructions (not for some of the new classes of instructions, such as the SIMD instructions, though).
- Optional PSR updating.
- Optional shifting of one of the operands by a constant, or a fourth register.
The combination of features like this makes for very elegant, powerful, and compact code.
The question is, can the Alpha do things like this?
I think you'll find that what is considered the most "elegant" and "best" processor tends to be highly subjective...
Furthermore, describing design choices as "crazy" doesn't sound very objective or balanced...
Regards,
Terje
P.S. I won't go into a lot of your points, since your criticism is so shallow (a pity, as a good discussion of C++'s development could actually be useful, rather than just "mud slinging", which is just time-wasting...) - based on a shallow understanding or treatment of C++ and other languages and design alternatives (but some of it good points, if we had the manpower to do it...), but to pick one:
"Languages that implement generics correctly (Haskell, Ml, Erlang, Ada, etc) have sold these problems many moons ago."
How do you define "correctly"? It has been argued that Ada's generics "killed Ada", because they turned out to be so cumbersome to use (for one thing, you have to explicitly instantiate each generic type, while that happens implicitly in C++). Secondly, Ada's generics _have_ been considered, in the context of the C++ "concept" proposals, but have been found to provide little, if any help, in the case of C++: They're just too limited, to be useful for C++'s rich type system.
So much for being "correct"...
This was a long rant... You are aware of that C++ is developed essentially as an "open source" project (like PHP, Python, etc.)? This means that the people working on it get absolutely _no pay_ for their volunteer work, and in fact, have to pay to be allowed to work for free (!) by paying their own expenses (unless their employer contributes) for attending standards meetings, fees to ISO, etc.
If you're dissatisfied with the development of C++ (myself, I'm excited about the development), then YOU can do something about it, rather than just complaining, by contributing to the standards work. Maybe you'll then get an appreciation for the amount of work that goes into standards work.
A lot of the things you mention has been suggested to the committee, but there's a limited amount of manpower to work on these things, so for things to get into the standard requires someone to work for it: Write papers, present it to the committee, perhaps make prototype implementation to get real-world experience with it, etc. (the latter has been done for one of the "concept" proposals, by the way). All this can be a lot of work, for people who have ordinary jobs like others, and who's only "compensation" is the same as other open source work.
However, I guess it's easier to be an uninformed "armchair quarterback"...
Oh, and by the way, your encouragement of the committee's work is much appreciated... </sarcasm>
Oh, and by the way, I'm not using Linux, so my posting wasn't a plug for Linux. :)
:)
One poster mentioned that some may use this limit in Windows, to plug Linux, even if the limit is irrelevant for them.
I'm using Windows, and I can assure you the limit is very relevant.
In my opinion, there shouldn't be a hard-coded limit on the number of windows, in an operating system.
When the size isn't known in advance, use e.g. std::vector, not arrays, and you solve it.
Terje
Hi.
I've hardly posted to Slashdot, before, but I felt I wanted to, now, because finally I've found somebody else mention this problem, as well.
As others have pointed out, it's a limit of the GDI-resources, and it's independent of how much memory you have.
I actually got 256 MB more in my PC (so I now have 384 MB), because I thought it was a memory problem, without it helping, at all.
I have 384 MB RAM, and I can't have 100 windows?! That's stupid!
This is actually one of the worst things I know about Windows, and yes, I'm using Windows 2000, the same limitation is there.
I had 4 MB RAM on my Acorn Archimedes computer, and I never ran into this problem, there. I had just as many windows open.
They got this right in 1989. Now, 12 years later, and with incredibly more powerful hardware, they still haven't got it right, in Windows. That says some.
It was asked for an example of how this limit would affect anybody, and I'll happily give that.
I tend to run into this limit, daily, and I think this limit, and the feature that you can't have the input focus at any other window than the top one (it automatically pops to top), to be some of the most annying things about Windows.
How I run into this limit?
It's simple. I tend to open IE windows in separate windows, so I don't get interrupted from the current one, and don't have to wait for them to load, to continue.
That also makes it easy to go to the other pages, instantly.
It's very convenient.
For example, I can read an article, and open any links in it, in new windows, so I don't get interrupted from the current article, and can go to them, later.
That means I don't get interrupted, and don't have to hunt for links, later.
Unfortunately, this conveniency is limited by the stupid limit in Windows.
Has anybody else had problems with this limit? Or are you all just using one window, and jumping in and out of the current article, when following links, and using the Back-button to get back?
Isn't that very disturbing on the reading?
Wouldn't it be better to have it in separate windows?
I've found using separate windows to be a better way of using the browser.
Regards,
Terje
P.S. Has anybody else found all this "My"-stuff to be incredibly infantile? "My Computer", "My Documents", My, My, My! Like a baby.
There's a very good article on Salon, about this.
A beautiful story. Very well said.
This is also similar to the "network effect": That the value for each node in a network, raises exponentially with the number of nodes in the network, due to the interconnectedness of the nodes.
This is the reason why closed, proprietary subnets (like AOL, MSN, etc.) have failed, while the Internet has succeeded.
>Current standards aren't safe _because_ of the
>current (a.k.a. nonexistent) W3C patent policy.
>As it stands right now, any company could come up
>with a 'torpedo' patent and lay claim to CSS or
>HTML or SVG. In fact one company has
>already "patented" the combination of W3C XForms
>and W3C XML signatures. When this happens,
>everyone looses.
>At least with a written policy, no company can claim ignorance.
Actually, they can. The proposal only covers the member corporations. Anyone else can come with patent claims, after the standard has come into effect.
This can happen, both with and without the proposal.
The proposal seems like burning the village, to save the village. In essence, they say that, "Ok. To avoid that you come with patent claims, later, we'll let you use patents, now."
And they still don't stop possible others, coming later, as mentioned.
This doesn't solve the problem with "submarine patents" (unknown patents).
This seems to be getting pretty off-topic.
We're discussing patented standards, not patents, in general.
Regarding patented standards, I've already posted a comment to another posting.
From "Reality Master":
>Certainly we have a body of research that was
>created from public investment. It's not a
>question of whether you can get research from
>public investment, it's a question of
>efficiency. For example, no one doubts that the
>government could produce a "universal
>automobile" to compete with the major car
>companies. However, no one also doubts (that is
>sane, that is) that it would be a huge space-
>station-style, unbelievable disaster.
Since you mention it...
Where do you think we would have been, today, if each of the automobile companies patented their way of arranging the controls, such as accelerator, brakes, steering wheel, etc.?
In an unbelievable mess, that's where.
Each car would be incompatible with each other car, and you would require training, to learn to use each new car you were going to use, before you could use it.
Would this promote innovation, and lead to widespread use of the technology? NO!
It would lead to a balkanization of the car industry, that would seriously had hampered progress, and prosperity.
The same is the threat, today, if this happened to the Internet standards.
Thanks to cars working the same way, and TCP/IP being free for everyone to use, as well, we have avoided this.
A patent is supposed to let you make something, that others can't make.
A standard is supposed to let everybody do the same thing.
Isn't then a patented standard an oxymoron?