Baremetal and 16Gb system

[JulienDarc]

Hello,

I have a baremetal project on a machine with 16Gb of RAM on x86_64 with a intel i5.
Why the hell x86? Because the processing power available on this arch is needed.

I don't want any mmu, or paging or anything really. Minimal overhead. There will be only one program running bare metal.

BUT, I will need to address 16 Gb of memory.

How will I deal with this constraint? I can only address 1Mb of memory in real mode.

How-will-I-do-that...

Thanks

[Octocontrabass]

You can't access more than 4GB without paging. On a PC, this will be less than 4GB of RAM due to MMIO.

Use long mode. You'll be able to access all of your RAM, and you'll have extra registers to work with.

[JulienDarc]

I cannot deal with physical memory that large directly in long mode?

[Techel]

I cannot deal with physical memory that large directly in long mode?

Use long mode. You'll be able to access all of your RAM, and you'll have extra registers to work with.

I dont't understand.

[onlyonemac]

I cannot deal with physical memory that large directly in long mode?

Yes, actually you can.

[JulienDarc]

hoops, actually there is some typing gone.

My question was if it was possible to address that much ram without using mmu and paging, at all.
Octocontrabass answered it: no it isn't.

I ask because that would add a lot of code and create overhead (page walk, mmu, tlb) for a code that knows where to take its information (hardcoded).

I think that architecture is a mistake to start that project on.

Could you propose another arch that doesn't have this limitation (4Gb- ram)?
Maybe multiple arm64 processors could make it after all.. or not.

Edit:
multiple i5 in 32 bit mode is a waste of money..

[iansjack]

I cannot deal with physical memory that large directly in long mode?

Yes, actually you can.

No you can't. Paging is a pre-requisite for long mode.

[JulienDarc]

Forget that, that project, as-is, is wrong.

I will propose small 32bits embedded cpus (arm) and a new framework. The 16Gb will be dispatched among those "cheap" chips.

We even may see a thoughput increase all in all.

Thanks a lot

[Nable]

One can use large pages (several 2G mappings + a bunch of 4M + some 4k for I/O areas) + identity mapping. This leads you to zero (or very close to it) overhead of paging.

[Ready4Dis]

Yes, you will have almost no overhead if you do the paging properly and don't need to task switch and reload page tables... although it is extra code. I am not sure of something as powerful as an i5 that would meet your requirements. What exactly are your requirements?

[JulienDarc]

@Ready4Dis:
I need a high processing power for lot of data analysis(medical, audio).

i5 (haswell) is a very powerful beast that can grok the amount of data we plan to throw at it.

Yet, the system has to be amazingly simple (no real OS) to limit a possible bug.
The same logic will be used for real time system if the first implementation is OK, because the code is made very deterministic.

@Nable:
2G page? Isn't the limit on i5 1G for huge page? Or is there a -pleasing- trick?

[Nable]

Oops, of course it's 1G, not 2. Sorry for this mistake. But it doesn't change the idea.

[JulienDarc]

You are right, this would enable negligible overhead.

Thanks a lot

[Ready4Dis]

Not only is there very little overhead, but it can actually simplify things for you. You can take a non-contiguous memory map and make it appear flat, making things even simpler for the actual programming. Or move things like MMIO away from useable ram so there is less chance of accidentally overrunning into it, etc.

[bluemoon]

Yet, the system has to be amazingly simple (no real OS) to limit a possible bug.

I don't know why people thinks bare metal (ie. rolling their own mini-OS in form of exo-kernel) reduce bugs compare to adopt a mature OS.
Bare metal does not mean no OS, you still need code to manage hardware and resources, and that is not amazingly simple.

BTW, to access 16GB of memory you need to use long mode or PAE, and both require paging.