questions

[gordonml]

hey. ive been gathering information about this subject for awhile. i have a reasonably complete os design on paper/in my head, and ill be attempting to start coding it soon. just some questions that i dont really get:

1. what is the A20 line anyway?

2. are far calls a lot more expensive than near ones?

my original design included segmentation, but i read somewhere that the x86-64 doesnt have it and you can acheive all the same stuff with pageing, so:

3. how can i acheive protection etc through paging? is it normal for each process to have its own page table?

4. if i dont use segmentation, how will programs know the offsets of their functions if the code isn't loaded at 0x00000000?

thank you very much
gordonml

[digo_rp]

lo man, I'll try to tell you what I know. isn't enough but, I think it helps you

1 - the A20 Line as the name sugest is in the physical address memory
by default is only 19 lines to get use after the processor reset.

2 - I don't think so, never that you can take care of it...

3 - don't know what "acheive" means, but, with paging you have bits on page_dir / page_table the User/Supervisor bit , to select the privilege level..

4 - using paging, the process think that they have the full power of computer. they doesn't know that is the virtual address, you have to map the physical address of each task/process to the virtual address 0.

sorry for my poor english, if I make some mistake guys please forgive me. and tell me the right.

[Da_Maestro]

digo_rp has it mostly right. I feel some elaboration is required though.

The A20 line is needed to maintain compatability with the 8086 in real mode. The 8086 only had 20 address lines (numbered 0-19) and any address over 1Mb wraps around to the first 64k. A lot of old DOS programs made use of that when accessing the BIOS memory structures at the begining of memory. Enabling the A20 line effecively gives you access to the rest of the memory above 1Mb (well it's more complicated than that but you get the point. Just enable it and you'll be set).

Segmentation is in the past. The only far calls you should need to worry about are calls in x86-32 mode, and that's only when handling interrupts.

Yes use the page table user/supervisor bit to achieve protection.

There is three ways of making sure programs can be located anywhere in memory:
1. Use paging as described by digo_rp
2. Use relative addressing.
3. Dynamic linking

Relative addressing is when significant memory addresses are accessed by adding a constant to the instruction pointer. Simply put, if you keep the data and the code at the same relative position, you can locate it anywhere in memory and the program will still work.

Dynamic linking is where the software makes use of relative addressing to index into a table, and the addresses in the table are used to locate variables in memory. The table is built by the operating system when the program is loaded and when all the memory is allocated.

In most cases, relative addressing is done automatically by your compiler, so if you have a program image, load it straight into memory and jump to the entry point. Try to avoid using explicit absolute addresses (ie. give everything a name and let the linker allocate all the memory, rather than specifying all the addresses explicitly).

[gordonml]

thanks, that helps a lot

im actually writing my own compiler at the moment, for the challenge, but i know how to code relative addresses in assembler.

thanks,
gordonml

[Da_Maestro]

Cool a compiler.

You might want to google up some stuff about reverse polish notation. There is some excellent stuff you can do with that and with functional languages such as C.

I've been interested in building a compiler for a while...may I see some of the code that you've created so far?

[carbonBased]

I've also done some work on a compiler... it's rough, but will compile a fair ammount of syntax into assembly language.

You can find the source at http://neuraldk.org/product-InCode.

I haven't worked on it for some time, as I've been focussing on OSDev. However, considering I will soon have a new release of my OS, I may switch back to working on the compiler again for a while. There are some areas which are in dire need of attention.

My compiler, essentially, consists of a tokenizer, a module that reorders tokens (in reverse-polish, for the most part), and a module that takes that reordered stream of tokens, and outputs assembly language.

The process is fairly straightforward, but the code, I fear, may not be in some places (as noted, this is my first attempt at a compiler). I'd definitly like to rework some portions and add more comments.

Cheers,
Jeff

[gordonml]

uh... you really dont wanna see my code. im only 16, and entirely self-taught, it probably isnt that great... and there isnt a single comment in it anywhere i dont think.

it doesnt actually do anything yet, still in the initial development stages. im writing it in 3 parts, that frontend, which defines the language, the middle which just stores a kind of abstract syntax tree, and im currently writing the backend for ia32. i had a compiler that worked for very simple operations a few weeks ago, but it was kinda bad and a total cludge so i rewrote it entirely, apart from the tokenizer.

if you're still interested, give me awhile to stick comments in lol. its all in C#.

gordonml