How similar is developing for the i686 in compared to developing for the i386?
I have been reading alot of stuff on developing for the i386 because I have one layin around collectin dust and thought since I'm just gettin started good it might be easier to start with it instead of todays computers but now I'm wonderin since I just noticed mine I'm currently on is a i686.
Similarities In Developing For i386 vs i686?
-
- Posts: 4
- Joined: Wed Jul 16, 2008 8:11 pm
Re: Rather stupid question . . .
Linux has you totally mis-interpreted. "i386" is just a "standard", that came up along with 80386 processors. Every x86 (that means, intel/amd compatible) is backwards compatible with 80386. Even a core 2 duo can run Windows 2.0 teoretically. That's because it's called "i386".
"i686" means just the same as "i386" but with newer opcodes, functions, modes etc. added.
"i686" means just the same as "i386" but with newer opcodes, functions, modes etc. added.
My web site: http://inflater.wz.cz (Slovak)
Derrick operating system: http://derrick.xf.cz (Slovak and English )
Derrick operating system: http://derrick.xf.cz (Slovak and English )
Re: Rather stupid question . . .
Developing for a 686 is nearly identical as developing for a 486. There were not many fundamental changes to the chip programming between the 486 and 686. But there were quite a few between the 386 and 486. The opcodes sets are nearly identical, but the virtual memory mechanism is completely different, AFAIK.
-
- Posts: 4
- Joined: Wed Jul 16, 2008 8:11 pm
Re: Similarities In Developing For i386 vs i686?
Ok so there will be some differences but not nerely as many as I would have thought. My only problem now is going from the DOS type setup to OSX which will prove to be fun.
Re: Similarities In Developing For i386 vs i686?
If i were you, i'd go for i586 as a base for your code (as this is widely supported - Pentium I, IIRC), then add in optimisations (that can be removed at compile time, using a define or whatever) for the i686 (Pentium II onwards). Especially if this is for OS development, as many people use older computers for testing.
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: Similarities In Developing For i386 vs i686?
The biggest differences in x86 generations from the software viewpoint are from 286 to 386, 386 to 486, then a leap up to the introduction of long mode.
the 386 mainly introduced paging, 32 bit modes, and a less-of-a-hassle FPU. 32-bit mode rocked.
The 486 introduced caches and their management (most importantly, the management of TLBs), multiprocessor support, and complex atomic instructions. In total, you get INVLPG, (WB)INVD, XADD, CMPXCHG, and more. This solved a problem with the fact that you had to flush the entire TLB on a 386, it allowed for advanced synchronisation and provided primitives for wait free algorithms. For the first time, FPUs were built in and their exception handling improved. This rocked developers as the de-facto PC platform now supported the grunt of things they would learn at academy.
The 586 introduced a superscalar architecture, which was transparent to the programmer, vector instructions which were transparent to the OS, CPUID which was a good step into the future, but you could still detect processors the old fashioned way, and virtual mode extentions, which would mainly alleviate load of code that was already written. Developers were rocked by little more than the increase in speed.
The 686s changed to cisc-to-risc decoders and out of order execution. The pentium pro wasn't much more than the 586, only later generations added extra features such as PAE, PSE and SSE. The 686 didn't rock, because AMD came along
the 386 mainly introduced paging, 32 bit modes, and a less-of-a-hassle FPU. 32-bit mode rocked.
The 486 introduced caches and their management (most importantly, the management of TLBs), multiprocessor support, and complex atomic instructions. In total, you get INVLPG, (WB)INVD, XADD, CMPXCHG, and more. This solved a problem with the fact that you had to flush the entire TLB on a 386, it allowed for advanced synchronisation and provided primitives for wait free algorithms. For the first time, FPUs were built in and their exception handling improved. This rocked developers as the de-facto PC platform now supported the grunt of things they would learn at academy.
The 586 introduced a superscalar architecture, which was transparent to the programmer, vector instructions which were transparent to the OS, CPUID which was a good step into the future, but you could still detect processors the old fashioned way, and virtual mode extentions, which would mainly alleviate load of code that was already written. Developers were rocked by little more than the increase in speed.
The 686s changed to cisc-to-risc decoders and out of order execution. The pentium pro wasn't much more than the 586, only later generations added extra features such as PAE, PSE and SSE. The 686 didn't rock, because AMD came along