OSDev.org

I just ported nasm over to my OS and the executable came to 600,920 bytes. I took -g off the command line and used -Os and got it down to around 540,000. This still seems pretty big. Is it supposed to be this big? I'm using version 2.05.

As a side note.. woohoo.. I've got nasm.

The nasm executable on my Debian Stable system is about ~520KiB. So yes, I'd guess so. I never realised how much of a behemoth nasm is.

Also, congratulations on getting nasm running!

Okay, thanks. I never realized how big it was. Cygwin's is 340k but it's a little older.

Now if I could only get cc1 to fit on a floppy so I could transfer it to my test computer, then I'd be fully self hosting.

If you have dd on your test computer, try splitting it into two parts. Get the first 1.44MB, transfer that over, get the part after the 1.44MB barrier, transfer that over, then merge the two back together. I know dd can do this since I did it once, but I can't remember how. Google is your friend.

JackScott wrote:If you have dd on your test computer, try splitting it into two parts. Get the first 1.44MB, transfer that over, get the part after the 1.44MB barrier, transfer that over, then merge the two back together. I know dd can do this since I did it once, but I can't remember how. Google is your friend.

I'd assume you copy the first 1300 kilobytes (let's go with that) using dd to a new file, and do the rest using dd, into two separate files, and them cat them together.

EDIT: Oh, and the standard x86 Windows NASM executable is 538KB for 2.05.01 from October.

Troy Martin wrote:I'd assume you copy the first 1300 kilobytes (let's go with that) using dd to a new file, and do the rest using dd, into two separate files, and them cat them together.

That's what I said.

Okay, so I'm going to go out on a limb here and say you need to use bs= and count= (with if= and of=) and possibly some arithmetic (or a start block setting, if dd has that.)

For instance, in DOS/Windows, you'd go "partcopy cc1 0 14CCCC cc1.part1" for the first 1.3KB, then "partcopy cc1 14CCCD (size of file in hex) cc1.part2" to split it and "copy cc1.part1+cc1.part2 cc1" to fuse them together.

EDIT: also, you may want to run a file compare (FC under DOS) to make sure the file fused together correctly.

For testing: On the development machine: Copy the two test.partx files to the other machine, and do this: Note that I've used a block size of 1 (byte) to make my brain not hurt. Using a larger block size would probably mean more efficiency. Not that it matters on a single file.

Have you tried running 'strip' on the binaries?

Strip won't work because my executable format is just flat binary.

As for splitting cc1 up and putting it back together, excellent suggestion. I'll give it a whirl. Either that, or dive into some atapi and iso9660 coding.

kubeos wrote:Strip won't work because my executable format is just flat binary.

Ah, then you probably won't have anything strippable on there anyway.

kubeos wrote:As for splitting cc1 up and putting it back together, excellent suggestion. I'll give it a whirl. Either that, or dive into some atapi and iso9660 coding.

If you're loading from a Multiboot loader then you could do something similar to what I do for quick testing - put stuff into a Tar archive and load it as a Multiboot module that can then be extracted onto a RAM disk by the kernel. You can boot that off a CD without actually having to code CD support.

kubeos wrote:Okay, thanks. I never realized how big it was.

Yes, most of the generic assemblers out there are built for portability, maintainability, and easy addition of features. They are also built as collective programming projects, in C trying to masquerade as C++, and with an eye toward churning out code that almost works -- rather than efficiency. So they are all enormous.

In my spare time, I am working on an x86 assembler (in ASM), and it looks like it's going to tip the scales at 7K. So an assembler doesn't quite need to be as big as nasm to work.

bewing wrote:In my spare time, I am working on an x86 assembler (in ASM), and it looks like it's going to tip the scales at 7K. So an assembler doesn't quite need to be as big as nasm to work.

Shiny. Is it a real mode assembler?

Wow, you're from Langley Troy. I think that makes 3 of us from BC on here.

Yep, wonderful province. Two of us are from the Vancouver area, too!