Linked by Thom Holwerda on Sat 15th Feb 2014 00:13 UTC, submitted by DeepThought
OSNews, Generic OSes

BareMetal OS now supports TCP/IP by way of a port of LwIP, originally by Adam Dunkels for embedded devices.

BareMetal is a 64-bit OS for x86-64 based computers. The OS is written entirely in Assembly, while applications can be written in Assembly or C/C++.

BareMetal boots via Pure64 and has a command line interface with the ability to load programs/data from a hard drive. Current plans for v0.7.0 call for basic TCP/IP support, improved file handling, as well as general bug fixes and optimizations.

Thread beginning with comment 583050
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Question
by bassbeast on Mon 17th Feb 2014 09:16 UTC in reply to "RE: Question"
bassbeast
Member since:
2007-11-11

That still doesn't explain my question which is WHY U NEED 64BITS IN ASM???????

In HPC yes, you use large datasets, in the other 2 contexts? You have Kolibri, Minix, FreeDOS, a whole bunch of choices that would seem better suited to the task.

Oh and Kochise really needs to take a Midol, just saying.

Reply Parent Score: 3

RE[3]: Question
by Kochise on Mon 17th Feb 2014 10:34 in reply to "RE[2]: Question"
Kochise Member since:
2006-03-03

If you want to use 64 bits in the higher level without context switching from 16/32 bits, better start the whole system to 64 bits and stay that way.

But this requires Rtfm and Stfu, not Midol...

Kochise

Reply Parent Score: 1

RE[3]: Question
by Alfman on Mon 17th Feb 2014 16:42 in reply to "RE[2]: Question"
Alfman Member since:
2011-01-28

bassbeast,

"That still doesn't explain my question which is WHY U NEED 64BITS IN ASM???????"

The question of bitsize (16/32/64) is orthogonal to the question of language (c/asm). The reason for using assembly on 64bit is the same as using it on 32bit or 16bit - direct access to the CPU. Whether asm is actually the best choice is debatable, however it is a separate factor from bit size.

As for bit size, there is absolutely no doubt that we want to use an OS with the same bit size as the application. Otherwise we end up an OS that cannot properly manage resources, system calls that have to be marshaled back through legacy CPU modes, indirection via specialized low memory buffers, much more difficult debugging, etc. This isn't a new problem, it's something 32bit developers had to deal with on dos, however now the problem is even worse because long mode (amd64) explicitly dropped support for vm86 as well as segmentation.


You have Kolibri, Minix, FreeDOS, a whole bunch of choices that would seem better suited to the task.


Since none are 64bit OSes, none of them are great choices for 64bit development.

Edit: I found this, a 64bit port of freedos. It's not clear that it ever got off the ground. Assuming they care to address backwards compatibility, they would need to support all the modes (16,32,64 bit), but that doesn't alleviate the incompatibilities between modes (ie how is a 64 bit app going to call a 16bit driver?). Dropping support for 16bit would be the easiest option, however that kills off one of the biggest uses cases of freedos for me today (flashing new firmware to hardware).


http://sourceforge.net/projects/dos64/

IMHO it's better to start with an OS that doesn't have a legacy problem.

Edited 2014-02-17 17:01 UTC

Reply Parent Score: 3

RE[3]: Question
by moondevil on Wed 19th Feb 2014 08:07 in reply to "RE[2]: Question"
moondevil Member since:
2005-07-08

That still doesn't explain my question which is WHY U NEED 64BITS IN ASM???????


Because x86 sucks in 16 and 32 bit mode.

In 64 bit mode you have lots of registers to play with and more instructions that aren't available in the other modes.

Is that good for you?

Reply Parent Score: 2