Hacked Menuet32
Hacked Menuet32
I have currently been able to modify MenuetOS so it can assemble using YASM. Currently it assembles but it looks like the text messages in the GUI don't display, so it's necessary to figure out that problem and also I have commented out the network code because it has FASM macros that I don't know yet how to convert to YASM syntax.
What do you think? Do you consider it is worthwhile to fully convert the source code to MenuetOS (or another project) so it compiles with such simpler assembler and further explain it in a learning/teaching effort?
Here's the link, but you must note that it's incipient and, as I already said, it seems that text messages in the GUI are gone:
http://didactos.blogsyte.com/hacks/menuet
What do you think? Do you consider it is worthwhile to fully convert the source code to MenuetOS (or another project) so it compiles with such simpler assembler and further explain it in a learning/teaching effort?
Here's the link, but you must note that it's incipient and, as I already said, it seems that text messages in the GUI are gone:
http://didactos.blogsyte.com/hacks/menuet
.....Wow...... To convert an entire operating system from fasm to yasm.....wow.....Maybe you should start a project or something......
As for a more serious taste: I don't think that's it's really necessary to port something like that, unless you find significant reason to.
How is yasm simpler that fasm?
As for a more serious taste: I don't think that's it's really necessary to port something like that, unless you find significant reason to.
How is yasm simpler that fasm?
C8H10N4O2 | #446691 | Trust the nodes.
For example, I think to have seen something like:
And in my opinion at least, it is better if coded in a standard way like:
I have tried to remove code that use those "addons" so it can assemble in a more "standard" assembler.
Code: Select all
push eax ebx ecx
And in my opinion at least, it is better if coded in a standard way like:
Code: Select all
push eax
push ebx
push ecx
I have tried to remove code that use those "addons" so it can assemble in a more "standard" assembler.
- Brynet-Inc
- Member
- Posts: 2426
- Joined: Tue Oct 17, 2006 9:29 pm
- Libera.chat IRC: brynet
- Location: Canada
- Contact:
- Brynet-Inc
- Member
- Posts: 2426
- Joined: Tue Oct 17, 2006 9:29 pm
- Libera.chat IRC: brynet
- Location: Canada
- Contact:
Hooray for BSD licenced software ...ehird wrote:Yasm's nice because the license is BSD-like instead of NASM's LGPL. Now we need a BSD/MIT-licensed compiler using it...
http://nwcc.sourceforge.net/ -- Can use yasm as a backend...
And I think TenDRA can use nasm as a backend? I don't know what assembler it uses actually..
http://www.tendra.org/
Here are some points, first menuet was coded in nasm than converted to fasm, now Yasm is compatable with nasm, also note fasm and nasm as very similar.
So what you have shown is how good FASM is and people who have coded in nasm should have no problem converting to FASM .
There is just no case for using anyother assembler other than fasm, Yasm is not as good, or as fast , its much bigger, ( and remember if your talking C compilers, what does gcc need for its backend ?).
On top of this there has been many, argument with people making differant ver's of menuet, so be carfull.
Do not get me wrong menuet is a good gui OS, that has shown, that so far the only hobby GUI desktop OS, that a working model, so far is coded in ASM (fasm), (please do not say what about skyos etc, As they have so much linux code in them ).
So what you have shown is how good FASM is and people who have coded in nasm should have no problem converting to FASM .
There is just no case for using anyother assembler other than fasm, Yasm is not as good, or as fast , its much bigger, ( and remember if your talking C compilers, what does gcc need for its backend ?).
On top of this there has been many, argument with people making differant ver's of menuet, so be carfull.
Do not get me wrong menuet is a good gui OS, that has shown, that so far the only hobby GUI desktop OS, that a working model, so far is coded in ASM (fasm), (please do not say what about skyos etc, As they have so much linux code in them ).
Last edited by Dex on Sun Apr 01, 2007 11:30 am, edited 2 times in total.
A typical compiler needs from the assembler basicly the ability to turn textual strings into binary opcodes, and the ability to pass symbol, segment and alignment information to the linker, preferably with enough detail that the linker can do the "right thing".
That's about it.
That's about it.
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
Too bad they're hardcoded C-only instead of backend + frontends... You could write a FizzBuzz compiler...Brynet-Inc wrote:Hooray for BSD licenced software ...ehird wrote:Yasm's nice because the license is BSD-like instead of NASM's LGPL. Now we need a BSD/MIT-licensed compiler using it...
http://nwcc.sourceforge.net/ -- Can use yasm as a backend...
And I think TenDRA can use nasm as a backend? I don't know what assembler it uses actually..
http://www.tendra.org/
Last edited by ehird on Sun Apr 01, 2007 11:52 am, edited 1 time in total.
again, fasm has its faults.
1. In a nutshell, it's not very portable. (N|Y)asm is. Most of these problems are a subset of this.
2. It has little support for object files; hence it's harder to interact with C. Somehow i don't see this as an issue for MenuetOS.
3. No cross-compiling, as I mentioned a few minutes ago.
4. few binary options. what are they; bin, coff, elf, and mz? where's MACH-O for osx? where's a.out?
when I'm on x86, fasm is really nice, if I'm on an operating system that supports it, but i will always use gas or nasm because of the porrtability.
[edit] Oh yea, it also supports PE.[/edit]
1. In a nutshell, it's not very portable. (N|Y)asm is. Most of these problems are a subset of this.
2. It has little support for object files; hence it's harder to interact with C. Somehow i don't see this as an issue for MenuetOS.
3. No cross-compiling, as I mentioned a few minutes ago.
4. few binary options. what are they; bin, coff, elf, and mz? where's MACH-O for osx? where's a.out?
when I'm on x86, fasm is really nice, if I'm on an operating system that supports it, but i will always use gas or nasm because of the porrtability.
[edit] Oh yea, it also supports PE.[/edit]
A cross-compiler is this: http://en.wikipedia.org/wiki/Cross_compilerbaileydr wrote: 3. No cross-compiling, as I mentioned a few minutes ago.
Than what do you call me coding for ARM on a x86 using fasm ?.
- Brynet-Inc
- Member
- Posts: 2426
- Joined: Tue Oct 17, 2006 9:29 pm
- Libera.chat IRC: brynet
- Location: Canada
- Contact:
Oh wow.. 2 architectures.. fasm was written in assembly..Dex wrote:A cross-compiler is this: http://en.wikipedia.org/wiki/Cross_compiler
Than what do you call me coding for ARM on a x86 using fasm ?.
That's 2 separate codebases for fasm?.. fix a bug in the one written in ARM assembly you might have to port it back to x86 assembly..
With C, A new Architecture/OS is what? a recompile and/or a few #ifdef's away..
GAS/NASM/YASM is my pick... It allows a greater level of cross-compilation support..
- Brynet-Inc
- Member
- Posts: 2426
- Joined: Tue Oct 17, 2006 9:29 pm
- Libera.chat IRC: brynet
- Location: Canada
- Contact:
differant? versions of MenuetOS? (It's different..)..Dex wrote:On top of this there has been many, argument with people making differant ver's of menuet, so be carfull.
I heard that they don't like the fact people are forking the older MenuetOS now that they have gone proprietary, But unfortunately.. They can't relicense the older versions under a alternative licence.. Anyone can take the older GPL'd version and do what they want with it, It was their choice to use the GPL in the first place.
GPL is truely infective.. but still.. This does allow people to take their last GPL release and continue the project as GPL