Hi all,
In order to make our ISOs flashable to USB drives and bootable from them (cf. CORE-12648), I'm currently overhauling our ISO boot sector "isoboot.S". This adds a lot of code and while I stay in the 2K size limit when assembling it with GAS, I break it with MASM.
Disassembling the assembled files shows the difference. A line like:
mov word ptr ds:[GetlinsecPtr], ax
is assembled by GAS to:
A35B50 mov [0x505b],ax
while MASM does this:
67A35B500000 mov [dword 0x505b],ax
Is there any option to enforce the shorter opcode sequence for MASM too? The code uses a lot of similar MOVs and this seems to be the only reason why I break the 2K size limit with MASM.
If there is no such option, what are the advantages of using MASM for our MSVC build anyway? Can't we just use GAS for both or decide on a common third-party assembler (NASM) for our assembly files?
Cheers,
Colin
No idea about the encoding length, but I wonder why we don't just use NASM everywhere, instead of having two separate assemblers.
On 17 January 2017 at 10:23, Colin Finck colin@reactos.org wrote:
Hi all,
In order to make our ISOs flashable to USB drives and bootable from them (cf. CORE-12648), I'm currently overhauling our ISO boot sector "isoboot.S". This adds a lot of code and while I stay in the 2K size limit when assembling it with GAS, I break it with MASM.
Disassembling the assembled files shows the difference. A line like:
mov word ptr ds:[GetlinsecPtr], ax
is assembled by GAS to:
A35B50 mov [0x505b],ax
while MASM does this:
67A35B500000 mov [dword 0x505b],ax
Is there any option to enforce the shorter opcode sequence for MASM too? The code uses a lot of similar MOVs and this seems to be the only reason why I break the 2K size limit with MASM.
If there is no such option, what are the advantages of using MASM for our MSVC build anyway? Can't we just use GAS for both or decide on a common third-party assembler (NASM) for our assembly files?
Cheers,
Colin
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
"ASSUME DS:.text" allows the assembler to use a smaller addressing mode -- but then also (silently) refuses to use 32 bit memory operands. E.g. mov ds:[01234h], ax mov ds:[012345678h], ax becomes 6: a3 34 12 mov %ax,0x1234 9: a3 78 56 mov %ax,0x5678
I believe we used to use NASM for everything and were happy when we could switch to using the compiler's native assembler. However I don't remember if there was a particular reason other than eliminating a dependency. Perhaps Timo or Amine know the details.
On 2017-01-17 10:23, Colin Finck wrote:
Hi all,
In order to make our ISOs flashable to USB drives and bootable from them (cf. CORE-12648), I'm currently overhauling our ISO boot sector "isoboot.S". This adds a lot of code and while I stay in the 2K size limit when assembling it with GAS, I break it with MASM.
Disassembling the assembled files shows the difference. A line like:
mov word ptr ds:[GetlinsecPtr], ax
is assembled by GAS to:
A35B50 mov [0x505b],ax
while MASM does this:
67A35B500000 mov [dword 0x505b],ax
Is there any option to enforce the shorter opcode sequence for MASM too? The code uses a lot of similar MOVs and this seems to be the only reason why I break the 2K size limit with MASM.
If there is no such option, what are the advantages of using MASM for our MSVC build anyway? Can't we just use GAS for both or decide on a common third-party assembler (NASM) for our assembly files?
Cheers,
Colin
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Hi everyone it is long time, What I rember back 2003 the choice was easy, nasm did exists for linux and windows and dos. nasm was only one did have mmx and sse support at that time and more advance macro. masm did not exists for linux and reactos where compile in dos, linux and windows nt envirom at this time. later all support for dos was droped.
On Tue, Jan 17, 2017 at 11:07 AM, Thomas Faber thomas.faber@reactos.org wrote:
"ASSUME DS:.text" allows the assembler to use a smaller addressing mode -- but then also (silently) refuses to use 32 bit memory operands. E.g. mov ds:[01234h], ax mov ds:[012345678h], ax becomes 6: a3 34 12 mov %ax,0x1234 9: a3 78 56 mov %ax,0x5678
I believe we used to use NASM for everything and were happy when we could switch to using the compiler's native assembler. However I don't remember if there was a particular reason other than eliminating a dependency. Perhaps Timo or Amine know the details.
On 2017-01-17 10:23, Colin Finck wrote:
Hi all,
In order to make our ISOs flashable to USB drives and bootable from them (cf. CORE-12648), I'm currently overhauling our ISO boot sector "isoboot.S". This adds a lot of code and while I stay in the 2K size limit when assembling it with GAS, I break it with MASM.
Disassembling the assembled files shows the difference. A line like:
mov word ptr ds:[GetlinsecPtr], ax
is assembled by GAS to:
A35B50 mov [0x505b],ax
while MASM does this:
67A35B500000 mov [dword 0x505b],ax
Is there any option to enforce the shorter opcode sequence for MASM too? The code uses a lot of similar MOVs and this seems to be the only reason why I break the 2K size limit with MASM.
If there is no such option, what are the advantages of using MASM for our MSVC build anyway? Can't we just use GAS for both or decide on a common third-party assembler (NASM) for our assembly files?
Cheers,
Colin
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Am 17.01.2017 um 11:07 schrieb Thomas Faber:
"ASSUME DS:.text" allows the assembler to use a smaller addressing mode -- but then also (silently) refuses to use 32 bit memory operands.
That does the job, thanks! As the boot sector is only working with 16-bit memory addresses, this disadvantage is acceptable to me.
By the way, one major benefit of using both GAS and MASM is definitely error checking. GAS even assembles code referencing nonexisting symbols just fine...
- Colin
-
Colin Finck -
David Quintana (gigaherz) -
Magnus Olsen -
Thomas Faber