MASM/WASM .model

[Robert Pengelly]

Does anyone know what .model actually does in MASM? I found http://www.c-jump.com/CIS77/ASM/Directives/lecture.html#D77_0030_models which states "Small model supports one data segment and one code segment." but yet if I use .model small,c with WASM I can still create multiple segments when I use 'CODE' or 'DATA'. Have I misunderstood what ".model" does or is WASM ignoring the .model line.

[Alexei A. Frounze]

On Saturday, July 16, 2022 at 10:44:44 AM UTC-7, Robert Pengelly wrote:
> Does anyone know what .model actually does in MASM? I found http://www.c-jump.com/CIS77/ASM/Directives/lecture.html#D77_0030_models which states "Small model supports one data segment and one code segment." but yet if I use .model small,c with WASM I can still create multiple segments when I use 'CODE' or 'DATA'. Have I misunderstood what ".model" does or is WASM ignoring the .model line.

Are you expecting it to forbid additional segments that you may mistakenly define?
Are you getting too many segments when you expect only two?

As usual, what's your code and how do you assemble and link it?
Alex

[Robert Pengelly]

Sorry, I have the following code:

.model small, c
.386p

_DATA segment word public 'DATA'
data1 dw 18h
_DATA ends

_DTEST segment word public 'DATA'
data2 dw 80h
_DTEST ends

_TEXT segment word public 'CODE'

start:

cli
hlt

_TEXT ends

_TTEXT segment word public 'CODE'

test:

cli
hlt

_TTEXT ends

end

If small only supports one code and one data segment then I don't expect the code to assemble using WASM as there's two code and two data segments but yet it does.

[Alexei A. Frounze]

Then don't define more segments than you need.
(It's a good question of why you may think you need them!)

However, if you still want somewhat (just visually?) separate segments
for e.g. different kinds of data (constants, initialized-to-zero vars,
other initialized vars, etc) which in the end will be part of one 64KB
segment, you may group them. See the group directive.

Also, if you only use the "Simplified segment directives" like .CODE,
.CONST, .DATA, I bet they would be automatically grouped together
as necessary.

Alex

[Robert Pengelly]

It's not a case of whether I define them or not, I'm just trying to understand how MASM (and MASM-compatible assemblers) work and I'm asking what .model actually does/doesn't do as from my understanding it shouldn't compile and display an error instead. If your not going to bother answering the question and instead tell me what I should and shouldn't do then why both even replying.

[Alexei A. Frounze]

Maybe you should state your problem/task/objective more fully when asking for help with it.
What you just said did not immediately follow from the original post.

Alex

[Robert Pengelly]

Actually it does I did ask "Does anyone know what .model actually does in MASM?" and "Have I misunderstood what ".model" does" then you asked for code and I provided it then you tell me what I should and shouldn't be doing. How hard is it to understand that I'm trying to understand how MASM and MASM-compatible assemblers function with regards to .model. I'm under the assumption that if you use .model small, c then the assembler should fail (and before you bitch again like I originally asked) have I misunderstood what ".model" does or is WASM ignoring the .model line. Seriously how hard is it to get a simple answer to a question.

[Alexei A. Frounze]

It's not a typical question I'd expect without any prior history or larger
context. As it turns out you're not asking about how to use the tool
(which is a more common question), you're asking about how it's
implemented, about its edge cases, you're almost asking how to
reverse engineer or replicate the tool.
This isn't the kind of question I would normally expect.

Further, this may not be implemented equally in similar/compatible
assemblers.

xASM may not be ignoring the .MODEL directive, it just may not be
doing the kind of check you're expecting from it. All it may be doing
in response to .MODEL is generating .CODE, .DATA and other such
special segments into two groups, which will reside in two distinct
64KB segments after linking. And that's it, without imposing any
limitations on any other segments you may throw in.
(and, of course, there's some support for subroutines, argument
passing and such, which is also affected by .MODEL, but we
aren't discussing subroutines here/now)
Your linker may then either fail to link or it just may produce an
executable with all your segments. And there isn't any problem in
DOS .EXEs having several dozens or even a hundred of different
segments (possibly overlapping).

If you want more info, check the official documentation or
find the answer by experimentation. But I'm guessing you already
have your answer. The assembler doesn't limit the number of
your segments. So, if you want to replicate this behavior, do it.
If you still want the check that the assembler isn't doing for you,
you need something else to do it. If you're generating code,
you may check for it on the generator side. If you're writing the
code by hand, either be careful or see if there's anything that
you can use to catch undesired segments. See if there are other
useful directives or options in the assembler or linker. See if you
can just post-process the object file or the map file or even the
executable...

There's no need to be so rude. Explain what you're trying to do.
Do some research yourself. You're not always going to get
everything right away and the way you want it.

Alex

[Robert Pengelly]

I weren't being rude (not intentionally any) I just got a little annoyed by you telling me "Then don't define more segments than you need." and then "What you just said did not immediately follow from the original post. " plus it was late and I couldn't sleep due to the heat, I have a very short fuse and I tend to lash out easily and I'm sorry for that but now I have a clear head. I've tried doing research when it come to wasm but I can't seem to find anything about it from google and other search engines (some examples are https://www.google.co.uk/search?q=wasm+model give me results about webassembly whatever that is). Other than trying to understand the source code (which I have tried and failed at multiple times) I have no idea what should and shouldn't happen. For larger context, I'm a developer and I'm fascinated by assemblers at the moment and I'm trying to understand how they work from a developer perspective (how they work, how they could be implemented, etc) by using existing ones and examining the output. Microsoft's documentation about MASM directives I kind of useless as well, take https://docs.microsoft.com/en-us/cpp/assembler/masm/dot-model?view=msvc-170 it tells you about the directive, the arguments and model types but doesn't tell what the types actually do. I've also looked a JWasm to try and understand it (source code is a bit earlier to go through) but it doesn't support ".model" it does support "-ms" as a command line option but couldn't really find where it was effecting the code. Is that better or do you need more.

[se...@conman.org]

It was thus said that the Great Robert Pengelly <roberta...@gmail.com> once stated:

>
> I weren't being rude (not intentionally any) I just got a little annoyed
> by you telling me "Then don't define more segments than you need." and
> then "What you just said did not immediately follow from the original
> post. " plus it was late and I couldn't sleep due to the heat, I have a
> very short fuse and I tend to lash out easily and I'm sorry for that but
> now I have a clear head. I've tried doing research when it come to wasm
> but I can't seem to find anything about it from google and other search
> engines (some examples are https://www.google.co.uk/search?q=wasm+model
> give me results about webassembly whatever that is). Other than trying to
> understand the source code (which I have tried and failed at multiple
> times) I have no idea what should and shouldn't happen. For larger
> context, I'm a developer and I'm fascinated by assemblers at the moment
> and I'm trying to understand how they work from a developer perspective
> (how they work, how they could be implemented, etc) by using existing ones
> and examining the output. Microsoft's documentation about MASM directives
> I kind of useless as well, take
> https://docs.microsoft.com/en-us/cpp/assembler/masm/dot-model?view=msvc-170
> it tells you about the directive, the arguments and model types but
> doesn't tell what the types actually do. I've also looked a JWasm to try
> and understand it (source code is a bit earlier to go through) but it
> doesn't support ".model" it does support "-ms" as a command line option
> but couldn't really find where it was effecting the code. Is that better
> or do you need more.

The "model" directive is more for interfacing with higher level languages
like C or Pascal and dictate how the code is laid out for real mode x86
developement. It's been years since I had to deal with this, but I do
recall a few details. What I recall are: this assume an x86 in real mode
with each segment being limited to 64K in size, with the models being
defined as:

tiny
This model all the code (CS), data (DS) and stack (SS) reside in a
single segment of memory. So CS=DS=SS.

small
This model the code is in a separate segment, and the data (DS) and
stack (CS) are in a separate segment. So CS by itself, and DS=SS

medium
I don't recall the specifics

compact
I don't recall the specifics

large
I don't recall the specifics

huge
You can have multiple code segments, data segments and stack
segments---in other words, you can have more than 64k of code, more
than 64k of data and mroe than 64k of stack.

flat
New to me actually (from the link you provided), but from context, I
think it means using the 80386 protected mode [1] with a single 4G
segment (flat mode)---i.e. CS=DS=SS (this is a very simplified view
of what is actually going on).

I do know there exists a model where you are limited to one code segment
of 64k (max length), one data segment, and one stack segment, but I don't
recall which model that is. The other ones are variations (>64k code, 64k
of data+stack, 64k code, 64k data, 64k stack, etc.).

All of this is very particular to MS-DOS and real mode programming on the
x86 line. These days you can ignore all this since it's not really relevant
anymore (unless you are maintaining legacy code for MS-DOS systems).

Personally, I no longer use MASM (last time I used it was in the mid-90s).
These days, if I am doing x86 programming, it's on Unix systems (like Linux
or Mac OS-X) with nasm, where one does not have to deal with segments at
all (it's all flat).

Assemblers are like any other compiler---they accept source code and
generate object files or executable files (depending upon assembler,
options, platform, etc.) and they can be implemented in any language (I've
used assemblers written in assembly, C, Perl and Lua). There's nothing
really magical about them, and in some ways, they are easier to implement
than a compiler.

-spc

[1] This can be done in real mode, by the way, but I don't recall the
exact details in setting this up.

[Robert Pengelly]

Thanks for that very detailed response, when you say "The "model" directive is more for interfacing with higher level languages
like C or Pascal" does that mean that the assembly source doesn't really get effected by it? Also from what you wrote about the models I'm assuming that '.model' doesn't effect the number of 'CODE' and 'DATA' segments within the source file it just effects the output and will merge the segments together later or am I wrong with that assumption? Only recently I've looked at MASM (or rather WASM), I used to use NASM before I helped create an assembler based on GAS although I don't really like att syntax and it's annoying putting .intel_syntax noprefix at the top of every file so I'm going to fork it and use just intel syntax but I'm trying to decide on whether it will be worth making it somewhat MASM compatible.

[se...@conman.org]

It was thus said that the Great Robert Pengelly <roberta...@gmail.com> once stated:

> Thanks for that very detailed response, when you say "The "model"
> directive is more for interfacing with higher level languages like C or
> Pascal" does that mean that the assembly source doesn't really get
> effected by it?

I don't know. All my work under MS-DOS was with assembly only, so I was
never really affected by all this. I do know that some compilers for MS-DOS
have switches to select the model, but that's generally used to get around
the 64K segment limit.

> Also from what you wrote about the models I'm assuming
> that '.model' doesn't effect the number of 'CODE' and 'DATA' segments
> within the source file it just effects the output and will merge the
> segments together later or am I wrong with that assumption?

Again, I'm not sure. That would be a valid interpretation to me, but it
could be completely wrong.

> Only recently
> I've looked at MASM (or rather WASM), I used to use NASM before I helped
> create an assembler based on GAS although I don't really like att syntax
> and it's annoying putting .intel_syntax noprefix at the top of every file
> so I'm going to fork it and use just intel syntax but I'm trying to decide
> on whether it will be worth making it somewhat MASM compatible.

Why not use nasm? I've found it very close to MASM but then again, I
don't have a lot of MASM code to convert (all my MASM stuff was 16-bit x86
code, which I don't use much of these days).

-spc

[Robert Pengelly]

I used to use NASM but it has limitations. One example would be that it only allows one file to be assembled at a time and another example would be far jumps, using nasm -f coff test.asm -o test.o I get "error: COFF format does not support non-32-bit relocations" and using nasm -f bin test.asm -o test.bin I get "error: binary output format does not support segment base references" so I don't know how to far jump with NASM. I've also used GAS but you can't assemble for 8086, there is the ia16-elf fork but that also has limitations and it's only available on ubuntu, I assume compiling it from source would make it available on other systems but when you jump between systems that becomes awkward and time consuming not to mention there's no way to get it on Windows. What ever the developers are doing to WASM very often makes the build fail on Linux so I end up using a VM to test things out with it. It's just easier to create one.

[Alexei A. Frounze]

On Monday, July 18, 2022 at 10:08:07 PM UTC-7, Robert Pengelly wrote:
> I used to use NASM but it has limitations. One example would be that it only allows one file to be assembled at a time

A minor problem. You can have your ASM files %include "somefile.asm"
with NASM.

> and another example would be far jumps, using nasm -f coff test.asm -o test.o I get "error: COFF format does not support non-32-bit relocations"

AFAIR, -f obj would be the proper option to generate object files with
16-bit segmented code. Then you'd need to link the object file(s) with
say Turbo/Borland linker, TLINK, that comes with some old Pascal and
C/C++ compilers for DOS. MASM's LINK and WASM's WLINK might
work too, but I haven't tried doing that in a long time.

> and using nasm -f bin test.asm -o test.bin I get "error: binary output format does not support segment base references" so I don't know how to far jump with NASM.

If you don't use instructions that require unsupported relocations,
you can do far jumps just fine. Except, maybe it won't be a very
meaningful thing to try to do on a 32-bit OS like Windows and Linux.

You could always push the 16-bit segment and then the 16-bit offset
and then do RETF to perform a far jump in 16-bit mode.

The segmentation problems you're talking about are an indicator of
lack of knowledge of the x86 architecture and/or tools. There are ways
to do unconventional things like mixing 16-bit and 32-bit code in the
same executable, like using segmentation in object/executable file
formats that don't seemingly allow it, like generating non-trivial
binaries with NASM without using a linker or any other similar tool.
It does take time to learn and try and come up with working solutions.
It can be frustrating in the beginning when the tools don't do what
you want right away.

> I've also used GAS but you can't assemble for 8086, there is the ia16-elf fork but that also has limitations and it's only available on ubuntu, I assume compiling it from source would make it available on other systems but when you jump between systems that becomes awkward and time consuming not to mention there's no way to get it on Windows. What ever the developers are doing to WASM very often makes the build fail on Linux so I end up using a VM to test things out with it. It's just easier to create one.

I'm just using NASM for my stuff. DOS, Windows, Linux, MacOS, doesn't
matter.

Alex

[Robert Pengelly]

I know nasm has the %include option I just saying that only being able to assemble one file at a time is a limitation. as for .obj files only open watcom v2 in avaiable on Linux (when I can actually get it to compile). As for the far jump, sorry I weren't specific, I know you can push values to the stack then retf, what I mean was say I have:

section .data
roffs: dd some_offset
rseg: dw some_segment

section .text
jump:
jmp far roffs

I get the segmentation errors. Don't get me wrong NASM is a great tool it just has limitations that you got to find workarounds for.

[wolfgang kern]

On 19/07/2022 08:07, Robert Pengelly wrote:
....

> section .data
> roffs: dd some_offset
> rseg: dw some_segment
>
> section .text
> jump:
> jmp far roffs

> I get the segmentation errors. Don't get me wrong NASM is a great tool it just has limitations that you got to find workarounds for.

perhaps you want to jump to the memory contents of roffs ?
shouldn't offset be 16bit (dw) ?
jmp far [ds: roffs] ;the ds may be not required.
__
wolfgang

[Robert Pengelly]

I don't think the roffs should be 16bit, from what I've read a far jump is a jump to a 16bit segment and 32bit offset. I'm assuming that jmp far roffs in NASM should be the equivalent to jmp fword ptr roffs in MASM.

[se...@conman.org]

It was thus said that the Great Robert Pengelly <roberta...@gmail.com> once stated:
>

> I know nasm has the %include option I just saying that only being able to
> assemble one file at a time is a limitation. as for .obj files only open
> watcom v2 in avaiable on Linux (when I can actually get it to compile).

Are you trying to generate executables for MS-DOS? Because that's the
only operating system where all of this really applies. Anything using the
x86 architecture today basically ignore the segment registers and operate in
a flat mode.

-spc

[se...@conman.org]

It was thus said that the Great Robert Pengelly <roberta...@gmail.com> once stated:

> On Tuesday, 19 July 2022 at 17:59:59 UTC+1, wolfgang kern wrote:
>> On 19/07/2022 08:07, Robert Pengelly wrote:
>>
>> > I get the segmentation errors. Don't get me wrong NASM is a great tool
>> > it just has limitations that you got to find workarounds for.
>>
>> perhaps you want to jump to the memory contents of roffs ?
>> shouldn't offset be 16bit (dw) ?
>> jmp far [ds: roffs] ;the ds may be not required.

> I don't think the roffs should be 16bit, from what I've read a far jump is
> a jump to a 16bit segment and 32bit offset. I'm assuming that jmp far
> roffs in NASM should be the equivalent to jmp fword ptr roffs in MASM.

It depends upon how the CPU is running. In real mode, it's a 16-bit
segment, with a 16-bit offset. In protected mode in a 16-bit segment, it's
still a 16-bit selector (NOT a segment) with a 16-bit offset, and if the
target is a 32-bit segment, a 16-bit selector with a 32-bit offset. 64-bit
mode doesn't use segements for the most part.

Unless you are trying to write code for MS-DOS, there's no need to deal
with segments or far calls at all. There's over 40 years of historical
bagage to the Intel x86 line.

-spc

[Robert Pengelly]

There's a need for far calls and segments when dealing with boot loaders as they tend to switch between real mode and protected mode. Where there are need though is sort of irrelevant, as regardless of the reasons they are used other than targeting omf objects there doesn't appear to be a way to do 16-bit selector and 32-bit offset using NASM as I keep getting the errors.

[Alexei A. Frounze]

On Tuesday, July 19, 2022 at 5:40:04 PM UTC-7, Robert Pengelly wrote:
> There's a need for far calls and segments when dealing with boot loaders as they tend to switch between real mode and protected mode. Where there are need though is sort of irrelevant, as regardless of the reasons they are used other than targeting omf objects there doesn't appear to be a way to do 16-bit selector and 32-bit offset using NASM as I keep getting the errors.

The boot sector is too small to do much useful beyond loading
a few more sectors from hard-coded locations or a file from
FAT12/16/32 and it shouldn't be switching to protected mode
(other than, perhaps, to copy loaded sectors to beyond 1MB mark)
as that would further complicate things and leave less room
for what's important.

Yes, one sector is enough to load a DOS-style .COM or .EXE file
off a FAT1x/32 FS. See my https://github.com/alexfru/BootProg .

That 2nd stage loader (.COM or .EXE), which can be much larger,
may load the rest of your OS kernel (if not just contain it if it's
not too big) and compared to just one sector there's enough room
for code that would query BIOS, examine the hardware and
switch to protected mode and all.

If you use my https://github.com/alexfru/SmallerC , you can make
a DOS-style .EXE 2nd stage loader, mostly written in C, that would
operate in unreal mode and let you easily do the rest of loading
and what not.
See https://wiki.osdev.org/Unreal_Mode#Smaller_C .

Alex

[Frank Kotler]

On 07/18/2022 06:46 PM, se...@conman.org wrote:
...
> Why not use nasm?

No ".model" directive (AFAIK). Which makes the answer easy...

Best,
Frank

[Frank Kotler]

On 07/19/2022 01:08 AM, Robert Pengelly wrote:
...

> I used to use NASM but it has limitations. One example would be that it only allows one file to be assembled at a time and another example would be far jumps, using nasm -f coff test.asm -o test.o I get "error: COFF format does not support non-32-bit relocations"

COFF is pretty obsolete, no? Why not "-f win32"?

Best,
Frank

[se...@conman.org]

It was thus said that the Great Robert Pengelly <roberta...@gmail.com> once stated:
> On Wednesday, 20 July 2022 at 00:42:49 UTC+1, se...@conman.org wrote:
>>
>> Unless you are trying to write code for MS-DOS, there's no need to deal
>> with segments or far calls at all. There's over 40 years of historical
>> bagage to the Intel x86 line.
>

> There's a need for far calls and segments when dealing with boot loaders
> as they tend to switch between real mode and protected mode. Where there
> are need though is sort of irrelevant, as regardless of the reasons they
> are used other than targeting omf objects there doesn't appear to be a way
> to do 16-bit selector and 32-bit offset using NASM as I keep getting the
> errors.

I checked the Nasm documentation, and the syntax to do a far call is:

CALL seg:offset ; supported by elf format

or

CALL FAR offset ; may not be supported by all formats

Two examples from nasm (both are list files)---the first for 16-bit code:

1 bits 16
2 global foo
3 extern bar
4 00000000 E8(0000) foo: call bar
5 00000003 9A[0000]0C00 call 12:bar
6 00000008 9A[0000][0000] call far bar
7 0000000D C3 ret

and the second for 32-bit code:

1 bits 32
2 global foo
3 extern bar
4 00000000 E8(00000000) foo: call bar
5 00000005 9A[00000000]0C00 call 12:bar
6 0000000C 9A[00000000][0000] call far bar
7 00000013 C3 ret

Both were compiled with "nasm -f obj ...". So it's possible, just not
possible with a Linux-only tool chain.

-spc

[Frank Kotler]

My mistake. Ignore!

Best,
Frank

[Robert Pengelly]

I know the boot sector is too small and shouldn't switch to protected mode that's why I said loader not sector, also this isn't about C compilers its about assemblers and how they function. The nasm -f coff test.asm -o test.o was just an example but win32 produes the exact same message as -f coff.

[Robert Pengelly]

Sorry, forgot that everything got to be specific on here. I know that jmp seg : off is supported by NASM but the fact you can't have
something like:

section .data:
temp:
dd some_offset
dw some_selector

section .text
jump:
jmp far temp

with file formats other than with omf files is a limitation in my opinion (you may have a different opinion).

[Frank Kotler]

Right. I was confused. Nasm's "-f coff" is for djgpp(?).

I may be a little lost as to exactly what we ARE trying to do.

Best,
Frank

[Robert Pengelly]

I was original querying what .model did in MASM to decide on whether it's worth trying to add support for it in a project and people were saying that they use NASM so I said I used to use it and it's turned into a discussion about it.

[Frank Kotler]

Different opinions are no problem. Different syntax might be a problem.
Been a long time since I've tried anything like this. Been doing Linux
lately ... which is kinda pointless...

I'm thinking:
jmp far [temp]
might be what we want, Maybe (maybe!!!) segment and 32-bit offset might
want to be swapped.

Help me get oriented, if you would. We're no longer talking about
".model", right? I'm thinking we want to assemble into -f bin. Are you
with me on this? If not, what? Are we trying to switch real mode to
protected? (second stage loader?) How lost AM I?

Best,
Frank

[Frank Kotler]

Okay.
Back when Ronnie Ray-gun was president, there was a hilarious routine in
which he was answering the question before last. We may be getting into
that...

Try to put me in the picture only if you feel like it.

Best,
Frank

[Robert Pengelly]

I know it's getting confusing, it started of me asking what .model does and sort of got an answer to that from sean yesterday "18 Jul 2022, 23:46:16" (although it's more like a little under 30 hours ago) and he asked at the bottom "Why not use nasm?" so I replied "I used to use NASM but it has limitations" and the conversations continued from there.

[Robert Pengelly]

Sorry looked at the wrong message timestamp sean gave me the answer "18 Jul 2022, 06:10:30" so almost 48 hours ago.

[Robert Pengelly]

It would be a bit easier if you look back at the conversation history. I'm getting a little confused at what the time zones are for the different people so the answer was given in the 10th message in this thread and the rest have been about NASM.

[se...@conman.org]

It was thus said that the Great Robert Pengelly <roberta...@gmail.com> once stated:
>

> I know it's getting confusing, it started of me asking what .model does
> and sort of got an answer to that from sean yesterday "18 Jul 2022,
> 23:46:16" (although it's more like a little under 30 hours ago) and he
> asked at the bottom "Why not use nasm?" so I replied "I used to use NASM
> but it has limitations" and the conversations continued from there.

At first, you were asking about .model from MASM. I answered (a better
answer is here [1]). I only asked about nasm because it appeared you were
trying to do this under Linux. That's it.

About .model---what I said about interoperability with higher level
languages holds true---if you are trying to interoperate with a compiled
language under MS-DOS (about the only operating system this stuff applies
to), then yes, you need to muck about with .model. If everything you are
doing is in assembly, no need to muck about with it at all.

Why does .model exist at all? Because there are programs where you might
need more than 64K of code (in which case, you might have to tell the
compiler to use the medium model), or more than 64K of data (in which case,
you might use the compact model) or an array larger than 64K (in which case
you have to use huge). Why not let the compiler choose? Because a program
might be comprised of multiple source files, or even object files from
multiple languages, and you don't want one object file to assume a data
pointer is just a 16-bit offset, and another one a 16-bit segement and
16-bit offset. Or you want to implement a slow routine in assembly
language, and you need to know the model to generate the right code.

As for the merging of data segments when you selected the small memory
model, yes, that's doing what it's supposed to do---the model only supports
one data segment and one code segment, so I would expect merging of
like-defined segment declarations. If you select large, you probably would
end up with separate data and code segments.

-spc

[1] https://en.wikipedia.org/wiki/X86_memory_models#Memory_models

[Robert Pengelly]

I know you answered it, I said you answered it and thanks for the better answer. All I was doing was catching Frank up on how the conversation progressed, I said about NASM having limitations that you got to work around and everyone starting suggesting different things like %include, -f obj, ect. I develop on Linux, macOS and Windows so I'm familiar to different tools (e.g. GAS, MINGW and NASM, etc), I'm also used to writing assembly I just didn't now what .model did in MASM (or WASM), I tried doing research but could quite understand what was going on hence the original question.