Twenty Years Too Late

Hrm...

Sorry, I've in fact been "hiding", although the intention was just that of staying off the internet to... uhm... improve productivity. It didn't improve, it just improved mostly useless insights.

I kept thinking to Lino3 syntax, so far bringing to almost full backward compatibility with Lino2, and for the rest implementing several new things, including... well, structured conditionals. I'm not transforming it into a strictly structured form of assembly: loops and subroutines are still formally unbounded (subs may have multiple return points, loops are still implemented via conditioned jumps, iterators or anything else that may fit), but conditioned jumps in Lino3 will likely be largely replaced by conditional blocks. Their mark-up will make use of a sign that may remind something from Lino1, but with a completely different purpose: the "=>" sign; I didn't want to create confusion with the way subs were called in version 1, I just found it to be the best candidate to represent a symbolic "if...then" construct, given that it closely reminds the double arrow commonly used to represent material implications. I mean, a conditional block is written as:

a = b =>        (which may be read as "a = b" IMPLIES...)

  some instruction;
  some other instruction;
  etc;

;

And terminates with a single semicolon, which otherwise, in lack of a conditional branch to be closed, would still translate to a "leave" tag. The "else" construct and jump threading (merging of jumps to a same location) is also handled by the version-3 compiler, so you could write:

a = b =>

  some code;

;

else =>

  some other code;

;

> some label;

...and expect "some code" to be followed by an unconditioned jump to "some label", placed there automatically by the compiler. Short-circuit OR operators are also supported. Short-circuit ANDs are not, because I find them redundant: it's probably more intuitive to nest two or more conditional blocks to represent an "AND".

I'm currently working on one-line conditionals (which don't open a branch and are used to conditionally execute single instructions) that could also perform "calls on condition", which had been implemented (although never made public) in a different way.

The Argent's central frame was completed in August, after which I was supposed to work on the wings. I had spotted several points where the wings may be stressed beyond the limits of their 6061 T6 aluminum, and was proceeding to add reinforcements, but got bored along the way.

um... I'd better just post about the news in more detail, later.

Whoa, quite annoying! It's not even the first time it occurs. I'm guessing the various antivirus algorithms are getting suspicious due to low-level optimizations in the run-time module. I may be wrong but I get the feeling that, possibly, nowadays the most "popular" use of 100% assembly coding in Windows PE executables is for writing malware, so files with code emitted by a standard C-or-higher compiler go unnoticed, while seeing "unusual" things such as Intel-specific short loops, three-operand LEAs, XORs for zeroing registers, and other tricks for shortening the size of the resulting machine language reminds them of similar coding found in malware. Or perhaps it's the fact that Linoleum apps are loaded by the RTM and them execution of their thread is re-located to a self-allocated memory area containing raw code, read straight there using the filesystem API.

I'll try to contact them and explain as clearly as possible that the problem lays in the run-time module which is part of every application.