OSDev.org

This is all very off topic, and if continued, we're at risk of a split and a righteous chastising, but it's hard for me not to want to throw in on this.

StephanVanSchaik wrote:You can gain more performance with Assembly than C, especially on embedded devices such as the GBA.


Regards,
Stephan J.R. van Schaik.

Although this is true in some cases, often the compiler knows the actual instruction pipeline and caching characteristics better than we do, unless we helped design the chip. GCC can output thumb code as well, so as long as you're paying attention to the bus specs well enough to place the proper types of code in the proper places of the GBA memory map, you're likely not going to gain much in foregoing productivity for alleged performance in going with assembly.

However, as a personal stylistic choice, assembly is always a valid option.

The ARM7TDMI is a simple in order single issue chip with no cache.

What does the compiler know that can make it better than me at that? In fact, its often worse, because it invokes its multiplication helper routines when you could do it in a couple of instructions instead...

Of course, really need to avoid running ARM mode code from main memory. Massive performance killer.

(Now, if this were the NDS, that does indeed have caches. But also a bat **** insane memory architecture...)

Owen wrote:The ARM7TDMI is a simple in order single issue chip with no cache.

What does the compiler know that can make it better than me at that? In fact, its often worse, because it invokes its multiplication helper routines when you could do it in a couple of instructions instead...

I hadn't looked that deeply into the GBA specifically, so I wasn't aware of those characteristics, and they do make my main argument moot. Thank you for informing me.

Owen wrote:Of course, really need to avoid running ARM mode code from main memory. Massive performance killer.

(Now, if this were the NDS, that does indeed have caches. But also a bat **** insane memory architecture...)

This is what I was getting at with my "pay attention to the bus specs" remark. In some passing Nerd ADD research, I knew that the main memory bus in the GBA is 16-bit, and therefore well-suited to thumb code, and that there is also a 32-bit RAM area where you can load some 32-bit code.

I do recognize the benefits of assembly in a limited environment, and I recognize it always as a valid choice for personal reasons in any personal project. What I was trying to get at is that, if you're careful, a language as low-level as C can easily increase productivity and still fit rather well to the needs of the environment. Especially if you specify to the compiler that you don't want any builtin code included and augment with assembly where needed.

Thank you for your rebuttal, it was both engaging and informative.

This thread lacks a bit of pictures of OSes running on real hardware...
Here is mine on a Acer Aspire 9300.

Very impressive. Kind of reminds me of Windows 3.1/Pre-DE Unix workstations.

Well after like a million start overs I have finaly made a successful 32bit p-mode OS in assembly Well... it is not perfect, but neither am I



@Tommy: Nice, I cannot wait to try a beta or demo release

This is very basic still. I have been reading this site and art of assembly and other resources for almost a month now.
Originally I was just working through tutorials and playing with some C code, but over the last 2 days, I've been working on putting my new (basic) assembly knowledge to use.
I wrote everything except the strcmp function, the putstring function, and the bootsector in nasm in about 2 days(these 3 peices of code i borrowed from tutorials I have been working with)... Not bad for a noob I think.

Lots of learning to do still, I know this isn't a huge achievement, especially after seeing some of your screenshots but I just thought I'd make my presence here known since I've been coming to this site for a while:) Next step is to wrap my head around reading a formatted filesystem:) hopefully more impressive screenshot to come soon.

Coddy wrote:Well after like a million start overs I have finaly made a successful 32bit p-mode OS in assembly Well... it is not perfect, but neither am I

Nice to see that your OS is progressing well . And it's very colorful.

We've just implemented a module into Pedigree that listens on a given port and basically, when you point your browser to it, dumps a heap of information about the running system. Later revisions have the kernel log included, but this example here just has the build information and available network interfaces.

Image attached.

Still working on the bootloader. Here is my xOS in FreeDOS(xOS only uses BIOS interrupts)
Here is it's MessageBox function

and it's list of commands

@konrad236
Is that the windows 3.11 system font used during the installation?

@Karlosoft

Actually this is just a simple real mode kernel using bios calls. The font is I guess the font vmware player 3.1 for windows uses in it's simulated bios.
I've been developing on linux in vmware and then dragging the image file onto my windows desktop over the previous image, and starting up the testbed vm in windows.

I've also run it on my netbook, just dd'ed the floppy image to a small sd card and set force fdd in the bios.

Hoping to be able to load and execute flat binary files off the disk by the end of the day, custom font seems like a long way off in another project lol.

wow tommy, you pretty much did what my dream was, build an os that looked like windows 3.1. your my hero lol haha

GhostXoPCorp wrote:wow tommy, you pretty much did what my dream was, build an os that looked like windows 3.1.

Me too I still wanted . I always liked the concept of GUI Windows 3.1 had: very simplist. Well, I added a bar on the desktop and
a system menu:



That makes you dream it even more?

yes, thats why i loved the design of the gui, it was very universally simple, great job


i did notice... all of your programs are of the same size?..