User talk:Markhobley

Hi,

I've seen several links to your homepage appear last night, and it shocked me how much omissions, inaccuracies, and sometimes blatant propaganda are within the relatively small content. Since it's not part of the wiki, I can't edit it, although at some points it is used as if it were part of the wiki. In the current state, I do plan on removing some, if not all, of the links as they add little to the existing wiki contents.

Some things:

• (propaganda) Restricting yourself to 386 instructions is a choice. However, there are numerous design issues with that chip that make code (especially OS code) for it rather inefficient. Selecting a later architecture as a base (most commonly, the 486 or pentium pro) can improve your code while only wasting those chips that you "should not even be using anymore".

Why should we not be using these chips? They are already installed on our computers, and I haven't seen a free upgrade programme anywhere.

I actually use the maths coprocessor instructions (on the 487). The reason for locking the architecture is due to bugs in the Linux kernel.

• In your list of features, the most notable extensions are missing: MMX and SSE.

Yeah, I intend to support the Intel Pentium 120, which does not provide either of these extensions. It is best not to embed them into the kernel, but add them to a loadable module that can be added on demand.

I have now drafted a policy for Matrix Maths Extensions as follows:

It is permissible to use Matrix Maths Extensions in a dedicated loadable module, however this policy requires that an emulation module is provided to enable deployment of software on computers that do not have the capability of using Matrix Maths Extensions.

Recommended modules names

   * mmx - for a computer that is capable of utilizing Matrix Maths Extensions
   * mmxemu - An emulator module for use on computers that are not capable of using Matrix Maths Extensions

Instruction Sets

The mmxemu emulator module must comply with the IA32 instruction set policy, and should be build with a target arch of i486 or lower.

The mmx module should be build with a target arch of i586MMX, and should not contain processor supplementary instructions that are not available on the Intel Pentium MMX processor. Note that the consistent deployment principle still applies, and it is not permissible to use cpuid instructions within the mmx module.

• (inaccuracy) Intel did not "allow" others to use the instruction set. It's forced by legislation. Also AMD is known to have probed/reverse engineered Intel processors to learn more about it.

What legislation was that? I read that AMD produced these under licence from Intel, but I will research this.

Ok, I have now reworded the glossary to read Intel and other vendors both decided to utilize the IA32 instruction set on the processors that they produced.

• (propaganda) using CPUID to enable processor-specific code is a deliberate action, and not bad design. Even intel considers it the way to use such features.

You can use the features, but they will break backward compatibility of the code when it is run on existing processors for the purposes of forcing people to upgrade. I still say it is a bad design. Only one branch of the code will ever run on the machine, so other branches are redundant.

propaganda bordering on BS. Any newer intel, or AMD, or Cyrix processor has all the features of older processors for backwards compatibility.

Indeed, but running these instructions on an older processor will not work - Try it if you do not believe me!!!!

Also, not all users are 1337 like us to compile their software specifically for their target. Most likely your grandma would benefit from having both versions in the same package.

Surely the installer program can decide what version to install, we do not need both sets of instructions in the same binaries.

Instruction sets should be decided at compile time, not at run time IMHO.

• (inaccuracy) The linux kernel has configuration options which say for what host it should be configured.

It does not work. I build and test on my AMD K7, using 486 architecture options. I then copy files to the Intel Pentium 120, the AMD K5and the Cyrix machines, and the systems crash with a Bug Int 6 error, due to invalid instructions being used on those architectures. I looked at the kernel code, and found those instructions embedded there, either though I chose an architecture which does not include them.

it helps if you stop compiling with a i686 toolchain...

• (inaccuracy) GNU tools (and any tool based on automake and friends) allow configuration for different hosts, including different architectures. You can look at the GCC crosscompiler tutorial to see how this works.

Again the gnu assembler includes cpuid on the 486 instruction set, even though not all 486 processors have this, and there is no option to restrict the build to IA32 instructions. I have had to edit the instruction table to remove this instruction.

Relevance?

• (omission) You can compile the same code with different optimisations, which would result in the same behaviour (provided the code itself not broken), but while taking advantage of the target platform.

Indeed. That is the way to go! Do not stick extended instructions into binary files for use on machines that do not use them.

I have patched the uname command to try to trick the build system into thinking it is on a 386.

There is however a bug in glibc which contains some instructions that I am not familiar with, and neither are my processors.

Mark.

Sincerely - Combuster 06:42, 6 January 2010 (UTC)

I might add that most of your semi-valid reasons are related to GNU software, and thus are totally irrelevant for hobby OS development. - Combuster 06:42, 7 January 2010 (UTC)

A developer may not want to make the same mistakes. I am currently expanding those articles, which will contain realistic examples of the problems above, with the faulty code disected. I am not against additional instructions on higher architecture, but I still believe in compile time decision making. and adding extended features via modules. I hope that the K486 fork will address these issues.

Factual Errors and Propaganda

I, too, am concerned about the factual errors and propaganda exhibited in the linked site. I will be monitoring the links and they will be removed if necessary.

• Regarding Intel "Allowing" others to use the x86 instruction set, see Wikipedia.

CPUID is a perfectly valid way to detect processor features. I suppose the compiler is allowed to implement CPUID to determine how to optimise?

On your site, it is stated as fact and not opinion that the use of CPUID is bad practice.

• This page is largely personal opinion. You are welcome to that on your own site but not on pages linked by a factual wiki. "Educating" aspiring os devvers not to use SYSCALL/SYSENTER is not good.

Again syscall and sysenter do not work on the following IA32 compatible processors:

Intel Pentium AMD K5 AMD K6 Cyrix 686

Yes, more modern instructions like SYSENTER/SYSCALL do not work on these processors, but you can always make your kernel accommodate that by using SYSENTER/SYSCALL when you available, while also providing an interrupt as backup (by having handling code in your system call library that checks if SYSCALL/SYSENTER can be used).

It would be better do determine this at COMPILE TIME, or using different modules on different machines. It is not good design to embed sysenter and syscall instructions into IA32 programs, because some machines cannot use them.

User:Markhobley 17:22, 8 January 2010 (UTC)

This is a matter of opinion, that is the crux of our argument, your views are being presented as fact, when they are actually just your personal opinion. In my opinion it is better to have a kernel that can work on any machine that has protected mode but can use the newer features if they are available.

(Also, can you please treat this page more like a thread on the forums, it's supposed to read like a discussion, so please tag your comments using ~~~~)

Thepowersgang 02:42, 9 January 2010 (UTC)

I actually say, these features can be implemented as loadable modules on machines that support them, although this information has not been fully written up yet - Mark.

What [com]buster is saying, is that you are not differentiating between your personal opinion and fact. The idea of this wiki is to inform aspiring OS developers on what they can do, and how it can be done. We do not want to colour that any more than it already is. I move that the links be taken off the wiki for the time being, until the content is changed.

Thepowersgang 15:22, 8 January 2010 (UTC)

• I agree with Combuster that code that behaves differently with different optimisations is poorly written code.

- It was actually me that said that. Mark.

Scope

Also, the scope of the article is limited to IA32 related builds. If the target build arch is [i686] or higher, then the articles on my website may not be applicable to those, because my own website is limited in scope to IA32, which is the platform that I currently support.

It is however expected that a build for [i386], [i486] and [i586] run on all IA32 compatible machines, and stick to the IA32 instruction set, and do not include [cpuid] branches.

I could bash more of your arguments and take this offtopic further. However we can safely say that the majority considers references to your site inappropriate, and I'll leave it at that. Please do not link to them, they will be removed. - Combuster 11:15, 10 January 2010 (UTC)