Index
> IDE Development > "Fresh" work version with code completitionGoto page Previous 1, 2, 3, 4 Next |
| Author |
|
|
Tommy 11 Jan 2004, 15:32
Good!
 You're welcome! 
Cheers, Tommy |
|||
11 Jan 2004, 15:32 |
|
|
Betov 11 Jan 2004, 16:18
Just curious, John:
How did you fix the GetKeyState Word.dWord problem? (i had the same problem,... and i solved it by doing it all a completely different manner, that i am now happy with, but, i'd like to know your way...). Would be usefull as a Win32 Template. Betov. |
|||
|
11 Jan 2004, 16:18 |
|
|
pelaillo 11 Jan 2004, 17:26
This picture is for the first compilation. The second performs even worst:
19.1 sec And the third is even worst: Fresh crash  (I guess a memory leak)
(The test was: Run Fresh, load fresh.fpr and hit the compile button for the three compilation processes) p.s. The AthlonXP 2600 isn't nominally 2600 MHz, it's only a brand commercial trick and mine is not overclocked.
|
||||||||||
|
11 Jan 2004, 17:26 |
|
|||||||||
|
JohnFound 11 Jan 2004, 19:10
Betov wrote: Just curious, John: Well, it is actually not a problem. I simply read the help not very carefully. The function GetKeyState, returns the value with high-order bit = 1 if the key is pressed and 0 if the key is not pressed. The trick was that the "high-order" bit is actually 15-th bit not 31-th. The other problem is that Win95/98 actually returns 32bit value where the eax is sign extended ax. (movsx eax, ax), so the 15-th bit still have the right value and 31-th bit have the same value as 15-th. In WinXP the high-order word of eax is always 0 (movzx eax, ax), so the only proper way is to check 15-th bit. If you make the test this way it will work on Win95 and WinXP without problems. Code:
test eax, $8000
jnz .pressed
;...or even:
test ax, ax
js .pressed
The strange thing is that WinXP actually returns 16bit result, but Win98 returns 32bit result. And some people claim that Win95 is not truly 32bit OS. 
Regards. Last edited by JohnFound on 11 Jan 2004, 20:30; edited 1 time in total |
|||
|
11 Jan 2004, 19:10 |
|
|
JohnFound 11 Jan 2004, 19:14
pelaillo wrote: This picture is for the first compilation. The second performs even worst: 19.1 sec Hi, pelaillo. It seems that you test the previous not fixed version. There was horrible bug that make huge memory leaks. Please, download the file from this thread, a few posts abouve (I will not remove it, until your next report) and test with it. I tested it with MemProof and there is very minor memory leaks or even none. ( Or I missed something huge.  )
Regards. |
|||
|
11 Jan 2004, 19:14 |
|
|
JohnFound 11 Jan 2004, 23:35
Hi all.
I upload at the site of Fresh the next WORK version with almost finished code completition behaviour and some compilation speed optimisations. For the team: There are changes in StrLib. If someone wants to improve it, please, use this version, it is with faster StrNew function. Regards. |
|||
|
11 Jan 2004, 23:35 |
|
|
JohnFound 12 Jan 2004, 15:14
Hi again.
New work version uploaded... The file have a name: FreshWork1_0_1C_05.rar If you download another file, refresh cashes.
I made some speed improvements and added detailed timing report in compilation messages. Please, give me some detailed feedback how Fresh compiles "Fresh.fpr" on different platforms. Thanks.
|
||||||||||
|
12 Jan 2004, 15:14 |
|
|||||||||
|
ipadilla 12 Jan 2004, 18:57
I am trying to download the new file, but it is not possible. ???
regards ipadilla |
|||
|
12 Jan 2004, 18:57 |
|
|
JohnFound 12 Jan 2004, 19:24
ipadilla wrote: I am trying to download the new file, but it is not possible. Sorry, it is my fault.  It should be OK now.
Regards. |
|||
|
12 Jan 2004, 19:24 |
|
|
Tommy 12 Jan 2004, 20:00
Good news John, I just tested the new version, and guess what: the speed has decreased with 2 seconds (from 8 to 6 secs)
Keep it up! Tommy |
|||
|
12 Jan 2004, 20:00 |
|
|
JohnFound 12 Jan 2004, 20:06
Hi Tommy.
Please, give me some details: Like in my screenshot above (of course text form is OK too) Regards. |
|||
|
12 Jan 2004, 20:06 |
|
|
decard 12 Jan 2004, 20:07
on P266MMX, WinME:
Message Window wrote:
please don't laugh 
It's strange that preprocessing took so much, while on your mashine it was almost equal to assembling time. |
|||
|
12 Jan 2004, 20:07 |
|
|
JohnFound 12 Jan 2004, 20:32
Hi,decard.
Your CPU is approximately twice slower, than mine. ( 266 - 500 MHz ), So you can see, that the stages that requre processor power are approximately only twice slower: Assembling: 12 - 5 Label capturing: 5 - 2.6 But on preprocessing stage, FASM works with file system. So, the low speed is because of WinME, IMHO. It is offtopic ofcourse, but WinME is too heavy for your machine. Better install Win95 (more stabble than 9  or Win98 lite - I am happy with it. Since I install it, my computer simply works without any problems.
Regards. |
|||
|
12 Jan 2004, 20:32 |
|
|
ipadilla 12 Jan 2004, 20:34
Pentium III 450 Hz, Windows 98 SE.
Regards ipadilla
|
||||||||||
|
12 Jan 2004, 20:34 |
|
|||||||||
|
sina 12 Jan 2004, 23:12
the last one was faster for me
this new one is ~+1 seconds p4 2400 winxp pro
|
||||||||||
|
12 Jan 2004, 23:12 |
|
|||||||||
|
JohnFound 12 Jan 2004, 23:36
VeSCeRa wrote: the last one was faster for me Well, visibly I have to make something with preprocessing. It is too slow on almost every machine. But it will be in the next version. I want to finish the whole code completition. There is only one problem remaining - when you type local label begining with dot, Fresh should find what is current parent label and to show only his local labels in the CC box. Ah, and to make CC to work without compiling all the time of course.
Regards. |
|||
|
12 Jan 2004, 23:36 |
|
|
decard 13 Jan 2004, 13:05
What about adding some aligment directives? I made an experiment: I added "align 4" before every subroutine in preproce.inc file, like:
Code: align 4 concatenate_lf: lods byte [esi] cmp al,0Dh je concatenate_ok dec esi jmp concatenate_ok align 4 concatenate_cr: lods byte [esi] cmp al,0Ah je concatenate_ok dec esi concatenate_ok: inc dword [esp] jmp convert_line_data align 4 ignore_comment: lods byte [esi] (...) When I compiled FRESH with this version of preprocessor, I got 17 sec instead of 20. |
|||
|
13 Jan 2004, 13:05 |
|
|
JohnFound 13 Jan 2004, 13:43
decard wrote: What about adding some aligment directives? I made an experiment: I added "align 4" before every subroutine in preproce.inc file, like: Hm, it is interesting. I know that some important procedures in the parser are aligned, but preprocessor is important too. Now I am plaing with implementation of binary search in the parser label lists. It will improve the speed of the parser on big source. Now parser uses linear search, and it is slow. On other hand, for the binary search we will need sorted hash array, that will slow adding new labels, but avery label is adding once, but searching many times. Well, definately it is not a good idea to change FASM sources, but I hope we can convince Privalov, to insert most important changes in the official release. Regards. |
|||
|
13 Jan 2004, 13:43 |
|
|
Betov 13 Jan 2004, 14:19
Aligning Code is not that much important as aligning DATA really IS. So, if FASM does not does this automatically (i suppose it does not), and if this may be the case(s) that some Data that would not be aligned on their own Boundary, this is the very first thing i would do (really twice faster).
Betov. |
|||
|
13 Jan 2004, 14:19 |
|
| Goto page Previous 1, 2, 3, 4 Next < Last Thread | Next Thread > |
Forum Rules:
|