Agreed. Knowing assembly language gives you a far better understanding of "how" the processor actually WORKS. Now, while learning assembly out-of-the-blue often seems quite difficult and daunting, I think it makes more sense to learn in the context of a computer architecture course.
If you know how a processor actually functions, then assembly is just a natural way to codify instructions. If you don't understand how a processor works, then it may not make any sense.
It is also useful to learn how easy it can be, for simple code, to translate between C and assembly. This is especially useful for embedded development, where program size counts, processor power is limited, processor-specific features directly matter, and sometimes you have to deal with crappy, non-standard, compilers (and need to see if their output assembler is accessing memory in the way you intended, etc).
You've got some of the spirit right, but a lot of the details wrong. First, both Windows AND Linux run in "protected mode" (which I guess is the x86 term for "I'm using the MMU/w protected memory). In fact, any multitasking OS should do this.
Second, with protected memory, the OS does not intercept memory access. Can you imagine how slow this would be? Every memory access would require an interrupt, context switch, dozens to hundreds of instructions to handle, etc... Even if you don't count "instruction fetch" as a memory access in this sense (though it is one), it would still be totally pointless.
What actually happens, is that the OS tells the CPU's MMU (memory management unit) what memory the program is allowed to use (setting up virtual memory mappings, etc). All runtime memory access is managed directly by the CPU in this sense. The only time the OS gets involved, is if you have a page fault. (program tries too access memory address not in RAM, a page fault occurs, which tells the OS to go swap in that memory from disk)
Now how does the CPU know who is allowed to control the MMU, and all those other "protected" functions? Well, it has a mode flag. Basically, you have a "unprivileged mode"(app) and a "supervisor"(OS) mode. When in "unprivileged" mode, you cannot do anything bad. The only way to get into "supervisor" mode is to trigger an interrupt that is serviced by the OS.
In reality, I should hope Linux should be "more" restrictive (not less) in terms of what it lets you do. Multitasking without absolute memory and resource protection is just asking for fatal OS crashes and other bad things.
Yeah, it's fun being able to boast about all the big mean computer "stuff" you have. Well, at least until you get to the point where someone needs to be of similar "geek caliber" as you to even understand what it is you're boasting about.
Well, they never did make CISC SPARCstations, because the "SPARC" is a RISC processor. However, before developing SPARC, Sun did make workstations using Motorola 680XX chips.
In any case, often the chip doesn't actually execute 1 instruction per clock cycle. What it does do is pipelining, which means on average it may fetch one instruction per cycle, and complete one instruction per cycle, but they're usually not the same instruction (where an individual instruction takes several clocks to complete).
Re:Perhaps you tried the wrong distro
on
FreeBSD 5.2 Review
·
· Score: 2, Interesting
I would have to majorly disagree on your opinion of the learning curve. FreeBSD has a substantually smaller learning curve than Linux, for someone who wants to tinker with the system. It is much easier to figure out how everything works, where everything goes, and how to use all the system commands.
What most Linux distributions tend to do, isn't to ease the learning curve, but to circumvent it. They provide tons of nice and pretty user-friendly utilities (that work a lot of the time, but not all the time) to do anything. But if you want to go in and manually set things up, it is MUCH harder than in FreeBSD. The only Linux distro that comes close to the clean feeling of a FreeBSD install is Slackware. But Slackware is bare-bones and featureless, while FreeBSD is quite the opposite.
FreeBSD aims to make the easist and most useable system for people who know what they're doing. Most Linux distros try to make some user-friendly setup that doesn't cut it for newbies, and gets in the way of more experienced folk.
It really comes down to the average member of their respective user communities. Just listen to round-the-room introductions at a LUG and a BUG if you want to hear. Most BSD users are looking for a UNIX, many being sysadmins by trade (and generally aren't afraid of other 'nixes either). Most Linux users are looking for an "alternative" to something else. (I know this isn't across the board, as I first installed Linux because I was looking for a PC-based UNIX and didn't know of anything else, though I did discover and move to FreeBSD a few years later)
Well I do live in Florida, and I see plenty of SUVs out there. However, I've found an interesting and annoying shift in the population SUV drivers.
Initially, all SUV drivers were male and complete assholes on the road. They certified this before allowing them to buy, it seemed. They were even REQUIRED to pass you under all circumstances, regardless of whether or not they actually wanted to go any faster after passing.
These days, I see a very large portion of SUV drivers being middle-aged women, who frankly act like road obstructions on the fast highways. As any large vehicle inhibits your view in a car, you either want them easily passable or just simply out of the way. These newer SUV drivers are just too annoying.
In any case, I see SUVs as a vehicle whose sole purpose is showing off or being a prick on the road. Think about it... If you need to carry lots of people, there are minivans. If you need to haul or tow crap, just buy a damn pickup truck. If you absolutely must do off-road, just get a damn Jeep or HumVee.
What really annoys me is how people with no real X exposure simply do not understand the advantages of this. The most irritating thing of all is that they don't know the very big and important differences between a "remote desktop" and a "remote application displaying locally".
Yeah, the underlying OS is more changable than most people think. When most people think "Linux", they're really thinking of a certain suite of userland software. Guess what? No one said you had to run Linux to use any of that. I have a desktop computer that uses KDE for the desktop, Evolution for E-Mail, Opera and Mozilla for the web, Gaim and X-Chat for chatting. What OS is it running? Solaris!
Now for x86, I often tend to lean towards FreeBSD. And guess what? Just about all that software also runs on FreeBSD, and it's actually very easy to get it all working.
With portability, however, I tend to prefer NetBSD as the "run on anything OS" (or OpenBSD, on the platforms it supports). I know Linux has a lot of ports, but those are just the kernel, often with little to back it up. With NetBSD, you get the "whole" system for most of the platforms on that very long list. Makes a great tinker OS for any random piece of computing hardware you may run across.
Running those same commands on my FreeBSD 4.9 server, I get the results: 60/6769/440
The *BSDs share so much code between each other, and most source files have ident tags from different *BSDs, that Apple could have mostly pulled from FreeBSD and may still produce the numbers you saw.
"Enterprise" market? Somehow, I'd think the Xserve still qualifies as an "edge" server. Now if Apple decides to come out with a 4-16 way server with hot-swappable system boards, then we'll be talking "enterprise" servers:-)
(of course they could, but it would be hard to justify the R&D given their current target market)
Here's the sad part about Sun framebuffers... I've got some SunRay units plugged into it, and guess what? When "scrolling in a web browser", and doing some other standard 2D GUI tasks, the SunRay is MUCH faster than the local framebuffer. (of course for video, or anything less "acceleratable", the reverse is true).
It's not an "Ultra Sparc 5". "UltraSPARC" is the name of the processor, not the machine. The machine's official name is "Sun Ultra 5", and it uses an "UltraSPARC IIi" processor. (last I checked, Sun was on the UltraSPARC III, and planning the UltraSPARC IV)
No, you didn't make a mistake. The SS5 is a sun4m class machine. The mbus is implicitly built into the machine's architecture. Sure, it doesn't have a physical MBUS "slot", but it is a sun4m machine.
That *IS* the framebuffer you're talking about. However, text on the framebuffer console is drawn with Forth code from the OpenBoot PROM, and is slow. For the framebuffer console on a Sun to really be snappy, you need to be on a fast machine.
The interesting thing, however, is that modern Macs use OpenBoot as well. If you ever get the chance, try booting OpenBSD or NetBSD on a modern Mac. The console looks EXACTLY like on a Sun;) (same font and everything)
Though I wonder if the Sun Blade 100/150 is more of a PC than the Ultra 5, even if less of a sucky PC. The U5/U10 had a UPA slot for the framebuffer (though only usable in the U10 case), and I think they used proprietary memory.
That's another thing to keep in mind. Sun machines tend to prefer refresh rates of 66Hz or 76Hz. (not 70Hz or 75Hz) Also, Sun's "default" resolution is 1152x900, but that's easy to change. In any case, finding PC monitors that support good resolutions at 76Hz is much harder than finding those that do it at 75Hz.
That makes little sense, unless you didn't install a good framebuffer (graphics card) in the U10. The U5 only works with on-board or PCI framebuffers, while the U10 can take a UPA framebuffer (faster slot, think of it as "like" AGP for UltraSPARC). Of course the U5 and U10 technically use the same exact motherboard (with different PCI riser cards), but the U5's case isn't designed to let you install a UPA card.
Another very important thing to note. "13W3" isn't really a very standardized form of plug (beyond the "3" mini-coax connectors). I've seen 13W3 used in workstations by Sun, SGI, and IBM, and the pin-outs of the 13 normal pins are all just a tad different. Keep this in mind when you need to buy an adaptor for a system.
Yeah, that is one thing that really annoys me about the current approach to space travel. It is way too mission-oriented. Frankly, it doesn't make logical sense to build "craft X for mission Y" and "craft W for mission Z". It would make much more sense to make a multipurpose "Craft XYZ" that could perform missions Y, Z, Q, and R, either with different vehicles, maybe even on the same vehicle after some refueling and maintenence. (and yes, it would make sense for this craft to remain out in space for the whole time)
Actually, that is one thing I really loved about Babylon 5. "Earthforce" was the military, plain and simple. They didn't pretend to be anything else.
"Starfleet" really should be more military-like, but fails in a number of areas. They get the officer rank structure correct, but seem to totally neglect any structure of enlisted ranks. Also, they're always a tad too touchy-feely, and you rarely see the officers with the personality of a disiplined hard-ass with real command responsibilities.
In fact, the only time I truely liked the "image" of Starfleet was in the movies 2-6 (well, and part of 7) with the uniforms they were wearing, and the general imagery of the ship (especially in 2 and 6). I wished they had chosen to keep up that image a little better, but they went back to non-descript "jumpsuits" as the only starfleet uniforms, and no visible officer/enlisted distinctions beyond "pips".
It has nothing to do with the cost of the actual R&D. Remember, in developing new technologies, the hardest thing of all is the "idea" and a perceived "need". Sure, we could have developed all that stuff without Apollo, but either no one would have thought to develop them, or it would have taken MUCH longer to get around to doing so.
By setting goals for major projects well beyond what we are currently capable of, we find needs for technologies that we don't currently have. Thus, we have the funding and the motivation to go and develop them. Later in time, we realize that those technologies have applications outside of that major project.
Think about it this way... necessity is the mother of invention, plain and simple. Also, many have said that function follows form (often an argument used to justify huge feats of urban construction in the early 1900's). Put those two together, and it all makes sense.
Slashdot Mirror
Agreed.
Knowing assembly language gives you a far better understanding of "how" the processor actually WORKS. Now, while learning assembly out-of-the-blue often seems quite difficult and daunting, I think it makes more sense to learn in the context of a computer architecture course.
If you know how a processor actually functions, then assembly is just a natural way to codify instructions. If you don't understand how a processor works, then it may not make any sense.
It is also useful to learn how easy it can be, for simple code, to translate between C and assembly. This is especially useful for embedded development, where program size counts, processor power is limited, processor-specific features directly matter, and sometimes you have to deal with crappy, non-standard, compilers (and need to see if their output assembler is accessing memory in the way you intended, etc).
You've got some of the spirit right, but a lot of the details wrong. First, both Windows AND Linux run in "protected mode" (which I guess is the x86 term for "I'm using the MMU /w protected memory). In fact, any multitasking OS should do this.
Second, with protected memory, the OS does not intercept memory access. Can you imagine how slow this would be? Every memory access would require an interrupt, context switch, dozens to hundreds of instructions to handle, etc... Even if you don't count "instruction fetch" as a memory access in this sense (though it is one), it would still be totally pointless.
What actually happens, is that the OS tells the CPU's MMU (memory management unit) what memory the program is allowed to use (setting up virtual memory mappings, etc). All runtime memory access is managed directly by the CPU in this sense. The only time the OS gets involved, is if you have a page fault. (program tries too access memory address not in RAM, a page fault occurs, which tells the OS to go swap in that memory from disk)
Now how does the CPU know who is allowed to control the MMU, and all those other "protected" functions? Well, it has a mode flag. Basically, you have a "unprivileged mode"(app) and a "supervisor"(OS) mode. When in "unprivileged" mode, you cannot do anything bad. The only way to get into "supervisor" mode is to trigger an interrupt that is serviced by the OS.
In reality, I should hope Linux should be "more" restrictive (not less) in terms of what it lets you do. Multitasking without absolute memory and resource protection is just asking for fatal OS crashes and other bad things.
Yeah, it's fun being able to boast about all the big mean computer "stuff" you have. Well, at least until you get to the point where someone needs to be of similar "geek caliber" as you to even understand what it is you're boasting about.
Well, they never did make CISC SPARCstations, because the "SPARC" is a RISC processor. However, before developing SPARC, Sun did make workstations using Motorola 680XX chips.
In any case, often the chip doesn't actually execute 1 instruction per clock cycle. What it does do is pipelining, which means on average it may fetch one instruction per cycle, and complete one instruction per cycle, but they're usually not the same instruction (where an individual instruction takes several clocks to complete).
I would have to majorly disagree on your opinion of the learning curve. FreeBSD has a substantually smaller learning curve than Linux, for someone who wants to tinker with the system. It is much easier to figure out how everything works, where everything goes, and how to use all the system commands.
What most Linux distributions tend to do, isn't to ease the learning curve, but to circumvent it. They provide tons of nice and pretty user-friendly utilities (that work a lot of the time, but not all the time) to do anything. But if you want to go in and manually set things up, it is MUCH harder than in FreeBSD. The only Linux distro that comes close to the clean feeling of a FreeBSD install is Slackware. But Slackware is bare-bones and featureless, while FreeBSD is quite the opposite.
FreeBSD aims to make the easist and most useable system for people who know what they're doing. Most Linux distros try to make some user-friendly setup that doesn't cut it for newbies, and gets in the way of more experienced folk.
It really comes down to the average member of their respective user communities. Just listen to round-the-room introductions at a LUG and a BUG if you want to hear. Most BSD users are looking for a UNIX, many being sysadmins by trade (and generally aren't afraid of other 'nixes either). Most Linux users are looking for an "alternative" to something else.
(I know this isn't across the board, as I first installed Linux because I was looking for a PC-based UNIX and didn't know of anything else, though I did discover and move to FreeBSD a few years later)
Well I do live in Florida, and I see plenty of SUVs out there. However, I've found an interesting and annoying shift in the population SUV drivers.
Initially, all SUV drivers were male and complete assholes on the road. They certified this before allowing them to buy, it seemed. They were even REQUIRED to pass you under all circumstances, regardless of whether or not they actually wanted to go any faster after passing.
These days, I see a very large portion of SUV drivers being middle-aged women, who frankly act like road obstructions on the fast highways. As any large vehicle inhibits your view in a car, you either want them easily passable or just simply out of the way. These newer SUV drivers are just too annoying.
In any case, I see SUVs as a vehicle whose sole purpose is showing off or being a prick on the road. Think about it... If you need to carry lots of people, there are minivans. If you need to haul or tow crap, just buy a damn pickup truck. If you absolutely must do off-road, just get a damn Jeep or HumVee.
What really annoys me is how people with no real X exposure simply do not understand the advantages of this. The most irritating thing of all is that they don't know the very big and important differences between a "remote desktop" and a "remote application displaying locally".
Yeah, the underlying OS is more changable than most people think. When most people think "Linux", they're really thinking of a certain suite of userland software. Guess what? No one said you had to run Linux to use any of that. I have a desktop computer that uses KDE for the desktop, Evolution for E-Mail, Opera and Mozilla for the web, Gaim and X-Chat for chatting. What OS is it running? Solaris!
Now for x86, I often tend to lean towards FreeBSD. And guess what? Just about all that software also runs on FreeBSD, and it's actually very easy to get it all working.
With portability, however, I tend to prefer NetBSD as the "run on anything OS" (or OpenBSD, on the platforms it supports). I know Linux has a lot of ports, but those are just the kernel, often with little to back it up. With NetBSD, you get the "whole" system for most of the platforms on that very long list. Makes a great tinker OS for any random piece of computing hardware you may run across.
Running those same commands on my FreeBSD 4.9 server, I get the results: 60/6769/440
The *BSDs share so much code between each other, and most source files have ident tags from different *BSDs, that Apple could have mostly pulled from FreeBSD and may still produce the numbers you saw.
"Enterprise" market? Somehow, I'd think the Xserve still qualifies as an "edge" server. Now if Apple decides to come out with a 4-16 way server with hot-swappable system boards, then we'll be talking "enterprise" servers :-)
(of course they could, but it would be hard to justify the R&D given their current target market)
Here's the sad part about Sun framebuffers... I've got some SunRay units plugged into it, and guess what? When "scrolling in a web browser", and doing some other standard 2D GUI tasks, the SunRay is MUCH faster than the local framebuffer. (of course for video, or anything less "acceleratable", the reverse is true).
I dunno, but there must be a way. When the NetBSD or OpenBSD kernels boot, they do change the font to look exactly like on a Sun machine.
Right now the Elite3D m3 UPA framebuffer is beyond dirt-cheap on eBay (and the Creator3D isn't too shabby either). Upgrade :-)
It's not an "Ultra Sparc 5". "UltraSPARC" is the name of the processor, not the machine. The machine's official name is "Sun Ultra 5", and it uses an "UltraSPARC IIi" processor. (last I checked, Sun was on the UltraSPARC III, and planning the UltraSPARC IV)
No, you didn't make a mistake. The SS5 is a sun4m class machine. The mbus is implicitly built into the machine's architecture. Sure, it doesn't have a physical MBUS "slot", but it is a sun4m machine.
That *IS* the framebuffer you're talking about. However, text on the framebuffer console is drawn with Forth code from the OpenBoot PROM, and is slow. For the framebuffer console on a Sun to really be snappy, you need to be on a fast machine.
;) (same font and everything)
The interesting thing, however, is that modern Macs use OpenBoot as well. If you ever get the chance, try booting OpenBSD or NetBSD on a modern Mac. The console looks EXACTLY like on a Sun
Though I wonder if the Sun Blade 100/150 is more of a PC than the Ultra 5, even if less of a sucky PC. The U5/U10 had a UPA slot for the framebuffer (though only usable in the U10 case), and I think they used proprietary memory.
That's another thing to keep in mind. Sun machines tend to prefer refresh rates of 66Hz or 76Hz. (not 70Hz or 75Hz) Also, Sun's "default" resolution is 1152x900, but that's easy to change. In any case, finding PC monitors that support good resolutions at 76Hz is much harder than finding those that do it at 75Hz.
That makes little sense, unless you didn't install a good framebuffer (graphics card) in the U10. The U5 only works with on-board or PCI framebuffers, while the U10 can take a UPA framebuffer (faster slot, think of it as "like" AGP for UltraSPARC). Of course the U5 and U10 technically use the same exact motherboard (with different PCI riser cards), but the U5's case isn't designed to let you install a UPA card.
Another very important thing to note. "13W3" isn't really a very standardized form of plug (beyond the "3" mini-coax connectors). I've seen 13W3 used in workstations by Sun, SGI, and IBM, and the pin-outs of the 13 normal pins are all just a tad different. Keep this in mind when you need to buy an adaptor for a system.
Actually, the SS5 runs OpenBSD really well, and works wonderfully as a firewall/network-edge box as such.
Yeah, that is one thing that really annoys me about the current approach to space travel. It is way too mission-oriented. Frankly, it doesn't make logical sense to build "craft X for mission Y" and "craft W for mission Z". It would make much more sense to make a multipurpose "Craft XYZ" that could perform missions Y, Z, Q, and R, either with different vehicles, maybe even on the same vehicle after some refueling and maintenence. (and yes, it would make sense for this craft to remain out in space for the whole time)
Actually, that is one thing I really loved about Babylon 5. "Earthforce" was the military, plain and simple. They didn't pretend to be anything else.
"Starfleet" really should be more military-like, but fails in a number of areas. They get the officer rank structure correct, but seem to totally neglect any structure of enlisted ranks. Also, they're always a tad too touchy-feely, and you rarely see the officers with the personality of a disiplined hard-ass with real command responsibilities.
In fact, the only time I truely liked the "image" of Starfleet was in the movies 2-6 (well, and part of 7) with the uniforms they were wearing, and the general imagery of the ship (especially in 2 and 6). I wished they had chosen to keep up that image a little better, but they went back to non-descript "jumpsuits" as the only starfleet uniforms, and no visible officer/enlisted distinctions beyond "pips".
What really annoys me is the R&D process so many modern large companies seem to have adopted:
1. Wait for small startup to develop innovative idea
2. Buy out the small startup
3. Produce product with new technology
It has nothing to do with the cost of the actual R&D. Remember, in developing new technologies, the hardest thing of all is the "idea" and a perceived "need". Sure, we could have developed all that stuff without Apollo, but either no one would have thought to develop them, or it would have taken MUCH longer to get around to doing so.
By setting goals for major projects well beyond what we are currently capable of, we find needs for technologies that we don't currently have. Thus, we have the funding and the motivation to go and develop them. Later in time, we realize that those technologies have applications outside of that major project.
Think about it this way... necessity is the mother of invention, plain and simple. Also, many have said that function follows form (often an argument used to justify huge feats of urban construction in the early 1900's). Put those two together, and it all makes sense.