Post by Gao, LimingI don't get any feedback from others. You also say I can go ahead.
So, I add this change.
Ok. You are right. It is true that I said: "I don't like the idea of
creating the .com for .nasmb sources, but if you insist that it is
required, then you can go ahead."
So, I guess you went ahead.
Can you at least agree that the use of the .com extension is confusing
in this case, since .com files are 16-bit DOS executables? I think the
only reason they appeared in EDK/EDK II is because masm16 would only
output a .com file.
I don't think we need to make everything backward compatible. This is
a new tool without the legacy masm baggage, so do we really need to go
out of our way to bring the masm baggage along?
Really, wouldn't it be reasonable for a platform to make a 1-line
change to their .fdf file if for no other reason than to make it
obvious that a big change just happened to their SEC phase?
This project goes *way* out of it's way to try to be backward
compatible. In my opinion, often too far.
Ok. Rant complete. Thanks for your time, :)
-Jordan
Post by Gao, LimingI add this support for compatibility. I want to update our core
module to use .nasmb, and platform can directly use the updated
core module without changes. Now, our most platforms use .com
postfix in their platform FDF Ffs Rule. With this patch, after we
update more core modules to use .nasmb instead .asm16, it will not
impact platforms.
Thanks
Liming
-----Original Message-----
From: Justen, Jordan L
Sent: Tuesday, June 9, 2015 12:56 AM
Subject: RE: [edk2] [Patch] BaseTools: Update nasmb build rule
Post by Jordan JustenPost by Gao, LimingNASMB is replacement of ASM16.
I see .nasmb as an alternative, but not a replacement. (.asm16 is
still supported by EDK II.)
I do hope that long term it replaces all uses of .asm16 though. :)
Post by Gao, LimingNow, ASM16 has been used in the
different modules. When the module owners do this conversion, they
expect it is compatible and doesn't impact platform, because
module owner can't predict how many platform will be impacted. So,
I think the compatibility is the important point to persuade the
module owners to do this conversion.
I would rather see .bin be used in this case, because it makes more
sense than .com. I guess .com was used because it was the output from
link16? But, .com files are known as old dos based executables. It is
a confusing use of the extension.
I see you went ahead and committed this without further discussion.
I also see that you converted an internal platform's fdf from being
able to accept either .bin or .com to only accept .com. So,
apparently you have real preference for using .com rather than .bin.
Can you explain why you think .com makes better sense than .bin in this context?
http://en.wikipedia.org/wiki/COM_file
-Jordan
Post by Jordan JustenIf we copy the file like in your patch, then few platforms will
actually change from using .com to .bin, but I think it would be an
improvement for them to convert to using the .bin extension.
Maybe another idea is to leave the .asm16 .inf in place, and create a
new .inf with the .nasmb source. Then the platform will have to change
both the .dsc and .fdf to make use of NASM. This will also leave the
platform with the option to continue using MASM16/LINK16.
I don't like the idea of creating the .com for .nasmb sources, but if
you insist that it is required, then you can go ahead. I will not give
my r-b for the change though. :)
-Jordan
Post by Gao, Liming-----Original Message-----
From: Justen, Jordan L
Sent: Friday, November 21, 2014 12:58 PM
Subject: Re: [edk2] [Patch] BaseTools: Update nasmb build rule
Post by Gao, LimingNasmb can replace ASM16. Now, ASM16 output file is *.com. To be
compatible with it, update nasmb build rule to output *.com file also.
ASM16 output file is used by Platform FDF Rule section. With this
patch, Platform FDF file will not be impacted after asm16 file is
converted to nasmb file.
Liming,
I don't think we need this change. With a small change to the .fdf, .bin can work as easily as .com.
I think .com was a bad extension for this file, even when
masm16/link16 was being used. Maybe we should have copied from .com to .bin before.
-Jordan
Post by Gao, LimingContributed-under: TianoCore Contribution Agreement 1.0
---
Index: build_rule.template
==================================================================
=
--- build_rule.template (revision 16400)
+++ build_rule.template (working copy)
@@ -491,8 +491,8 @@
"$(PP)" $(PP_FLAGS) $(INC) ${src} >
${d_path}(+)${s_base}.i
Trim --source-code --convert-hex -o
${d_path}(+)${s_base}.iii $ {d_path}(+)${s_base}.i
"$(NASM)" -I${s_path}(+) -l ${d_path}(+)${s_base}.lst
$(NASMB_FLAGS) -o $dst ${d_path}(+)${s_base}.iii
+ $(CP) ${dst} $(OUTPUT_DIR)(+)${s_base}.com
-
[Microcode-File.USER_DEFINED, Microcode-File.Microcode]
<InputFile>
?.txt, ?.TXT, ?.Txt, ?.mut, ?.inc
---
Thanks
Liming
------------------------------------------------------------------------------