remove the strict mode flag (or revert its meaning)

[Te.Pe.]

Why should an obviously wrong statement be no error without the strict mode flag ?

Assembly language is difficult to learn and understand. Tools should help us and not hiding errors. Strict mode should be the default/always on. If legacy code would not assemble you probably have either a long forgotten bug inside or it was related to issue #64 where error codes from the first pass persisted.

This is a follow-up to issue #60. Imagine the value would be calculated from other symbols. You include some additional code, the value grows and will not fit into the desired space/register. The result would be definitely wrong code. Would you like to allow it ?

BTW: The deleted 'positive' testcases would fail also without strict mode flag. I recommend to include also commit a999a9d into the pull request.

[Te.Pe.]

I commented a working testcase for both with and without -S flag commit c08bc1e

[Mike Saarna]

Why should an obviously wrong statement be no error without the strict mode flag ?

You're only considering the trivial case. If one is working on a target with a program size > 64k, regular label references will be larger than word size. Is it "obviously wrong" that one needs to wrap references to these labels in a (LABEL & 0xffff) construct? Is is serving the user base better to enforce the trivial case (which is obviously wrong) and to force them to use more cumbersome constructs? For me the answer is "no"

[Te.Pe.]

Hello Mike, Mike Saarna schrieb:

Why should an obviously wrong statement be no error without the strict mode flag ? You're only considering the trivial case.

I see this in the view of a developer who has the task to take over the code from another.

If one is working on a target with a program size > 64k, regular label references will be larger than word size. Is it "obviously wrong" that one needs to wrap references to these labels in a (LABEL & 0xffff) construct?

If you state this in the code, other developers will immediately see and understand what was meant. And if you don't state this in the code, the assembler/compiler has to pin-point your attention to it.

Is is serving the user base better to enforce the trivial case (which is obviously wrong) and to force them to use more cumbersome constructs? For me the answer is "no"

It belongs not only to word-wrap. Also byte-wrap is affected. Imagine the targeted processor misses the word adressing mode for an op and the calculated address value becomes > 256. With silently ignoring the wrap the code will fetch the variable from the wrong place. This topic is not about molesting a user/developer. It is to direct the attention of the user/developer to a problematic area in his/her code. And if there are "cumbersome" constructs neccesary, they should be stated and commented in the code. It will enhance maintainability of the code. BTW: The false-positive testcase that I removed would make assembly to fail even without the -S flag. There is no StrictMode flag stated in the the code for .BYTE in function v_dc(). I re-added the strict-less assembling of toobigword to the test-cases again with commit 6898c9c. And for this special case it _IS_ obviously wrong to put 0x10000 into a ".word" or 0x100 into a ".byte". Because ".word" and ".byte" are user-enforced adressing modes. And if the user wants it to be a byte, it should be a byte and nothing bigger. Same analogy with word. And if the user wants it to be the low part of the byte, then there is the need to prefix the value with '<' or wrap the word with an AND-mask. This is something that I call 'precise speaking'. Assemblers/Compilers need precise speaking all the time. Best Regards Thomas Pantzer

[Te.Pe.]

Why should an obviously wrong statement be no error without the strict mode flag ?

[..] Is it "obviously wrong" that one needs to wrap references to these labels in a (LABEL & 0xffff) construct?

No, it is not. With

.word NUMBER

you only tell the assembler "There are two bytes reserved for the next number to be put in"
you are NOT telling "If NUMBER evaluates to something bigger, it is allowed to wrap it".
The second statement is done with the AND mask and was done implicitly without StrictMode. And only you knew about, it's not written/reflected in the code.

I want to be alarmed if there is something that I've not foreseen.

Lets make StrictMode the default! ;-)