Nasm port HUGE

[kubeos]

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.

[JackScott]

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!

[kubeos]

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.

[JackScott]

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.

[Troy Martin]

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.

[JackScott]

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.

[Troy Martin]

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.

[JackScott]

For testing:

Code: Select all

dd bs=1 count=1536K if=/dev/random of=./test

On the development machine:

Code: Select all

dd bs=1 count=1M if=./test of=./test.part1
dd bs=1 count=512K if=./test of=./test.part2 skip=1M

Copy the two test.partx files to the other machine, and do this:

Code: Select all

dd bs=1 count=512K if=./test.part2 of=./test.part1 seek=1M
mv ./test.part1 ./test

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.

[xyzzy]

Have you tried running 'strip' on the binaries?

[kubeos]

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.

[xyzzy]

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

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

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.

[bewing]

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.

[Troy Martin]

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?

[kubeos]

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

[Troy Martin]

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