OSDev.org

Funny how x86 has no bit endianness and it's "compatible with existing file formats" and it can be "emulated efficiently".

mnovotny wrote:Funny how x86 has no bit endianness

mnovotny wrote:and it can be "emulated efficiently".

There goes the discussion.

mnovotny wrote:There goes the discussion.

the discussion stays where it was, but if x86 specification would have no bit endianness, there would be no common bootable os on x86.

(also emulating one x86 instruction is like 70-100 clock, i would not call it efficient)

So if I have value 0x80 in al register and store it in memory, which bit gets stored first and which goes last? How are the bits stored on disk?

read the posts before - we alreday discussed that.

So this?

7 6 5 4 3 2 1 0

That means that 0x80 which is 10000000 would be stored one first and then zeroes?

i think yes, this is possibly the correct internal bit order.
after all, >>1 would divide it with 2.

Geri, mate, I think you're confused. Mnovotny almost nailed it on the head a few posts back when he wrote:

Unless you can address individual bits then it doesn't make sense to talk about bit level endianness. x86 has bytes as smallest addressable units of storage so talking about the order of bits in a byte on x86 is irrelevant.

I write almost because of instructions like BSF and BSR. The result of executing these instructions will depend on the bit numbering convention used by the machine designer. I personally wouldn't call this endianness but somebody else might and I don't think they would be that wrong to do so as we're so used to the idea of bit patterns denoting integers.

Where mnovotny does hit the bull's eye is with:

Bit level endianness is really only relevant in serial data transfer.

This has been my experience as well.

no, at this moment i now know how it actually works, why its bad, and how to implement it, what hack i will need in the emulator. (and i know what the others dont understand, why they dont, but i am too lazy to explain it more, and its also offtopic.)

near to compile the first working binary.

milestone1:

executable binary (including header) compiled (features endless cycle with goto in void main)

i wanted to have this before end of 2013, thank for god, i was able to do it

speed bencmkared later.

emulation is 10 clock per op (including endian conversion)

emulation optimized to 9 clock (relying more heavily on superscalar design of x86)

this conception is flawed, and i was wrong. i am considering to do the folowing modifications:

-i now think that clock based interruptions are wrong. there is no needed for hardware scheduling at all. having clock, or instruction counter, having the ability to break execution is basically have a lot of larger transistor demand than the subleq part of the cpu at all!

-having hardware scheduling, process descriptor table pointers makes the operating system to be more buggy and complex for no reason.

-the 4 operand conception (ABCD) is wrong, and if we dont need real multiple processes to run, we can skip D, and just use a special memory area that actually stores EIP. with this, the cpu core almost can decrased by another 30-40%.

-these modifications enable large boost in speed, due to less cache demand, less memory demand. emulation also can be faster.

-no need for having individual data sets for each thread, very very effective performance boost.

this decrases the cpu core by more than 75%

-> drawbacks: no real processes - the softwares must run in an emulator, as bytecode.
at first look, people would say that this would cause a 80-90% speed drop.
but lets investigate it:
-the emulation is clearly slower than having real processes, but due to the lower memory demand and easyer cpu design, we would have very large speed-up generally, which helps to incrase ipc.
-having hardware timer/counter interruption decrases the system performance aniway, and that, like this, we do not need to do
-by running the user-mode apps in an emulator, we can just use the operating system's library to do things like multipication for us, so we dont have to run the applications in subleq bytecode at all if we dont want to, decrasing the emulation overhead
-by having lot of smaller cpu cores and caches, we can have much more cpu core
-so basically, with emulation, skipping hardware process assistance and skipping D, we actually can do faster, simplier, and cheaper system.