MASM using longer opcode sequences than GAS

[Colin Finck]

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

[David Quintana (gigaherz)]

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(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[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.
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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Magnus Olsen]

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(a)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(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Colin Finck]

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