In the link you provided, the "backwards order" is a reference to little endianism, although they do not state so directly. If you read carefully, they talk about backwards data storage, and discuss how algorithms in C might not work if written to use the Intel method.
Here, we are considering the order of operands in the instruction, which does not effect the way the code runs.
you've essentially gotten rid of the operating system too, haen't you?
It sounds like the only thing being removed are protections. After removing these things, and operating system would still be needed for hardware initialization and providing base services. The key difference would be that those services would not have to be guarded because they could trust the application code.
At first, you might think it sounds nice since it would be so much more efficient. But this is not a very realistic idea. How could you guarantee that all code was written in a safe language? Evildoers would have no problem writing in their own "underground" unsafe languages (that would invariably have intimidating names like "C" and "assembly"), and the system would give full control to their code as if it were safe.
For a system to be stable and work well, major components must not implicitly trust the other components. There is a great deal of value in enforcing security and error detection whether application code needs/likes it or not.
is a reflection of the binary opcode which, in turn, made sense at the hardware level.
It isn't obvious to me why it made sense at the hardware level. I don't see why any ordering would be better than another, except that related bits should be grouped. I can imagine that it depends on the physical interface of the register file, but I don't see what would require that to be any particular way either.
If there is truth to what you say, I would certainly be interested in why one ordering makes more sense than another.
SRC,DEST seems like useful syntax considering that on paper I often pseudocode like:
3 + 2 --> a
Clearly, this differs from the a = 3 + 2 syntax of C. However, this is a similar issue to (+ 3 2) verses 3 + 2.
The order which is "naturally determined by the processor" does not seem to impact the way I'd like to think of it, and only seems to come up if you translate a lot of assembly to machine code by hand.
This is an interesting issue. There is real benefit to assemblers presenting similar views of different machines, but there is also value in variety.
I think that the only difference is that people who understand the lower-level system are more likely to consider the higher-level things. Ultimately, I think that some understanding of each layer of abstraction is necessary to succeed at designing within any layer, and that the best engineers study the entire system.
People who only want to know one layer are probably likely to go for a really high-level one, because Java seems easier than assembly. In truth though, I think that there are similar challenges and that designing good software is just as difficult in Java as in assembly. IMHO the biggest difference is how easy it is how obvious your mistakes are.
Being able to read the assembly output by compilers has helped me several times to find compiler bugs. Embedded compilers are sometimes really buggy, especially for new processors, and sometimes have trouble with some of the subtleties of C.
When I see code that doesn't work, but seems like it should, the first thing I look at is the assembly output. It is usually easy to trace through, since there is usually enough debug information to match the C code to the generated assembly. Some problems become obvious at that point.
Of course, there are also many cases like the one you suggest, where a high-level view is still enough to determine the general problem with enough understanding to present it to the compiler maintainers.
I agree. There are enough different paradigms that it should not be assumed that someone could understand any of them by virtue of understanding any one.
However, the best engineers are those who understand many layers of abstraction and many different paradigms. When you know the strengths of each different view of hardware/software, you can make much better design decisions.
Someone experienced in hardware design and assembly programming probably has no experience with higher-level programming. But if they have broad (even if shallow) experience, learning a new language or even a new way of thinking is probably not a problem for them.
For someone trying to learn about how processors work, the 08 is IMHO more appropriate than the 11 or 12, mostly because it is a smaller, more limited chip. 8-bit programming exposes you to many things you can get away with ignoring, especially since many people have only used 32-bit systems. 2^32 is much greater than 2^8, and generally makes the difference between thinking overflow will never happen and seeing it happen every time you try to do anything useful.
That said, my favorite chip (at the moment, at least) is the HC12 (16-bit), which is really quite similar to the 11 (compared to the 08). I have been quite pleased with Motorola's reference manuals, and the instruction sets are quite comfortable.
For anyone serious about learning the ins and outs of hardware/software, I would suggest writing assembly on 8-bit and either 16-bit or 32-bit chips with similar instruction sets. The differences between the 8-bit world and the 32-bit world are enlightening, and might even change the way you think about code. I would recommend trying a good mix of C and assembly code, because both will present different challenges to you.
But if you write a compiler and assembler first, it is much easier to design the instruction set and hardware, because you just have to do an as-built analysis to discover the machine's native code. Extra points if your compiler implementation generates instruction mnemonics (which makes the reverse-engineering of your instruction set much more straight-forward).
By that reasoning, implementing an API will greatly simplify the design work of the ABI. =P
Generally, an operating system saves context between tasks. That is, anything necessary to restore the current operating state of a task is saved (e.g. program counter, stack data).
The amount of saved data depends on how smooth of a context switch is needed. Most desktop OSs will save everything a task needs to run so that switches are very smooth and transparent to the application code. On the other hand, real-time OSs often save less. At work we are developing on a system with very contrained resources. The RTOS I have coded does not perform a full context switch. The stack data is not saved, and control jumps (via longjmp) to the RTOS scheduler. Every context switch blows away non-static variables, and restarts the current task at the top (or possibly switches to a new task). This is acceptable because it is a non-preemptive system. It is necessary because our memory contraints are very tight.
As an RTOS, the only things available are those specifically supported by the hardware. There is no magic to support you, that's what you're providing to others.
There is also no reason an OS must be written in assembly, or that it must not be. Many developers consider C a much more effective system language, although C programming is much different at that level and still requires a good understanding of the machine's instruction set.
The only way I can see getting around this would be for Google to add "Did you mean 'apple' as a _fruit_, _computer company_, or _fiona apple_?" to the top of the listings
While reading the article, I considered the same thing. It seems like it may be possible for Google to implement, and I think it would be an excellent feature. The engine could separate groups of results that have different sets of keywords in common; e.g. of results on keyword "apple", many will contain "mac", many others will contain "pie", but few will contain both. With a reasonable threshold of number of results per subcategory, it seems that this could provide great assistance to users by not expecting them to learn advanced search options or even to think of more search terms, very much along the lines of the "did you mean" feature, which no doubt has aided many poor-spelling searchers.
I'm a vegetarian, so I can quite glady say I've not.:-)
Some people I know actually eat SPAM from time to time. willingly! and they even claim to like it. I've purchased several cans, but only as jokes and such. Though I was at a party once where the snack table featured a large SPAM-sculpture of a pig with crackers all around. But despite its 'tempting' appearance, I've always managed to avoid it.
it's silly that after so long they'd be upset about spam-fighting software having having that in it's name. they've made little attempt to stop the widespread use of their trademark on the internet, and now more people associate the word "spam" with junk mail or vikings than with hormel's lovely "pork with ham" product.
they could refuse to accept the return by stating it did not come from their store
that would still be bad for customer relations, and is very unlikely to happen. as it is now, they could require a receipt to make returns (and deny otherwise, with the same reason you suggested), but that would likely end up turning their customers away, and many stores generally accept such returns. i really dont think a store like walmart would try tracking like that, as they'd likely hurt themselves by accusing customers of lying when they may indeed have just purchased an item from another walmart.
however, goto is still quite useful in the hands of an intelligent programmer (who knowns not to allow it to become a pasta-maker). i believe the book "code complete" mentioned this, if i remember correctly.
i've written a lot of assembly lately, and use GOTO (jump) commands generously throughout. so i can't help but encourage the use of goto.:-)
to make it actually secure, you could always put it online and access it via a URL containing a username and password, which would be fairly simple to set up server-side. web authentication is more secure than secrecy, at least.
of course, this only addresses the accessibility issue. there's still the matter of simplifying the addition and deletion of marks from any of the machines you may use...
i really don't think switching to free software will make large software companies happy. they only care about piracy because it represents lost money, but using an alternative product is basically the same. if you use their products, but wouldnt buy them anyway, they at least get their names out in front of you, and perhaps your friends and family. in the end they are businesses, not police.
if it was GPLed, you could not prevent redistribution, even if you did sell the source. open source includes more than just GPL, but stopping redistribution of source code and adding other restrictions seems to conflict with the idea of open source in general.
IMHO, not releasing sercurity fixes for some of their not-so-old products is a crime.
do you really think that producers should be required to continue producing? you're certainly entitled to such an opinion, but i think it's unreasonable to expect someone to support their product for longer than their licensing dictates.
in computer science, that's how tree's always grow.
weird, i know, and probably makes planting a pain. then again, most of computer science makes more sense standing on your head, if only for the rush of blood.
Slashdot Mirror
In the link you provided, the "backwards order" is a reference to little endianism, although they do not state so directly. If you read carefully, they talk about backwards data storage, and discuss how algorithms in C might not work if written to use the Intel method.
Here, we are considering the order of operands in the instruction, which does not effect the way the code runs.
you've essentially gotten rid of the operating system too, haen't you?
It sounds like the only thing being removed are protections. After removing these things, and operating system would still be needed for hardware initialization and providing base services. The key difference would be that those services would not have to be guarded because they could trust the application code.
At first, you might think it sounds nice since it would be so much more efficient. But this is not a very realistic idea. How could you guarantee that all code was written in a safe language? Evildoers would have no problem writing in their own "underground" unsafe languages (that would invariably have intimidating names like "C" and "assembly"), and the system would give full control to their code as if it were safe.
For a system to be stable and work well, major components must not implicitly trust the other components. There is a great deal of value in enforcing security and error detection whether application code needs/likes it or not.
is a reflection of the binary opcode which, in turn, made sense at the hardware level.
It isn't obvious to me why it made sense at the hardware level. I don't see why any ordering would be better than another, except that related bits should be grouped. I can imagine that it depends on the physical interface of the register file, but I don't see what would require that to be any particular way either.
If there is truth to what you say, I would certainly be interested in why one ordering makes more sense than another.
I like the way you explained that. I'll have to remember that reasoning the next time I get into a discussion about syntax.
SRC,DEST seems like useful syntax considering that on paper I often pseudocode like:
3 + 2 --> a
Clearly, this differs from the a = 3 + 2 syntax of C. However, this is a similar issue to (+ 3 2) verses 3 + 2.
The order which is "naturally determined by the processor" does not seem to impact the way I'd like to think of it, and only seems to come up if you translate a lot of assembly to machine code by hand.
This is an interesting issue. There is real benefit to assemblers presenting similar views of different machines, but there is also value in variety.
I think that the only difference is that people who understand the lower-level system are more likely to consider the higher-level things. Ultimately, I think that some understanding of each layer of abstraction is necessary to succeed at designing within any layer, and that the best engineers study the entire system.
People who only want to know one layer are probably likely to go for a really high-level one, because Java seems easier than assembly. In truth though, I think that there are similar challenges and that designing good software is just as difficult in Java as in assembly. IMHO the biggest difference is how easy it is how obvious your mistakes are.
Being able to read the assembly output by compilers has helped me several times to find compiler bugs. Embedded compilers are sometimes really buggy, especially for new processors, and sometimes have trouble with some of the subtleties of C.
When I see code that doesn't work, but seems like it should, the first thing I look at is the assembly output. It is usually easy to trace through, since there is usually enough debug information to match the C code to the generated assembly. Some problems become obvious at that point.
Of course, there are also many cases like the one you suggest, where a high-level view is still enough to determine the general problem with enough understanding to present it to the compiler maintainers.
only the most perverse programmer would develop GUIs in a low-level language.
That sounds like a challenge. =P
I agree. There are enough different paradigms that it should not be assumed that someone could understand any of them by virtue of understanding any one.
However, the best engineers are those who understand many layers of abstraction and many different paradigms. When you know the strengths of each different view of hardware/software, you can make much better design decisions.
Someone experienced in hardware design and assembly programming probably has no experience with higher-level programming. But if they have broad (even if shallow) experience, learning a new language or even a new way of thinking is probably not a problem for them.
The HC08 is even easyer then the HC11.
For someone trying to learn about how processors work, the 08 is IMHO more appropriate than the 11 or 12, mostly because it is a smaller, more limited chip. 8-bit programming exposes you to many things you can get away with ignoring, especially since many people have only used 32-bit systems. 2^32 is much greater than 2^8, and generally makes the difference between thinking overflow will never happen and seeing it happen every time you try to do anything useful.
That said, my favorite chip (at the moment, at least) is the HC12 (16-bit), which is really quite similar to the 11 (compared to the 08). I have been quite pleased with Motorola's reference manuals, and the instruction sets are quite comfortable.
For anyone serious about learning the ins and outs of hardware/software, I would suggest writing assembly on 8-bit and either 16-bit or 32-bit chips with similar instruction sets. The differences between the 8-bit world and the 32-bit world are enlightening, and might even change the way you think about code. I would recommend trying a good mix of C and assembly code, because both will present different challenges to you.
But if you write a compiler and assembler first, it is much easier to design the instruction set and hardware, because you just have to do an as-built analysis to discover the machine's native code. Extra points if your compiler implementation generates instruction mnemonics (which makes the reverse-engineering of your instruction set much more straight-forward).
By that reasoning, implementing an API will greatly simplify the design work of the ABI. =P
Generally, an operating system saves context between tasks. That is, anything necessary to restore the current operating state of a task is saved (e.g. program counter, stack data).
The amount of saved data depends on how smooth of a context switch is needed. Most desktop OSs will save everything a task needs to run so that switches are very smooth and transparent to the application code. On the other hand, real-time OSs often save less. At work we are developing on a system with very contrained resources. The RTOS I have coded does not perform a full context switch. The stack data is not saved, and control jumps (via longjmp) to the RTOS scheduler. Every context switch blows away non-static variables, and restarts the current task at the top (or possibly switches to a new task). This is acceptable because it is a non-preemptive system. It is necessary because our memory contraints are very tight.
As an RTOS, the only things available are those specifically supported by the hardware. There is no magic to support you, that's what you're providing to others.
There is also no reason an OS must be written in assembly, or that it must not be. Many developers consider C a much more effective system language, although C programming is much different at that level and still requires a good understanding of the machine's instruction set.
this link describes what they seem to be referring to.
Does the Bible say pi equals 3.0?
The only way I can see getting around this would be for Google to add "Did you mean 'apple' as a _fruit_, _computer company_, or _fiona apple_?" to the top of the listings
While reading the article, I considered the same thing. It seems like it may be possible for Google to implement, and I think it would be an excellent feature. The engine could separate groups of results that have different sets of keywords in common; e.g. of results on keyword "apple", many will contain "mac", many others will contain "pie", but few will contain both. With a reasonable threshold of number of results per subcategory, it seems that this could provide great assistance to users by not expecting them to learn advanced search options or even to think of more search terms, very much along the lines of the "did you mean" feature, which no doubt has aided many poor-spelling searchers.
And have you ever had SPAM musubi?
:-)
I'm a vegetarian, so I can quite glady say I've not.
Some people I know actually eat SPAM from time to time. willingly! and they even claim to like it. I've purchased several cans, but only as jokes and such. Though I was at a party once where the snack table featured a large SPAM-sculpture of a pig with crackers all around. But despite its 'tempting' appearance, I've always managed to avoid it.
"that's not got much spam in it..."
as i understand, it was short for "spiced ham". but your suggestion seems far more accurate :-)
it's silly that after so long they'd be upset about spam-fighting software having having that in it's name. they've made little attempt to stop the widespread use of their trademark on the internet, and now more people associate the word "spam" with junk mail or vikings than with hormel's lovely "pork with ham" product.
they could refuse to accept the return by stating it did not come from their store
that would still be bad for customer relations, and is very unlikely to happen. as it is now, they could require a receipt to make returns (and deny otherwise, with the same reason you suggested), but that would likely end up turning their customers away, and many stores generally accept such returns. i really dont think a store like walmart would try tracking like that, as they'd likely hurt themselves by accusing customers of lying when they may indeed have just purchased an item from another walmart.
ah, referencing Dijkstra. clever.
:-)
however, goto is still quite useful in the hands of an intelligent programmer (who knowns not to allow it to become a pasta-maker). i believe the book "code complete" mentioned this, if i remember correctly.
i've written a lot of assembly lately, and use GOTO (jump) commands generously throughout. so i can't help but encourage the use of goto.
to make it actually secure, you could always put it online and access it via a URL containing a username and password, which would be fairly simple to set up server-side. web authentication is more secure than secrecy, at least.
of course, this only addresses the accessibility issue. there's still the matter of simplifying the addition and deletion of marks from any of the machines you may use...
There's a pretty well known fact that if you put a frog in cool water...
i thought that was because they are cold blooded.
the time factor probably is what did it though.
i really don't think switching to free software will make large software companies happy. they only care about piracy because it represents lost money, but using an alternative product is basically the same. if you use their products, but wouldnt buy them anyway, they at least get their names out in front of you, and perhaps your friends and family. in the end they are businesses, not police.
if it was GPLed, you could not prevent redistribution, even if you did sell the source. open source includes more than just GPL, but stopping redistribution of source code and adding other restrictions seems to conflict with the idea of open source in general.
IMHO, not releasing sercurity fixes for some of their not-so-old products is a crime.
do you really think that producers should be required to continue producing? you're certainly entitled to such an opinion, but i think it's unreasonable to expect someone to support their product for longer than their licensing dictates.
in computer science, that's how tree's always grow.
weird, i know, and probably makes planting a pain. then again, most of computer science makes more sense standing on your head, if only for the rush of blood.