New HJWasm release

[habran]

I was not aware of that :icon_eek:
Here it is:
mingw32-gcc.exe -O3 -DWIN64 -DNDEBUG -I.\H -I"C:\Program Files (x86)\mingw-w64\i686-4.9.2-posix-dwarf-rt_v3-rev0\mingw32\i686-w64-mingw32\bin" -I"C:\Program Files (x86)\CodeBlocks\MinGW\bin" -c "C:\Users\Brane

[TWell]

-m64 isn't in commandline, so resut was 32-bit.

[jj2007]

It seems you picked the right options this time - almost as fast as AsmC :t

Code: [Select]

OxPT_Assembler HJWasm32 ; 3.15
OxPT_Assembler HJWasm64 ; 2.80 secs
Btw where are your bottlenecks? Is loading string arrays and finding matches in these strings one of them?

Code: [Select]

- the FAST option is typically about twice as fast as CRT strstr, but 3..4 times as fast when used with
  MasmBasic string arrays (Intel Core i5 timings for counting a rare word in a file with 800 MB, 6 Mio lines):
232 ms for fast Instr_
795 ms for "normal" Instr_
999 ms for Masm32 InString
929 ms for CRT strstr ;)

[jj2007]

-m64 isn't in commandline, so resut was 32-bit.

Oops, you are right - doping alarm

Btw you could check if you have an old GCC version. Google finds plenty of hits for gcc 64-bit slower than 32-bit, many of them around spring 2014. So maybe the developers have saved the honour of 64-bit compilers in the meantime 8)

[habran]

OK, let see this one, is it x64 ::)

[jj2007]

Is in my test something wrong :icon_confused:

Code: [Select]

OPT_Assembler hjwasm32gcc3 ; 2.7
OxPT_Assembler hjwasm64gcc ; 6.1
OPT_Assembler AsmC ; 2.1 secs
::)

[jj2007]

OK, let see this one, is it x64 ::)

2.55 secs, so far your best one :t

(one little problem: Olly says it's 32-bit code...)

[nidud]

deleted

[jj2007]

The switch still trashes registers

That seems not the only problem. Here is a snippet - try with the latest AsmC and HJWasm versions 8)

Code: [Select]

include \masm32\include\masm32rt.inc

.code
start:
  m2m edi, -5
  .Repeat
print chr$(13, 10)
print str$(edi), 9
.switch edi
.case -4
print "case -4 "
; .break
.case -2
print "case -2 "
; .break
.case 0
print "case 0 "
.break
.case 2
print "case +2 "
.break
.case 4
print "case +4 "
.break
.Default
print "default"
.Endsw
inc edi
  .Until sdword ptr edi>5
  inkey chr$(13, 10, "--- ok? ---")
  exit
end start

[nidud]

deleted

[jj2007]

With AsmC, no options but .break instead, the .break causes an exit of the .Repeat loop. Is that "by design"?

[habran]

Hi nidud,
This code below is a brilliant idea, and I like it a lot, however, it is not applicable in 64 bit because it would force linker LARGEADDRESS  error, while I was writing the code my mind was focused on 64 bit and 32 bit was just conversion from 64 bit, now I see that I have to start to think from 32 bit side if I write 32 bit code 

Code: [Select]

cmp eax,min
jl endsw
cmp eax,max
jg endsw
push eax
movzx eax,index[eax-min]
mov eax,table[eax*4]
xchg eax,[esp]
retn
In the case of jj2007 source, I don't think that any ASM programmer would write such a code that would trash registers that are needed for next iteration.
You can, of course, push register on the stack, and then purposely overwrite that memory on the stack, and than complain that the assembler is not good because it let you overwrite the stack space ::)
If that happened I would not fill sorry for that "programmer"   

[nidud]

deleted

[jj2007]

In the case of jj2007 source, I don't think that any ASM programmer would write such a code that would trash registers that are needed for next iteration ... would not fill sorry for that "programmer"

So far, I have tried to be helpful. Show me one occasion where I insulted you as a "programmer" or similar.

Besides, this is obviously valid code, since edi is a non-volatile register. I perfectly understand why you are pissed off, but please concentrate on your homework instead of attacking others.

[habran]

My intention was not to attack you jj2007, I am grateful for your help and cooperation, and I already said before how much I appreciate you as a programmer, however, I am sure that you would never write this construction in your programs, and you have to admit that