* Basic digital logic circuits built from transistors, diodes and capacitors. The various logic gates, a DRAM cell and an SRAM cell, maybe a simple adder too. (self-nominated
i'd love it if you explained this
[editline]9th January 2011[/editline]
of course if your hands are still recovering from such stress please do take a break.
[editline]9th January 2011[/editline]
though.
God damn RAM. :argh:
Hopefully those overclocker types stop being so crazy about overclocking now.
[editline]10th January 2011[/editline]
[QUOTE=ButtsexV2;27250368]my system for hiding porn is ~/porn[/QUOTE]
I keep mine on an external drive; I live dangerously.
It's formatted with XFS though, and since everyone in my house uses Windows it's practically encrypted.
I can give you the fastest and best way to hide porn!
[url]http://fiddyp.co.uk/how-to-hide-a-rar-in-a-jpeg-file/[/url] (Works with .png's and should work with .mp3 too)
Yeah that's pretty much it, simple isn't it?
You can then open the picture with winrar, or 7zip or any kind of unrarer and add to archive, or extract from it. You may as well make it a passworded rar if you like, but it won't be needed - I guarantee you.
The technique saved me countless times as my external disk where I have porn has visited many computers of friends, and they like to search through files trying to catch me red-handed. (And they never found what they were looking for, aka my stash :smug:)
[QUOTE=Ritave;27323047]I can give you the fastest and best way to hide porn!
[url]http://fiddyp.co.uk/how-to-hide-a-rar-in-a-jpeg-file/[/url] (Works with .png's and should work with .mp3 too)
Yeah that's pretty much it, simple isn't it?
You can then open the picture with winrar, or 7zip or any kind of unrarer and add to archive, or extract from it. You may as well make it a passworded rar if you like, but it won't be needed - I guarantee you.
The technique saved me countless times as my external disk where I have porn has visited many computers of friends, and they like to search through files trying to catch me red-handed. (And they never found what they were looking for, aka my stash :smug:)[/QUOTE]
But then you have to uncompress it every single time you want to porn :saddowns:
I hated having to learn this in my intro to programming, yes it is interesting, but no it will not help me day-to-day in my job functions
[QUOTE=JohnEdwards;27324250]it will not help me day-to-day in my job functions[/QUOTE]
Isn't that, like, all of high school in general?
I understand now why we need faster ram! before I just thought it would help programs load faster, and nothing else, This was truely fascinating. I read it all. Do Kernels next.
[editline]11th January 2011[/editline]
[QUOTE=MacTrekkie;27323996]But then you have to uncompress it every single time you want to porn :saddowns:[/QUOTE]
Have you read how gman watches his porn? It's nothing compared to that.
[QUOTE=MacTrekkie;27323996]But then you have to uncompress it every single time you want to porn :saddowns:[/QUOTE]
And re-compress it every time you add more porn.
[QUOTE=gman003-main;27249057]Basic digital logic circuits built from transistors, diodes and capacitors. The various logic gates, a DRAM cell and an SRAM cell, maybe a simple adder too. (self-nominated)[/QUOTE]
Please do this, I've been trying to wrap my head around this sort of stuff for a while but I haven't found anything that explains it well. Yet.
1. It's better to explain with a RISC architecture, since x86 is a disaster.
2. This is still all software-level stuff. Saying "This is how a CPU works" and writing out some assembly code is like saying "This is how a car works -- you grab this wheel here and push on that pedal there."
[QUOTE=Zeke129;27201209]Make a version of this that's readable by computer illiterate people.[/QUOTE]
As many car analogies as possible pls
[editline]2nd May 2011[/editline]
[QUOTE=ROBO_DONUT;29561091]1. It's better to explain with a RISC architecture, since x86 is a disaster.
2. This is still all software-level stuff. Saying "This is how a CPU works" and writing out some assembly code is like saying "This is how a car works -- you grab this wheel here and push on that pedal there."[/QUOTE]
thanks
I can't understand anything you're saying and I feel stupid :(. I wanted to go to college for computer programming, but I'm in my junior year and at the beggining of the year I was having some trouble with chemistry, but getting by just enough. Then I moved to North Carolina "permentantly". Did not take Chemistry there as they only take 4 classes a semester. So three months of that bullshit and I move back and they put me in with the same schedule as I had A's in everything else all year, I could pass with doing no work and getting a zero on my final even, but Chemistry is another story that shit is so god damn hard and there's only like 4 weeks of school left so its raping my GPA man now I have to go to community college:(
[QUOTE=ROBO_DONUT;29561091]1. It's better to explain with a RISC architecture, since x86 is a disaster.
2. This is still all software-level stuff. Saying "This is how a CPU works" and writing out some assembly code is like saying "This is how a car works -- you grab this wheel here and push on that pedal there."[/QUOTE]
1. But x86 is what 99.999% of us use on our desktops, so it's relevant. And CISC assembly is usually easier to explain than RISC.
2. Yeah, I realize it's mostly software-level stuff. I originally intended to make it much, much more involved, translating the assembly into micro-ops, then going through all the stages of the pipeline. After just writing that much, though, I realized I had already achieved "Ludicrous Detail", and was too tired to continue.
I'm still planning to make a "sequel" thread, going over basic electronics - transistors, AND/OR/XOR/NOR/NXOR/NAND gates, and capping it off with a DRAM and SRAM cell - but it may be some time before I get to that, as I'm rather busy with Project Horizon right now.
That wooshing sound you heard was air rushing over my head.
I shudder at the sight of assembly language.
[QUOTE=gman003-main;29572821]1. But x86 is what 99.999% of us use on our desktops, so it's relevant. And CISC assembly is usually easier to explain than RISC.[/QUOTE]
I see your point, but the key phrase there is "on our [i]desktops[/i]". Think of all the smartphones and tablets out these days. They're all RISC. Desktop computing is on the decline because no reasonable human being wants to be glued to a desk all day. Programmers are finally being forced to think about portability, and I'm sure if this trend continues we could see x86 being replaced soon enough (after all, the only thing it has going for it is momentum and codebase).
Also, I was personally thinking more about the hardware level than pipelining, but that's just me, I'm a hardware kind of guy.
Regardless of my criticism, it's a damn good post.
[QUOTE=gman003-main;29572821]I'm still planning to make a "sequel" thread, going over basic electronics - transistors, AND/OR/XOR/NOR/NXOR/NAND gates, and capping it off with a DRAM and SRAM cell - but it may be some time before I get to that, as I'm rather busy with Project Horizon right now.[/QUOTE]
If/when you do this, be sure to cover two's compliment arithmetic, half-adders, and flip-flops :)
[QUOTE=gman003-main;27200580]If your head isn't hurting a bit after reading this, I did not go into enough detail.[/QUOTE]
If you're head isn't hurting after this you don't understand.
[editline]3rd May 2011[/editline]
But still NNNNNNNYYYYYAGGGGGGHHH
[editline]3rd May 2011[/editline]
Where is the next one, Gman, I wish to know how to hide my porn better.
Your example isn't x86-64, it's regular x86 with MMX/SSE. You should make an example that doesn't use any special registers from extended instruction sets because not all CPUs have them. It is possible to do that math with x86 (without the FPU also.)
[QUOTE=gman003-main;29572821]1. But x86 is what 99.999% of us use on our desktops, so it's relevant. And CISC assembly is usually easier to explain than RISC.
2. Yeah, I realize it's mostly software-level stuff. I originally intended to make it much, much more involved, translating the assembly into micro-ops, then going through all the stages of the pipeline. After just writing that much, though, I realized I had already achieved "Ludicrous Detail", and was too tired to continue.
I'm still planning to make a "sequel" thread, going over basic electronics - transistors, AND/OR/XOR/NOR/NXOR/NAND gates, and capping it off with a DRAM and SRAM cell - but it may be some time before I get to that, as I'm rather busy with Project Horizon right now.[/QUOTE]
??? How is CISC easier than RISC? I don't even know where to begin with the train wreck of x86-16/32/64. You have hundreds if not thousands of different instructions, of which not every CPU model has the same instruction set, and instructions are even executed differently between manufacturers. Tons of instructions do the exact same thing as other instructions, leading to lots of redundancy, and big problems when it comes to sloppy/unoptimized code.
Then you have the assbackwards segmented memory and registers, a gift from the 70's that keeps on giving, kind of like AIDS.
RISC is so much easier to program on. You don't need a 1,500 page book explaining 35 years of backwards compatibility. You have a small base of instructions that you perform lots of small operations with and use loops to accomplish bigger things. Even though the 680x0 isn't technically a RISC CPU, the instructions are RISC-like enough to make it a dream to program on, accompanied by the flat linear memory map. PowerPC is even better.
[QUOTE=gman003-main;27249057]* Basic digital logic circuits built from transistors, diodes and capacitors. The various logic gates, a DRAM cell and an SRAM cell, maybe a simple adder too. (self-nominated)[/QUOTE]
Who uses diodes for logic gates nowadays? You can't even chain them that way.
[QUOTE=bohb;29590398]Your example isn't x86-64, it's regular x86 with MMX/SSE. You should make an example that doesn't use any special registers from extended instruction sets because not all CPUs have them. It is possible to do that math with x86 (without the FPU also.)
??? How is CISC easier than RISC? I don't even know where to begin with the train wreck of x86-16/32/64. You have hundreds if not thousands of different instructions, of which not every CPU model has the same instruction set, and instructions are even executed differently between manufacturers. Tons of instructions do the exact same thing as other instructions, leading to lots of redundancy, and big problems when it comes to sloppy/unoptimized code.
Then you have the assbackwards segmented memory and registers, a gift from the 70's that keeps on giving, kind of like AIDS.
RISC is so much easier to program on. You don't need a 1,500 page book explaining 35 years of backwards compatibility. You have a small base of instructions that you perform lots of small operations with and use loops to accomplish bigger things. Even though the 680x0 isn't technically a RISC CPU, the instructions are RISC-like enough to make it a dream to program on, accompanied by the flat linear memory map. PowerPC is even better.[/QUOTE]
First off, I was deliberately using certain extensions needlessly in order to cover more ground. Besides, you can safely assume everyone has SSE3 - SHS shows 98% coverage for that extension (that's more than have NTFS or Flash available).
Second, a well-designed CISC set is far easier to write programs in than a RISC set. Look at, say, VAX assembly - it's practically a high level language. Sure, x86 is a mess, but it's actually not that bad. You're also exaggerating how bad the multivendor problem is - almost all code will work the same on all processors (), and there's arguably more problems dealing with the legacy processors than dealing with modern incompatibilities.
While RISC is easier to understand how it works, it's also much harder on the programmer. I would NOT like to program raw RISC assembly - and if you're working on even a medium-level language, you don't care about the ISA anyways.
[QUOTE=gman003-main;29597289]Besides, you can safely assume everyone has SSE3 - SHS shows 98% coverage for that extension (that's more than have NTFS or Flash available).[/QUOTE]
Isn't SSE3 only on 64-bit CPUs? I know that all 64-bit x86 CPUs have SSE2 as the minimum, but I don't know if they made any 32-bit CPUs with SSE3.
If so, I didn't know 64-bit had hit 98% coverage already.
[QUOTE=PvtCupcakes;29599074]Isn't SSE3 only on 64-bit CPUs? I know that all 64-bit x86 CPUs have SSE2 as the minimum, but I don't know if they made any 32-bit CPUs with SSE3.
If so, I didn't know 64-bit had hit 98% coverage already.[/QUOTE]
SSE3 was introduced shortly before Intel adopted x86-64, so it was in multiple x86-32 CPUs. Additionally, AMD only introduced it in a later revision of the Athlon 64, so there are also x86-64 processors without SSE3.
Still, Intel started using it in 2004, and AMD caught up in 2005, so it takes a computer over 6 years old to not have SSE3. That's generally a reasonable assumption for most purposes - it would be like having Windows XP as the minimum requirement.
I [i]believe[/i] Chrome requires SSE3, but it might only need SSE2. I remember finding out that I couldn't run Chromium on my ancient Athlon 800 because of that.
[QUOTE=gman003-main;29599321]SSE3 was introduced shortly before Intel adopted x86-64, so it was in multiple x86-32 CPUs. Additionally, AMD only introduced it in a later revision of the Athlon 64, so there are also x86-64 processors without SSE3.
Still, Intel started using it in 2004, and AMD caught up in 2005, so it takes a computer over 6 years old to not have SSE3. That's generally a reasonable assumption for most purposes - it would be like having Windows XP as the minimum requirement.
I [i]believe[/i] Chrome requires SSE3, but it might only need SSE2. I remember finding out that I couldn't run Chromium on my ancient Athlon 800 because of that.[/QUOTE]
I've got three computers in my house that are at least 6 years old, all of which are still used frequently (as desktops, not servers or terminals or w/e). My current main computer is four years old, and I don't plan on upgrading anytime soon. Most of the computers I see in the office where I work are well over six years old.
I highly doubt that there's "98% coverage" for SSE3.
I'm fairly certain the socket 775 p4 in my semi-backup server has sse3
[QUOTE=ROBO_DONUT;29601499]I've got three computers in my house that are at least 6 years old, all of which are still used frequently (as desktops, not servers or terminals or w/e). My current main computer is four years old, and I don't plan on upgrading anytime soon. Most of the computers I see in the office where I work are well over six years old.
I highly doubt that there's "98% coverage" for SSE3. It's a very bad idea to assume people have it.[/QUOTE]
The 98% coverage was for gamers (source was Steam Hardware Survey).
Regardless, SSE3 is widespread enough that it's beneficial to use in speed-sensitive applications. Many wrapper libraries exist to let you call it directly from C, but will use alternate (slower) code if SSE3 is unavailable. I'm pretty sure pretty much every recent media player takes advantage of SSE3 that way.
that's from around 2004-05
Chrome works with my pentium m laptop I have and that does not have SSE3, so it must support SSE2.
This is a super-super-simplification. Buy some books on CPUs and come back when your already hurting heads are reduced to ash. :v:
[QUOTE=gman003-main;29597289]First off, I was deliberately using certain extensions needlessly in order to cover more ground. Besides, you can safely assume everyone has SSE3 - SHS shows 98% coverage for that extension (that's more than have NTFS or Flash available).
Second, a well-designed CISC set is far easier to write programs in than a RISC set. Look at, say, VAX assembly - it's practically a high level language. Sure, x86 is a mess, but it's actually not that bad. You're also exaggerating how bad the multivendor problem is - almost all code will work the same on all processors (), and there's arguably more problems dealing with the legacy processors than dealing with modern incompatibilities.
While RISC is easier to understand how it works, it's also much harder on the programmer. I would NOT like to program raw RISC assembly - and if you're working on even a medium-level language, you don't care about the ISA anyways.[/QUOTE]
Why are you using the steam hardware survey as a source for world computer spec data? That survey is highly biased towards gamers, which the majority of upgrades their equipment every few years.
It doesn't apply to the general population which can use the same computer for 10 years or more. The average age of computers I work on in my repair business are usually over 5-6 years old, and are sometimes 15 years old.
And if you're trying to introduce people to x86 assembly, you [I]generally[/I] want to start them out with the basics, not go off on advanced instruction sets and all of the complicated mess that goes with them.
I also fail to see the reason why RISC is harder on the programmer. Reduced instruction sets are the whole point to make it easier to program on a RISC CPU.
It's odd that superscalar execution's always just about implied throughout.
[editline]5th May 2011[/editline]
[QUOTE=bohb;29608605]I also fail to see the reason why RISC is harder on the programmer. Reduced instruction sets are the whole point to make it easier to program on a RISC CPU.[/QUOTE]
Debilitating lack of "what-the-hell-is-this-driving-at"-ness, I suppose. But the relationship between RISCness and conciseness isn't always linear (gman003 is *very* right to bring up the VAX - the PDP-11 instruction set is perfection, even though x86 is relative hell) - there's "basic and orthogonal", and then there's "we couldn't care more for xMUL and by the way I hope you enjoy function prologs and epilogs, because you'll spend a lot of time on them".
I never really thought much of ram timings (Aside from smaller = better), but from what I understand they correspond to how often the ram can be accessed, which is kind of neat I guess. I imagine the ram as a bus that only has one stop so it drives around the block occasionally.
Sorry, you need to Log In to post a reply to this thread.
