HJWasm

[habran]

DATATYPE is not built in yet ( and I wish to skip it if possible)
I am waiting for the forum's decision 8)

[rrr314159]

Now, it's perfectly obvious from the flow of the code...

3r, You should at least give a few examples to Habran, so that he can derive the logic for HJWasm

- One example, suppose we're using edi for an address, like "mov eax, [edi]". And suppose edi was zeroed previously in the routine; that there's also a statement assigning an address to esi like "lea esi, SomeDataLabel"; and that esi is never used. Then obviously I meant to assign the address to edi instead of esi.

The alternative is, I meant to use esi in the mov statement: "mov eax, [esi]". So HJWasm should simply check if either variation works better than the other, and use that one. It should NOT use the option that screws up the program, instead it should use the one that performs correctly - that's pretty simple isn't it? And if they both work fine, it can flip a coin.

If neither works, it will have to analyze the overall flow more carefully - there may be a few more typos floating around. For instance, perhaps I meant "mov esi, SomeDataLabel" because SomeDataLabel is actually a pointer. Or, perhaps I meant to write "invoke CreateThread,0,0,addr ThreadProc,rbx,0,0" instead of "mov eax, [edi]" - hey anybody can make a couple typos. Just add a little module to HJWasm that corrects the typos, so that the program works right: NOT so that the program works wrong. That's pretty clear isn't it?

Surely an assemblers job is to assemble what you tell it, not for it to attempt to guess at your intention. I don't think there is anyway that it could know you meant mov eax,ecx instead of mov ebx,ecx regardless of the flow.

- That's exactly what they said to the Wright Brothers - and now look at commercial aviation! If that doesn't prove my point, nothing will. I'm afraid you lack vision.

That said do you have any indication as to what potentially is failing in your code rrr? (Is it run-time or assemble time error?, code or macro related?)

- well as i said b4, for 64-bit it's compile-time, for 32-bit it's run-time (after taking care of those two "_dy"'s); and, I'll bet it's macro related. I need to check it more, but won't get around to it for a while. Probably habran can figure it out with that much to go on, after he takes care of the typo issue. Never underestimate the GodFather, you might wind up a floater in the Hudson River, your face eaten away by the crabs ...

re. the vote: I'd go with jj2007's opinion, require the equ statement instead of nokeyword; but whatever habran wants is fine with me, after all he's doing the work

[habran]

Folks, 3rP is just pulling my leg ;)
In his own sneaky way, he is trying to say that he is happy with the development of HJWasm

[johnsa]

Ok,

So we have:

No datatypes, use EQU for ymmword,xmmword,zmmword (if required):     - 2 votes
Option nokeyword:  - 0 votes
Option datatype: - 1 vote

So I say, let's leave it alone.. do the EQUs if you want them? (Less for Habran to do, and he can focus on more interesting tasks). :)


rrr, I'm still not sure I buy into the idea, it's making assumptions rather than following any real logic:

Code Select Expand


xor edi,edi
.
.
.
mov eax,[edi]

could be completely valid.. (For example when reading the IVT in system code).

Code Select Expand


lea esi,SomeDataLabel

This one I can sort of buy into, and could produce something akin to a compiler warning: "ESI assigned to but not used." or something. However once again the test would have to be confined to some level of scope,
say within the current PROC. The expectation may be to load ESI and return from the PROC with ESI set but not used, so in that case you'd get a warning when you don't really need one. I often do that with PROCS that have multiple return values.. so EAX=status, ECX=return count, ESI=ptr to returned data / buffer (even if it's breaking with stdcall/fastcall ABI) I know if I'm the only one using it it's fine and it's not going into a library/hll linkage scenario.

Basically want you're after is a full static-analysis, even in a high level language where the ability to determine the correctness of logic is far easier given the reduced combination of possibilities or usages is still quite hit and miss even using formal logical methods.
I definitely don't think the assembler should ever modify the code, warnings I can live with.. corrupted code due to the assembler "trying" to be smart not so much.

I have an idea floating in my head about how we could address these sorts of issues in the future and it's something that solves some other pain points too:
It's a very simple idea really (however it would probably require a completely new assembler to a degree) or at least the addition of a new front-end pre-parser.

To start with, I would like to add more scoping constructs, one primarily being namespaces.
Then I was thinking instead of a high-level language with inline assembler , what about an assembler with inline high level language?

So imagine something like:

Code Select Expand



MyProc PROC FRAME uses rbx argument1:DWORD, argument2:REAL4, argument3:DWORD
   LOCAL i:DWORD

   mov rsi,argument1
   xor rcx,rcx

   .HLL(exclude rsi,rcx)
      for(i=0;i<argument3;i++)
      {
         [rsi++] = (argument2*2.0f)+sin(argument2) + (float)rcx;
         rcx++;
      }
   .ENDHLL

   ret
MyProc ENDP



Now the HLL parts could be processed via a true compiler model with AST and the expressions, types and correctness could be verified in a way similar to what you are looking for.
The HLL directive would specify which registers to be excluded during register allocation / compilation of the hll code. the HLL code could use variables exactly like a normal HLL, but could also directly manipulate registers as if they were variables.

[johnsa]

In addition it would be nice to add CLASS and METHOD keywords, which do something similar to our OOP macro layers, but built-in with implict THIS ptr if it's declared as a method and not a proc.
Also.. I see no reason why we need to use invoke anymore
we should be able to just call by name with type checking and support for literal strings , float constants etc.

Basically the idea in my head is not so much about a set of specific features but rather lets think about ways to make writing assembler code faster, smarter, better WITHOUT it becoming a new language or just another derivative of C.
1) easier calling syntax
2) support for literals
3) namespace+using
4) class/method support with psuedo-templates.. no inheritance, probably some sort of contractual or prototypal implementation.
5) inline HLL blocks
6) a new standard library with containers (built around class/method), string functions etc..

[jj2007]

Basically want you're after is a full static-analysis, even in a high level language where the ability to determine the correctness of logic is far easier given the reduced combination of possibilities or usages is still quite hit and miss even using formal logical methods.
I definitely don't think the assembler should ever modify the code, warnings I can live with.. corrupted code due to the assembler "trying" to be smart not so much.

I have an idea floating in my head about how we could address these sorts of issues in the future

R3 just made a joke, but I see you are turning the joke into a serious project :t
However, why not use a pre-processor, instead of burdening the assembler with this "external" task? See here for an example.

[johnsa]

I think the idea has merit. Either there is no point in us using asm anymore, or we should be dreaming up "the next big thing".
I often find myself wondering if I should use C/C++ for a project simply because there are some things in asm which are a complete pain.. usually some form of mathematical expression
(I know SmplMath can help with some of that stuff).
(I will ignore the main argument being code maintainability..;)

If we could just "pop up" into some hll lines for some annoying tasks and then carry on in asm, rather than the original paradigm of "drop down" into some inline asm for speed (which you can't do anymore in VC 64bit anyway.. and I don't like linking in separate modules that much).. I think it would be pretty neat.

[jj2007]

If we could just "pop up" into some hll lines for some annoying tasks and then carry on in asm

Great idea :t
(royalties on my bank account please)

[HSE]

Keep the pace!! I wil be expecting the telepathy module  (perhaps typing the same little program at that time).

Btw, because the "so many tokens" error I change the size of line from 600 to 1600, and compiler is not crashing...  yet. 

[habran]

Telepathy module will be available in my estimation about second half of 2031 ;)
We should beware of changing the essence of source code

Johnsa, if I decide to use some Hll, it would be in the first place preprocessor for precompiled headers

[habran]

So we have conclusion for HJWasm about data types: leave it as it is

[johnsa]

Seems so, delete the new operators DY/DZ/DX and just use equates if you want them.

[rrr314159]

Folks, 3rP is just pulling my leg ;)
In his own sneaky way, he is trying to say that he is happy with the development of HJWasm

- True, the telepathy module is a joke, altho it's inspired an interesting discussion which I intend to comment on. But the fact is, neither 32-bit nor 64-bit was working for me - I wouldn't joke about that, because if taken seriously it would cause extra headaches and work chasing down a non-existent bug.

The good news is both are working now. Didn't bother to figure out the problem with 32-bit (which did compile but then ran incorrectly) because the latest version is good. It may pop up again, and turn out to be as simple as the following:

The problem is / was, __JWASM__ is no longer defined: it used to be 211. You changed that to __HJWASM__ (=212).

So I'm all set now but I guess you should leave __JWASM__ defined? Remember when Japheth made his new version constant __JWASM__ but left the old MASM version intact, so as not to break existing code. Doesn't matter to me anymore but it might "gotcha" someone else.

Thanks for your great contributions to the community ... !

[habran]

Are you saying this because you are really satisfied or because you are afraid of the Hudson River

OK, I'll delete the new operators DY/DZ/DX

[jj2007]

the telepathy module is a joke, altho it's inspired an interesting discussion

We had started "FindBugs for Assembler" two years ago, but it was limited to fairly simple things, such as comparing the number of pushs and pops in a procedure. Problem is to test such stuff you need bad code - and here in this forum you'll find only excellent coders