OSDev.org

[引用] After reviewing your IdealOS thread, I have determined a few things. First is that you have a major example of the Dunning Kruger effect. Second is that you don't have respect for more senior forum members. Putting aside the obvious technical foibles (as you do have a right to be wrong), you have 1) posted links to pirated software (i.e., the Windows NT link), 2) your dialog was borderline rude all the way throughout the thread, but becomes blatantly unacceptable in the linked post. Calling iansjack a "bad person", saying his "filthy essence", and saying "you will become an even worse person" is unacceptable behavior. Please change your attitude or I will lock the thread in question, and consider further action if this doesn't change.

I received an interesting notification from the administration. It turns out they doubt my competence. Well, let them try to prove it on the merits. Of course, I don't understand why I can be humiliated in my personal post, but I can't respond to it. There's no point in me posting code here anyway. This is a dump of possibly good projects, but not a space for creativity, this is well described in the FAQ. If the sophists win in my personal post, it will be a wonderful precedent. I will not allow anyone to humiliate me in any way, either directly or indirectly. This is an axiom. Especially in my own post.

For the sake of transparency, I sent the warning.

I hate dealing with issues in the view of others, but your warning has nothing to do with competence. It is simply because I wanted to remind you of the forum rules, which you have broken two of in this thread. Obviously iansjack hasn't dragged himself into a fight with you (thankfully), but I don't believe it sets a good precedent to let new members speak disrespectfully to senior forum members, and so I warned you.

"How did you do this?"
"It's very simple — you read the protocol and write the code." - Bill Joy
Projects: NexNix | libnex | nnpkg

[引用] Okay, then I'll continue to prove my point about Nasm.
Here I clearly show how Nasm creates a longer opcode for no reason

https://youtu.be/pOpN2ogCb90

I had to squint to make out a video that you could have just provided text for. You provided this example to prove your supremacy You then assembled with `nasm test.asm` . Then ran `ndisasm -b32 test` and got this: You declare this a NASM bug. I assume because you believe that these could have been encoded as the same 3 byte instruction. Well I hate to break it to you but your ignorance or incompetence of the x86 architecture is at fault. If you want to prove Dunning-Kruger applies to you, you are doing a wonderful job. I recommend you Read the Fucking Manual. The AMD or Intel architectural manuals will tell you the difference when EBP appears as a BASE REGISTER. When you find the part about the default segment get back to us.

Right now your assembler is crap because it has been programmed by someone who lacks an understanding in basic x86 design especially scale*index+base+displacement addressing. Even the competent 13-14 year old OS Developers on this forum already understand the difference.

What do I know though, you think I am just stupid.

[引用] The reason is explained in the NASM manual. This is not a bug. (And please don't post a video when text would have worked.)

But you said there were lots of bugs. What else have you found?

[引用]Yes, in particular Section 3.3. There is a single sentence that describes it and why.

[引用] As I understand it, you claim that there can be both ss and ds segments, here is an example of code in the emulator

https://github.com/sarah-walker-pcem/pc ... /386.c#L22

And at the same time you ignore the fact that this assembler is made specifically for my operating system, in which all segments are equal. And such an assembler can be useful to everyone who writes their own OS and does not want your name to appear there as a developer. Well, okay, not everyone can understand this. If you want bugs, then read the topic above, nasm generates short addresses in certain situations, but not in all. The justification by alignment will not work - there is no alignment there.

And share a link to your operating system, please.

[引用] A few lines down, here and here, you can see that the default segment changes to SS when EBP is the base register, but the default segment does not change when EBP is the index register.
[引用] NASM was made for every operating system, including operating systems where segments are not equal.
[引用] NASM providing a way to choose whether EBP is the base register or the index register is not a bug.

NASM is not designed to just output code for whatever you are targeting. It is intended to target a multitude of potential environments where SS and DS may not have the same base. If SS.base != DS.base then the segment chosen matters. The assembler doesn't know what environment it is running in. NASM will generally try to emit the instructions so that they follow any of the nuances of the CPU. The default segment is one of those.

NASM assumes an effective address (EA) is of the form disp[base+index*scale] (where some components can be omitted). `inc dword [eax+ebp]` is disp=0, base=eax, index=ebp, and scale=1. `inc dword [ebp+eax]` is disp=0, base=ebp, index=eax, and scale=1. The problem here is that if the CPU encounters a BASE with register ESP or EBP the Stack Segment is the default, not the Data Segment. Volume 1 of the Intel SDM section 3.7.5 provides this rule:

The uses of general-purpose registers as base or index components are restricted in the following manner:
• The ESP register cannot be used as an index register.
• When the ESP or EBP register is used as the base, the SS segment is the default segment. In all other cases,
the DS segment is the default segment.

The NASM documentation has documented this situation in Section 3.3:

NASM has a hinting mechanism which will cause [eax+ebx] and [ebx+eax] to generate different opcodes; this is occasionally useful because [esi+ebp] and [ebp+esi] have different default segment registers.

If EBP is the index then the default segment is DS. If EBP is the base then the default segment is SS. So to NASM it matters whether something may be the base or index in the effective address. Note: If you attempt to illegally use ESP as an index (with a scale of 1) NASM will swap and make ESP the base and the other register the index. An attempt to apply scale >1 to ESP is invalid and NASM will warn you.

You claimed that NASM has bugs. We don't know what the intentions of your own assembler are (unless you tell us) or if we actually knew the design of your OS which we don't. NASM producing a 3 byte instruction vs 4 byte is not about alignment in this case. It is about what default segment the CPU will use. When SS.base != DS.base then these are not equivalent from the CPU perspective:The first has EAX as the base so the default segment is DS. The second has EBP as the base so the default segment is SS. To get the first one to use SS as a segment like the second (rather than DS) you would have to explicitly specify SS with:The result would be a 4 byte encoding of 0x36, 0xFF, 0x04, 0x28.

Your assembler has no documentation and there is nothing saying what its expectations are. Your assembler as is would not be useful for encoding in environments where SS.base and DS.base are not the same which is often the case in 16-bit real and 16-bit protected mode. It is a deficiency in your assembler that doesn't make it generic. That is not how NASM was designed, as it is trying to be environmentally agnostic.

If you think that NASM is generating less than efficient instruction encodings it is far more likely that NASM understands the nuances of the x86 instruction encodings better than you do - and what you perceive to be a bug is actually by design. Most of the time NASM bugs are not related to basic instruction encodings. I found a bug in the Macho64 object metadata and it was eventually fixed by NASM developers.

The STRICT keyword in NASM can sometimes be used to generate a specific instruction encoding that may not been the default.

[引用] The main question here
[引用] Maybe it was my imagination, but in my opinion you are hostile towards teenagers.

[引用] That explains a lot. We should leave him alone now guys.

Teenagers are always free to make fools of themselves but, if I wasn’t involved, I would lock this thread now.