How about an OS with only an Assembly API?

[LieutenantHacker]

I can't think of many, besides maybe MenuetOS.

But I don't know if MenuetOS would count ... by "OS with only an Assembly API" I mean an operating system which possess an API only capable of executing specific output format executables that have been compiled specifically through Assembly syntax.

MenuetOS has had some work done to solve that.

I mean has anyone ever developed a sort of application framework only for Assembly language support, no HLL like C, C++, D, Java, etc.

What I mean is ALL Assembly, from the kernel to the frameworks to middleware, to the application software support, any runtimes, system software, and device drivers. I am sure it would be one potentially fast responding system as well.

I was wondering what the approach on this would be in some of your opinions, because I have FASM, a specialized toolchain, and my own output format specification ready to fire up some parts of my kernel as soon as possible.

[bluemoon]

I think you misunderstood the meaning of ABI and the role of executables.

There is no assembly API, it just don't make sense. There is however, ABI definition, which act as an interface for things like parameter passing and return values. Any language, including assembly, may be mixed if they talk with same ABI.

Executable format is just a container with useful information for the OS to load and hence execute the program.


In some case one may optimize its API to adopt an ABI that is not supported by a particular compiler (e.g. stock gcc on i386 is not able/configured to pass parameters on register), so one may do it manually for better performance while knowing its tradeoff (break tools, or involve modified toolset).
However, with x86_64 AMD's ABI this also become wildly supported by HLL.

What I mean is ALL Assembly, from the kernel to the frameworks to middleware, to the application software support, any runtimes, system software, and device drivers. I am sure it would be one potentially fast responding system as well.

Try implement quick sort in full assembly and beat modern C++ compiler. If you can't beat it with quick sort, the chance beating it with a full OS is remote.

[LieutenantHacker]

No, I mean API, not ABI.

Maybe a better word (s) I should have used was application platform for applications compiled through Assembly.

A custom format would be needed, regardless of branching off an existing format for my own loader I am making, with special parameters necessary for my calling convention.

I wanted to have an application platform all in Assembly code only(i.e., only Assembly libraries can be linked with Assembly code, there's no HLL ports, such as with C standard library ports and C compilers).

That is how I want my OS to work, offering the most precision and speed, with less errors and stalling due to more native architecture code, and all code running in the same mode(i.e., no "kernel mode" or "user mode").

Basically, I want it all in Assembly.

Try implement quick sort in full assembly and beat modern C++ compiler.

Why should I need to implement a sorting algorithm for in Assembly? I don't see how that's relevant to my question.

I can get by with most of my kernel's basics without virtually any sorting algorithms, and I have actually tested this true with a hypothesis, theorem, and a schematic of the entire kernel. I've had the idea thought of and planned for some months now.

[Kazinsal]

So, a regular API then?

You have to wrap any HLL's system library around some assembly language to talk to the kernel.

[CJKay]

<deleted>

[osdog]

How about an OS with only an Assembly API?

No.

What I mean is ALL Assembly, from the kernel to the frameworks to middleware, to the application software support, any runtimes, system software, and device drivers. I am sure it would be one potentially fast responding system as well.

I am sure it would be one definitively unmaintainable and unportable cluster FUBAR without any software support.

I was wondering what the approach on this would be in some of your opinions, because I have FASM, a specialized toolchain, and my own output format specification ready to fire up some parts of my kernel as soon as possible.

The approach would be:

Code: Select all

1: write asm
2: OS still not finished yet? goto 1
3: post OS to osdev.org

... just my opinion though.

Maybe a better word (s) I should have used was application platform for applications compiled through Assembly.

"[A]pplications compiled trough Assembly" what does that even mean?
Like?

Code: Select all

$ gcc -c src.c
$ gcc src.s

and all code running in the same mode(i.e., no "kernel mode" or "user mode").

How does your OS cope with security?

Why should I need to implement a sorting algorithm for in Assembly? I don't see how that's relevant to my question.

What is your question? You OP contained exactly 0 (zero) question marks. A question mark (?) is a punctuation mark that replaces the full stop (period) at the end of an interrogative sentence in English.

I can get by with most of my kernel's basics without virtually any sorting algorithms, and I have actually tested this true with a hypothesis, theorem, and a schematic of the entire kernel. I've had the idea thought of and planned for some months now.

And the application layer? Will your file browser not be able to display files sorted?

Anyway no. No one has ever though of an Assembly API. Mostly because an API unlike an ABI suggest a HLL. If you write machine code directly that is binary op codes - which Assembly is just a human readable representation of - you are in fact doing an ABI.

[Mikemk]

Can't everything in rbil be considered part of various assembly apis?

[LieutenantHacker]

Is an interrupt list considered an API?

I am no pro on what constitutes formal arrangement of an application programming interface.

[linguofreak]

I mean has anyone ever developed a sort of application framework only for Assembly language support, no HLL like C, C++, D, Java, etc.

What I mean is ALL Assembly, from the kernel to the frameworks to middleware, to the application software support, any runtimes, system software, and device drivers.

A lot of older OS's were programmed in assembly language, and while no OS that I know of has tried to disallow programming applications in HLLs (because it's pretty much impossible: you can write a compiler that will generate code for any ABI, you can write an interpreter in assembly language, and so forth), older OS's were often written with the assumption that application programmers would be working in assembly language.

I am sure it would be one potentially fast responding system as well.

Nowadays compilers usually generate assembly code that's as good or better than a human can write. That, as well as the fact that HLL's are easier to write and debug with, is why OS's (and programs in general) are no longer done in assembly (and when humans do directly write assembly code, it's generally for stuff that's hardware-specific and not supported by the compiler, not for speed).

[LieutenantHacker]

So I still assume nobody here bears with me at all.

Oh well...

[dozniak]

So I still assume nobody here bears with me at all.

Oh well...

Are you asking for a blessing or what? Your OP still doesn't contain any question marks.

[rdos]

My API is register-based, but it is possible to write wrappers for HLLs that uses it (which I have done for both OpenWatcom and working on for GCC). That's as far as you can get with an assembly API. A few aspects of register APIs is hard to handle in HLLs, like multiple returns, but you can write wrappers for those as well.

[bluemoon]

FYI AMD x86-64 ABI is using registers, im sure rdos know this - he invent his own for different registers interface, not because HLL lack of it.

But for OP he/she may have wrong concept that HLL cannot efficiently use register.

[Combuster]

So I still assume nobody here bears with me at all.

The whole point is that an "Assembly API" is essentially a meaningless concept. All calls, kernel or not, require assembly. And it does essentially not matter if it's an assembler where you write out the call, or a high-level-language compiler that writes out the assembly for the call out for you.

The API defines nothing but functionality provided by a number of calls. The calls themselves can with various amounts of effort be done in any language. Your only choice is to try to be a egocentric dictatorial bastard and make it more difficult for languages beyond your own choice to use them (Try Apple's UIKit).

[rdos]

FYI AMD x86-64 ABI is using registers, im sure rdos know this - he invent his own for different registers interface, not because HLL lack of it.

I know, but register allocation in my API is typically based on type of a parameter, not which order in a HLL definition it is used in. For instance, handles is in ebx, buffers in es:edi, sizes in ecx.