This is a tough nut to crack
This is a tough nut to crack
I followed a tutorial on the wiki on Babysteps part 1 for creating a basic bootcode in ASM, and after I had that success I decided that maybe it was time to move on to learning about actual systems architecture to grasp more Assembly. Unfortunately, everything is still heavy reading at the moment, and not sure where is a good idea to move forward. I'm very intelligent, but I learn best when I learn things my own way.
Sure, I am pretty confident in the basic stuff (binary and hex notations, obviously, and little things like the bootsector starting at 0x07c0, or some hex number like that), but all I seem to be doing is running around in circles and viewing the same web pages over and over again, it's not helping me.
I know I need to be able to figure stuff on my own, but I'm just getting burned out. I feel how you guys must feel.
Sure, I am pretty confident in the basic stuff (binary and hex notations, obviously, and little things like the bootsector starting at 0x07c0, or some hex number like that), but all I seem to be doing is running around in circles and viewing the same web pages over and over again, it's not helping me.
I know I need to be able to figure stuff on my own, but I'm just getting burned out. I feel how you guys must feel.
Re: This is a tough nut to crack
Yes it's easy to get frustrated when things don't just work on the first try. There are threads on here with suggestions and such, but one thing I would suggest is to stay within you comfort zone as much as possible. When making changes to your code, make one minor change at a time, and recompile and test that everything is still working like you expect. Change too many things, and you'll find yourself spending hours trying to fix an issue that turns out to be a side effect from an earlier issue that you didn't even notice until now.
Good luck. Just reading this site keeps me pretty motivated to keep going.
Good luck. Just reading this site keeps me pretty motivated to keep going.
Project: OZone
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Source: GitHub
Current Task: LIB/OBJ file support
"The more they overthink the plumbing, the easier it is to stop up the drain." - Montgomery Scott
Re: This is a tough nut to crack
What you're describing sound a lot like you're trying to understand the full theory of everything before you start to put it to use. There are some people who learn very well this way; there are some members of the Lowlevel community who used to help newbies (successfully) without actually having written a kernel of their own.
However, this might not be your learning style. I see that when you set yourself the goal "hello world bootloader", you completed it in a short time. Maybe what you need is learning by doing, setting yourself the next goal for your "OS" and then implementing it. For example, you could try to extend your bootloader so that the user can enter their name and it says "Hello <name>". And then as the next step, let the user enter two numbers and print the sum. Just take small steps and implement the next thing that you view as the logical extension of what you already have.
However, this might not be your learning style. I see that when you set yourself the goal "hello world bootloader", you completed it in a short time. Maybe what you need is learning by doing, setting yourself the next goal for your "OS" and then implementing it. For example, you could try to extend your bootloader so that the user can enter their name and it says "Hello <name>". And then as the next step, let the user enter two numbers and print the sum. Just take small steps and implement the next thing that you view as the logical extension of what you already have.
-
- Member
- Posts: 1146
- Joined: Sat Mar 01, 2014 2:59 pm
Re: This is a tough nut to crack
I think I'm a bit like that sometimes .Kevin wrote:there are some members of the Lowlevel community who used to help newbies (successfully) without actually having written a kernel of their own.
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.
Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing
Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing
Re: This is a tough nut to crack
I think I'm just having problems understanding the structure and how the operands work of x86 Assembly more than the individual instructions. I'm still trying to wrap my head around registers. I know they are supposed to be on-CPU memory stores, but what exactly is the difference between all of them? The concept for them being copied to other registers sounds weird and confusing too.
-
- Member
- Posts: 5513
- Joined: Mon Mar 25, 2013 7:01 pm
Re: This is a tough nut to crack
Which registers are confusing you? What copying are you talking about?
- Nutterts
- Member
- Posts: 159
- Joined: Wed Aug 05, 2015 5:33 pm
- Libera.chat IRC: Nutterts
- Location: Drenthe, Netherlands
Re: This is a tough nut to crack
You might find this to be of your liking. It gives step by step insight into how a computer system works by building (a simple) one from the ground up. It'll give you a guided taste into many different aspects of computer science. I especially think you'll like the hardware part and that you'll get allot of new insights out of it besides answering allot of the questions you seem to have.
As a bonus you could write a emulator for the cpu in that course and get some solid programming experience.
As a bonus you could write a emulator for the cpu in that course and get some solid programming experience.
"Always code as if the guy who ends up maintaining it will be a violent psychopath who knows where you live." - John F. Woods
Failed project: GoOS - https://github.com/nutterts/GoOS
Failed project: GoOS - https://github.com/nutterts/GoOS
Re: This is a tough nut to crack
I'll check this one out.
Re: This is a tough nut to crack
To have some information we need it to be perceptible. Until we can feel it the information doesn't exist. That's why machines have means of recording an information. Electrical machines (computers in particular) often use the electric potential level as a sign of "something is there" (an information about something). That's how computer's memory works. It sets one voltage level for the bit 0 (zero) and another level for the bit 1. But there's much more information in the world than one bit can hold. So, people invented bytes (8 bits), kilobytes, megabytes and so on. And every bit in those megabytes is one of the voltage levels - one level for 0 and another for 1.SeanMc wrote:I'm still trying to wrap my head around registers. I know they are supposed to be on-CPU memory stores, but what exactly is the difference between all of them? The concept for them being copied to other registers sounds weird and confusing too.
Next goes memory structure. If we have enough memory it doesn't mean the memory fulfills all our needs. One particular need is the speed with which the computer does it's job. When there is a lot of memory the time required to access it increases significantly. That's why people decided to create another piece of memory, but with another name - the registers. The registers are small pieces of memory and because of the size it is possible to place them somewhere near the computer's processor. If something is near the access speed is increased. So, the registers can be viewed as a "fast" memory. And all that they are needed for is the speed. Would there be no need for speed there would be no registers.
Next goes computer's job. The job is about calculations and sending results to a device, where people can see it. So, there's a need for sending information. To send an information we need a piece of hardware with the same voltage levels as the another piece has. It is just a copy of the voltage levels. When there's no copy - the information wasn't sent. But when the copy is there - we just have sent the information from one device to another. It applies to every piece of the computer electronics. Also it applies to the registers. If we ordered the processor to execute a move instruction (register to register) it means the processor just connected it's internal lines between two registers. If the move instruction involves memory then the process is more complicated and involves additional chips and somewhat tricky algorithms. That's why processor to memory communication is slow (if to keep it simple).
Next goes the need for register to register information movement. It's partially the hardware issue. Internal processor's lines connect registers with processor's calculation unit (arithmetic logic unit or ALU). But in the process of processor evolution there was time when not all registers were connected to the ALU and some operations were possible only for a particular register. It means if we have our information in the register it doesn't mean we actually can use it and just have to copy it to another register. But sometime we need the copy because of the algorithm involved. For example - to calculate a square of a number we need to multiply the number with itself, so, we have a need for another copy of the number.
Well, now it should be simple enough - there's just some voltage levels and they just represent our information. When we want to use our information we often have to copy it because of the need for speed or hardware issues or just because of the algorithm involved. And the best way for a processor to access the information is to read it from processor's registers. That's why we need to copy our bits (voltage levels) from one register to another.
My previous account (embryo) was accidentally deleted, so I have no chance but to use something new. But may be it was a good lesson about software reliability
Re: This is a tough nut to crack
You can think of registers as simple variables. The CPU can only work directly with these variables (registers).SeanMc wrote:I think I'm just having problems understanding the structure and how the operands work of x86 Assembly more than the individual instructions. I'm still trying to wrap my head around registers. I know they are supposed to be on-CPU memory stores, but what exactly is the difference between all of them? The concept for them being copied to other registers sounds weird and confusing too.
The CPU then needs a way to load values into these variables (registers). This looks like this:
Code: Select all
mov eax, [some_memory_address]
Code: Select all
mov [some_memory_address], eax
Code: Select all
mov ebx, eax
Re: This is a tough nut to crack
What you listed was already clear to me, except for the last part about the special purpose registers.
So does this mean with the non-special registers, I can use any value or address I want in them?
So does this mean with the non-special registers, I can use any value or address I want in them?
-
- Member
- Posts: 1146
- Joined: Sat Mar 01, 2014 2:59 pm
Re: This is a tough nut to crack
Yes. Or more accurately, you can put any value or address that you want in them.SeanMc wrote:So does this mean with the non-special registers, I can use any value or address I want in them?
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.
Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing
Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing
Re: This is a tough nut to crack
No.
Some of the special purpose registers cannot be written to directly. The most familiar examples would be the CS and EIP registers. Also note that although the other segment registers, the stack pointer, and the flags register are writeable putting random values into them is likely to crash the system. There are also control or error-reporting registers for which the same holds true.
Edit Oops - missed your qualification "non-special". You should still bear in mind that function-calling conventions mandate the use of particular registers. Also, some of the general-purpose registers have specific uses (e.g. the ECX register as a loop counter.)
Some of the special purpose registers cannot be written to directly. The most familiar examples would be the CS and EIP registers. Also note that although the other segment registers, the stack pointer, and the flags register are writeable putting random values into them is likely to crash the system. There are also control or error-reporting registers for which the same holds true.
Edit Oops - missed your qualification "non-special". You should still bear in mind that function-calling conventions mandate the use of particular registers. Also, some of the general-purpose registers have specific uses (e.g. the ECX register as a loop counter.)