[Coco] Nitros9 Build question

[William Astle]

On 15-01-27 07:55 PM, Bill Pierce via Coco wrote:
>
> Bill the IFP1 error is normal (shouldn't be, but is), but the 2nd error looks fatal.
> I downloaded and built last week and it was fine... but I know there's neem a 'push' since then so something may have gone wrong or something in your files corrupted. I haven't a clue.
>

I figured I'd chime in on the whole IFP1 thing.

First off, it's a *warning*, not an error. In standard parlance that 
means it doesn't cause the build to fail.

Now, on to why lwasm complains about it. The whole IFP1 and IFP2 
conditionals thing is a misfeature of the highest order for any two-pass 
assembler. The whole point of the two directives is to feed the 
assembler different source code for each of the two passes. Any source 
code that needs one of those directives to build correctly is either 
broken itself or, more likely, working around a bug in the assembler.

With a two pass assembler, pass 1 assigns addresses/values to all 
symbols. Then, pass 2 actually outputs the code and probably generates 
the listing at the same time if one is requested.

With that understanding, you can see that by including the os9defs type 
files inside an ifp1 conditional, you get all the symbol definitions on 
pass 1 but on pass 2, no listing for the defs files is produced. This is 
a relatively benign usage and is the absolute only valid usage I can 
think of for such a feature. In this usage, other than generating a 
larger listing than required, it has no impact on the final binary.

lwasm is *not* a two pass assembler. Though it has multiple passes, they 
do not look at all like the traditional passes in a two pass assembler. 
It also reads the source exactly once - it does not re-parse anything on 
subsequent passes. As a result, it is impossible for lwasm to provide 
the expected semantics for those directives, and I have not lost any 
sleep over that because I believe their use to be a bug in nearly every 
case. However, because a lot of source code does include such 
directives, rather than throwing an error, it simply ignores them and 
continues on its way. The warning is to let people know that they're 
doing something unsupported.

It is possible to get the same listing suppression effect with lwasm 
using judicious use of the "*pragmapush", "*pragmapop", and "*pragma" 
directives, all of which can be included inside the include file. 
Figuring out how to do that is left as an exercise for the reader in 
consultation with the lwtools manual. Realistically, someone should do 
this for all the defs files in nitros9 during all that copious spare 
time everyone has.