1. Rob: Bug with Windows trasking translator
Rob,
It seems the Watcom translator for Windows isn't working for me. I've tried
translating/compiling taskwire.exw and it translates ok and will open and have
the message and delay. But after that, the program just quickly closes with no
error or anything. It does the same thing on all the Windows programs I've tried.
Borland and DOS Watcom translators seem to work OK. I haven't tried LCC.
This is rather nasty since the translator produces an executable that is
completely unfunctionable.
Regards,
Vincent
2. Re: Rob: Bug with Windows trasking translator
Vincent wrote:
> It seems the Watcom translator for Windows isn't working for me. I've tried
> translating/compiling taskwire.exw and it translates ok and will open and have
> the message and delay. But after that, the program just quickly closes with
> no error or anything. It does the same thing on all the Windows programs I've
> tried.
>
> Borland and DOS Watcom translators seem to work OK. I haven't tried LCC.
>
> This is rather nasty since the translator produces an executable that is
> completely
> unfunctionable.
I just tried it again here, and it worked.
ecw -wat taskwire
emake
taskwire
The message appeared, and then it started running ok.
Make sure you have the new (PD) version of ecw.lib in your euphoria\bin.
It's 99,328 bytes.
Or, I suppose it could be an incompatibility between
Open Watcom and Watcom 10.6
You could see where it dies by adding:
with trace
trace(3)
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Rob: Bug with Windows trasking translator
Robert Craig wrote:
>
> I just tried it again here, and it worked.
> ecw -wat taskwire
> emake
> taskwire
> The message appeared, and then it started running ok.
>
> Make sure you have the new (PD) version of ecw.lib in your euphoria\bin.
> It's 99,328 bytes.
>
> Or, I suppose it could be an incompatibility between
> Open Watcom and Watcom 10.6
>
> You could see where it dies by adding:
> with trace
> trace(3)
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Yea that is what I did. But it still doesn't work and no trace file is produced.
Everything works with official 2.5 translator. The machine code you added to the
"ecw.lib" static library might be causing the incompatability?
Maybe you could download Open Watcom 1.4 on a different Windows computer and try
to debug the problem? If you can fix it, then maybe test it on Watcom 10.6 again?
I'm sorry I can't help you out more. The translated programs just arn't doing
anything. So I'm pretty clueless as to what exactly might be causing this.
Maybe you can see what you can do? I don't really want to downgrade my compiler
or use Borland to overcome this.
Sorry,
Vincent
4. Re: Rob: Bug with Windows trasking translator
Vincent wrote:
> Yea that is what I did. But it still doesn't work and no trace file is
> produced.
>
>
> Everything works with official 2.5 translator. The machine code you added to
> the "ecw.lib" static library might be causing the incompatability?
>
> Maybe you could download Open Watcom 1.4 on a different Windows computer and
> try to debug the problem? If you can fix it, then maybe test it on Watcom 10.6
> again?
>
> I'm sorry I can't help you out more. The translated programs just arn't doing
> anything. So I'm pretty clueless as to what exactly might be causing this.
>
> Maybe you can see what you can do? I don't really want to downgrade my
> compiler
> or use Borland to overcome this.
I'll download Open Watcom 1.4 tomorrow and see what happens.
And maybe someone else with Open Watcom 1.4 can try the
multitasking release and let us know if:
ecw -wat taskwire
emake
produces a usable .exe file.
It's probably something minor, since, as you say,
2.5 official works fine.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
5. Re: Rob: Bug with Windows trasking translator
Robert Craig wrote:
>
> Vincent wrote:
> > It seems the Watcom translator for Windows isn't working for me. I've tried
> > translating/compiling taskwire.exw and it translates ok and will open and
> > have
> > the message and delay. But after that, the program just quickly closes with
> > no error or anything. It does the same thing on all the Windows programs
> > I've
> > tried.
> >
> > Borland and DOS Watcom translators seem to work OK. I haven't tried LCC.
> >
> > This is rather nasty since the translator produces an executable that is
> > completely
> > unfunctionable.
>
> I just tried it again here, and it worked.
> ecw -wat taskwire
> emake
> taskwire
> The message appeared, and then it started running ok.
>
> Make sure you have the new (PD) version of ecw.lib in your euphoria\bin.
> It's 99,328 bytes.
>
> Or, I suppose it could be an incompatibility between
> Open Watcom and Watcom 10.6
>
> You could see where it dies by adding:
> with trace
> trace(3)
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
The same as Vincent. New PD version, no windows programs work with Open Watcom.
Nag screen OK and then abruptly finish with no trace information (added with
trace, trace(3)).
JG
6. Re: Rob: Bug with Windows trasking translator
Julio C. Galaret Viera wrote:
> The same as Vincent. New PD version, no windows programs work with Open
> Watcom.
> Nag screen OK and then abruptly finish with no trace information (added with
> trace, trace(3)).
OK, thanks. That's useful information.
I think it's probably a small problem in
the extra start-up code I added for multitasking.
Maybe a linker issue. I'll fix it.
Thanks,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
7. Re: Rob: Bug with Windows trasking translator
Robert Craig wrote:
> OK, thanks. That's useful information.
> I think it's probably a small problem in
> the extra start-up code I added for multitasking.
> Maybe a linker issue. I'll fix it.
When you fix it, could you re-upload the zip file to the archive so we can do
more testing with it using Open Watcom?
So far everything else seems to be working fine, but I'll let you know if I run
into any more problems; I'm sure others will do the same.
Thanks,
Vincent
8. Re: Rob: Bug with Windows trasking translator
Vincent wrote:
> Robert Craig wrote:
> > OK, thanks. That's useful information.
> > I think it's probably a small problem in
> > the extra start-up code I added for multitasking.
> > Maybe a linker issue. I'll fix it.
>
> When you fix it, could you re-upload the zip file to the archive so we can do
> more testing with it using Open Watcom?
Yes. I'm going to do that as soon as it's fixed.
> So far everything else seems to be working fine, but I'll let you know if I
> run into any more problems; I'm sure others will do the same.
Thanks,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
9. Re: Rob: Bug with Windows trasking translator
Vincent wrote:
> Robert Craig wrote:
> > OK, thanks. That's useful information.
> > I think it's probably a small problem in
> > the extra start-up code I added for multitasking.
> > Maybe a linker issue. I'll fix it.
>
> When you fix it, could you re-upload the zip file to the archive so we can do
> more testing with it using Open Watcom?
>
> So far everything else seems to be working fine, but I'll let you know if I
> run into any more problems; I'm sure others will do the same.
I have installed Open Watcom 1.4, and rebuilt everything with it.
Things are working fine. In fact, with the new Watcom, the
tasksort demo runs 5.7x faster! (Most of the time is spent inside
a line drawing routine in the Watcom graphics library.)
I've also found why people with Open Watcom could not
translate/compile the taskwire.exw demo and make it run.
The fix is very simple. You can do it yourself if you like:
After running:
ecw -wat taskwire
Edit the file objfiles.lnk.
After the line that says:
OPTION STACK=1048576
add a new line:
COMMIT STACK=1048576
Then run emake. taskwire.exe should then run ok.
1048576 is the normal default maximum stack space on Windows,
but I've added a translator option (-stack nnn) to set this
explicitly now, and I need to commit it to avoid a page fault.
With Watcom 10.6, there was no need for "COMMIT", since it
defaulted correctly. But with Open Watcom, I must state the
COMMIT value explicitly, or a very small value will be chosen
by default. The commit value is the amount of stack space
to reserve initially when the program starts running.
I'll do some more tests, and upload a
fix tomorrow sometime.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
10. Re: Rob: Bug with Windows trasking translator
Robert Craig wrote:
> I have installed Open Watcom 1.4, and rebuilt everything with it.
> Things are working fine. In fact, with the new Watcom, the
> tasksort demo runs 5.7x faster! (Most of the time is spent inside
> a line drawing routine in the Watcom graphics library.)
>
> I've also found why people with Open Watcom could not
> translate/compile the taskwire.exw demo and make it run.
>
> The fix is very simple. You can do it yourself if you like:
> After running:
> ecw -wat taskwire
> Edit the file objfiles.lnk.
> After the line that says:
> OPTION STACK=1048576
> add a new line:
> COMMIT STACK=1048576
> Then run emake. taskwire.exe should then run ok.
>
> 1048576 is the normal default maximum stack space on Windows,
> but I've added a translator option (-stack nnn) to set this
> explicitly now, and I need to commit it to avoid a page fault.
> With Watcom 10.6, there was no need for "COMMIT", since it
> defaulted correctly. But with Open Watcom, I must state the
> COMMIT value explicitly, or a very small value will be chosen
> by default. The commit value is the amount of stack space
> to reserve initially when the program starts running.
>
> I'll do some more tests, and upload a
> fix tomorrow sometime.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Now works!
In my old windows machine (166 Mhz, 32 MB RAM) is evident the slowdown produced
by «with trace» that let appreciate the exact order in which the «Es» move: the
first and then the second, and so on.
Not so obvius the speed gained in compiled versus interpreted.
Great Job!
JG
11. Re: Rob: Bug with Windows trasking translator
Robert Craig wrote:
> I have installed Open Watcom 1.4, and rebuilt everything with it.
> Things are working fine. In fact, with the new Watcom, the
> tasksort demo runs 5.7x faster! (Most of the time is spent inside
> a line drawing routine in the Watcom graphics library.)
{^.^}
5.7x faster? What?!?!? Say that again I didn't hear you real well! Is that when
interpreted or translated? I take it this speed increase isn't typical across
most programs?
> I've also found why people with Open Watcom could not
> translate/compile the taskwire.exw demo and make it run.
>
> The fix is very simple. You can do it yourself if you like:
> After running:
> ecw -wat taskwire
> Edit the file objfiles.lnk.
> After the line that says:
> OPTION STACK=1048576
> add a new line:
> COMMIT STACK=1048576
> Then run emake. taskwire.exe should then run ok.
>
> 1048576 is the normal default maximum stack space on Windows,
> but I've added a translator option (-stack nnn) to set this
> explicitly now, and I need to commit it to avoid a page fault.
> With Watcom 10.6, there was no need for "COMMIT", since it
> defaulted correctly. But with Open Watcom, I must state the
> COMMIT value explicitly, or a very small value will be chosen
> by default. The commit value is the amount of stack space
> to reserve initially when the program starts running.
>
> I'll do some more tests, and upload a
> fix tomorrow sometime.
Well I'm glad you figured out what the problem was. I must admit I got a bit
worried there. I feel much better now. 
Thanks,
Vincent
12. Re: Rob: Bug with Windows trasking translator
Vincent wrote:
> Robert Craig wrote:
> > I have installed Open Watcom 1.4, and rebuilt everything with it.
> > Things are working fine. In fact, with the new Watcom, the
> > tasksort demo runs 5.7x faster! (Most of the time is spent inside
> > a line drawing routine in the Watcom graphics library.)
>
> {^.^}
>
> 5.7x faster? What?!?!? Say that again I didn't hear you real well! Is that
> when
> interpreted or translated? I take it this speed increase isn't typical across
> most programs?
I had profile_time'd this demo earlier, and found that
96% of the time was spent, not in sorting, but rather
in the Watcom DOS routine for drawing line segments.
I had also noticed that it ran much faster when
translated/compiled with DJGPP + Allegro (sorry, no exact timings).
Anyway, the demo now runs *much* faster (5.7x) with Open Watcom 1.4
than with the old Watcom 10.6. I measured the ex.exe interpreter,
but the translator shows a similar, perhaps a tad better,
speed-up. This speed-up will likely affect some other DOS graphics
programs, but I wouldn't expect a big speed-up on typical programs.
I'll do some more benchmarking soon.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
13. Re: Rob: Bug with Windows trasking translator
- Posted by Vincent <darkvincentdude at yahoo.com>
Feb 15, 2006
-
Last edited Feb 16, 2006
Robert Craig wrote:
> I had profile_time'd this demo earlier, and found that
> 96% of the time was spent, not in sorting, but rather
> in the Watcom DOS routine for drawing line segments.
> I had also noticed that it ran much faster when
> translated/compiled with DJGPP + Allegro (sorry, no exact timings).
> Anyway, the demo now runs *much* faster (5.7x) with Open Watcom 1.4
> than with the old Watcom 10.6. I measured the ex.exe interpreter,
> but the translator shows a similar, perhaps a tad better,
> speed-up. This speed-up will likely affect some other DOS graphics
> programs, but I wouldn't expect a big speed-up on typical programs.
> I'll do some more benchmarking soon.
Interesting...
Any speed up with Windows programs? Perhaps also benchmark the DOS time()
function to see if that speed-up any? You could also try a sieve test and see if
that speed up a tiny bit on both DOS and Windows?
Now that you're using the latest Watcom, you can see about removing Watcom 10.6
bug work around code too. That may help improve overall performance even more.
Excellent,
Vincent
14. Re: Rob: Bug with Windows trasking translator
The update fixed the problem with Open Watcom, thanks.
I looked at the tasksort demo in the new update, but I couldn't notice any
performance increase. Wouldn't a 5.7x speed up be noticable? How come when I move
my mouse it increases sorting speed? It does it with both releases.
Also, I keep running into this error message when I translate/compile with a
large value assigned to the NTASKS constant in the taskwire example:
Fatal run-time error:
Task 0 (initial task) exceeded its stack size limit of XXXX bytes
I don't think it's a bug, but I think you should increase whatever stack limit
it's mentioning because the problem runs fine interpreted.
Regards,
Vincent
15. Re: Rob: Bug with Windows trasking translator
Vincent wrote:
> The update fixed the problem with Open Watcom, thanks.
>
> I looked at the tasksort demo in the new update, but I couldn't notice any
> performance
> increase. Wouldn't a 5.7x speed up be noticable?
You don't have the new ex.exe built with Open Watcom, nor do you have
ec.lib built with Open Watcom, so you won't see any
performance increase. Everything was built with 10.6,
except the updated file today, ecw.exe, which doesn't
affect performance.
> How come when I move my mouse
> it increases sorting speed? It does it with both releases.
Interesting. It does that for me too. I never noticed before.
Maybe XP is giving the program more CPU time when the mouse
is moving. Strange.
> Also, I keep running into this error message when I translate/compile with a
> large value assigned to the NTASKS constant in the taskwire example:
>
> Fatal run-time error:
> Task 0 (initial task) exceeded its stack size limit of XXXX bytes
>
> I don't think it's a bug, but I think you should increase whatever stack limit
> it's mentioning because the problem runs fine interpreted.
If you get that error, you have to use the new translator option (-stack):
ecw -wat -stack nnnn taskwire.exw
and choose a larger size. (nnnn is the size in bytes. 1048576 bytes is
the default for Windows - see objfiles.lnk). Each task has its own
call stack. The interpreter can grow the call stacks dynamically
as required. The Translator needs you to pick a fixed size at
translation time. For most programs there won't be any problem,
but if you want to have a zillion tasks running simultaneously,
or you want to have very deep recursion, you will have to
build your .exe with a larger stack space.
Regarding Open Watcom 1.4, I've encountered a potentially fatal
problem with it. Whenever I run ex.exe, built by Open Watcom,
it immediately switches the command-prompt window to full-screen.
It's very annoying. I went through the code and identified
3 or 4 places in the ex.exe start-up code where the window
is forced to full-screen. Basically, any call to Watcom's
library that does anything related to the screen. Even with those
3 or 4 places commented-out, it will still do it when the
Euphoria program prints on the screen. It doesn't do that with 10.6.
I wonder if anyone knows of a fix for this.
I also tried right-clicking and setting the properties of ex.exe,
but nothing seemed to fix the problem.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
16. Re: Rob: Bug with Windows trasking translator
Robert Craig wrote:
[snip]
> Regarding Open Watcom 1.4, I've encountered a potentially fatal
> problem with it. Whenever I run ex.exe, built by Open Watcom,
> it immediately switches the command-prompt window to full-screen.
> It's very annoying. I went through the code and identified
> 3 or 4 places in the ex.exe start-up code where the window
> is forced to full-screen. Basically, any call to Watcom's
> library that does anything related to the screen. Even with those
> 3 or 4 places commented-out, it will still do it when the
> Euphoria program prints on the screen. It doesn't do that with 10.6.
> I wonder if anyone knows of a fix for this.
> I also tried right-clicking and setting the properties of ex.exe,
> but nothing seemed to fix the problem.
I have compiled ex_r.exe with OW1.4 just now.
It starts in command-prompt window, doesn't output any prompt,
then switches to full-screen and then outputs its usual prompt.
'Alt Enter' switches screen to command-prompt window and back
to full-screen.
I think, it is not that bad behaviour, just a DOS32 program
starts as pure DOS program.
And it seems to me that nasty bug - if you forget machine_proc(5,-1)
before the end of your DOS32 graphics program - is gone now,
with this OW1.4.
Regards,
Igor Kachan
kinz at peterlink.ru
17. Re: Rob: Bug with Windows trasking translator
Robert Craig wrote:
> You don't have the new ex.exe built with Open Watcom, nor do you have
> ec.lib built with Open Watcom, so you won't see any
> performance increase. Everything was built with 10.6,
> except the updated file today, ecw.exe, which doesn't
> affect performance.
Well that certainly explains it. 
> If you get that error, you have to use the new translator option (-stack):
>
> ecw -wat -stack nnnn taskwire.exw
>
> and choose a larger size. (nnnn is the size in bytes. 1048576 bytes is
> the default for Windows - see objfiles.lnk). Each task has its own
> call stack. The interpreter can grow the call stacks dynamically
> as required. The Translator needs you to pick a fixed size at
> translation time. For most programs there won't be any problem,
> but if you want to have a zillion tasks running simultaneously,
> or you want to have very deep recursion, you will have to
> build your .exe with a larger stack space.
OK, I see now. That option will be quite useful then.
> Regarding Open Watcom 1.4, I've encountered a potentially fatal
> problem with it. Whenever I run ex.exe, built by Open Watcom,
> it immediately switches the command-prompt window to full-screen.
> It's very annoying. I went through the code and identified
> 3 or 4 places in the ex.exe start-up code where the window
> is forced to full-screen. Basically, any call to Watcom's
> library that does anything related to the screen. Even with those
> 3 or 4 places commented-out, it will still do it when the
> Euphoria program prints on the screen. It doesn't do that with 10.6.
> I wonder if anyone knows of a fix for this.
> I also tried right-clicking and setting the properties of ex.exe,
> but nothing seemed to fix the problem.
This has been happening since day one for me with the translator. It isn't a big
deal, just press "Alt-Enter" to restore windowed mode. I agree that it's a little
annoying, but it certainly isn't a critical flaw worth deleting a perfectly good
compiler with nearly hundreds of bug fixes,
new features, improvements, and optimizations since the 10.x series.
Remember we're talking about DOS here, I hardly ever read any DOS related
discussions on the EUforum, which makes me suspect that few people are using it
anymore. In fact, I doubt that many people would care if you one day decided to
drop support for it (however Igor and I might get upset).
I dont know of a way to bypass this, but perhaps you might find something in the
Watcom C manual: ttp://www.openwatcom.org/ftp/manuals/c_readme.pdf
If not, maybe you can request it for a later release of Open Watcom if it is
really all that important to you.
Regards,
Vincent
18. Re: Rob: Bug with Windows trasking translator
Vincent wrote:
>
(snip)
> This has been happening since day one for me with the translator. It isn't a
> big deal, just press "Alt-Enter" to restore windowed mode. I agree that it's
> a little annoying, but it certainly isn't a critical flaw worth deleting a
> perfectly
> good compiler with nearly hundreds of bug fixes,
> new features, improvements, and optimizations since the 10.x series.
But at the same time the Euphoria code works and works well so those bug fixes
and to a lesser extent the optimizations aren't necessary for Euphoria.
Personally I would prefer to not have to press Alt-Enter everytime I run a
Euphoria program. However, it might be worth looking into how previous versions
of OpenWatcom handle it. If OpenWatcom 1.2 doesn't maximize the window then Rob
could experiment using that.
> Remember we're talking about DOS here, I hardly ever read any DOS related
> discussions
> on the EUforum, which makes me suspect that few people are using it anymore.
> In fact, I doubt that many people would care if you one day decided to drop
> support for it (however Igor and I might get upset).
For command line only things I always use the DOS interpreter because it's one
less character I have to type and it's the lowest common denominator for Euphoria
meaning if it works with the DOS version it'll (almost) always work with the
other ones (except system() calls). I also mess around with FreeDOS alot and all
our instruments at the place I work at use DOS so I would very much like to be
able to use Euphoria on those platforms.
The Euphoria Standard Library project :
http://esl.sourceforge.net/
The Euphoria Standard Library mailing list :
https://lists.sourceforge.net/lists/listinfo/esl-discussion
19. Re: Rob: Bug with Windows trasking translator
D. Newhall wrote:
> But at the same time the Euphoria code works and works well so those bug fixes
> and to a lesser extent the optimizations aren't necessary for Euphoria.
> Personally
> I would prefer to not have to press Alt-Enter everytime I run a Euphoria
> program.
> However, it might be worth looking into how previous versions of OpenWatcom
> handle it. If OpenWatcom 1.2 doesn't maximize the window then Rob could
> experiment
> using that.
Yes but Rob had to work around a bug with Watcom 10.6 in the back-end that
slightly affects performance. Euphoria can never have enough optimizations, not
even if it had performance identical to highly optimized C code yet had room for
more optimization. Also, you wouldn't need to press "Alt-Enter" everytime, many
DOS programs are full-screen anyway. As for text-mode apps, people should really
use EXWC anyway. Open Watcom 1.0, 1.1, 1.2, etc. are all the same way too. This
isn't a bug; if there isn't a way to disable it, then it was meant to be this way
for some reason.
I'd prefer not needing to "Alt-Enter", but I much rather have a 5x speed
increase with DOS pixel mode graphics and a small overall speed increase with
Euphoria. But Robert may find a way to disable it, so we still might be able to
have our apple pie and eat it too.
> For command line only things I always use the DOS interpreter because it's one
> less character I have to type and it's the lowest common denominator for
> Euphoria
> meaning if it works with the DOS version it'll (almost) always work with the
> other ones (except system() calls). I also mess around with FreeDOS alot and
> all our instruments at the place I work at use DOS so I would very much like
> to be able to use Euphoria on those platforms.
>
Fair enough. I use the DOS one all the time. I'm just saying that it seems it's
popularity has declined drastically with the introduction of Windows, Linux, and
FreeBSD Euphoria.
> The Euphoria Standard Library project :
> <a href="http://esl.sourceforge.net/">http://esl.sourceforge.net/</a>
> The Euphoria Standard Library mailing list :
> <a
> href="https://lists.sourceforge.net/lists/listinfo/esl-discussion">https://lists.sourceforge.net/lists/listinfo/esl-discussion</a>
Regards,
Vincent
20. Re: Rob: Bug with Windows trasking translator
Robert Craig wrote:
<snip>
> Regarding Open Watcom 1.4, I've encountered a potentially fatal
> problem with it. Whenever I run ex.exe, built by Open Watcom,
> it immediately switches the command-prompt window to full-screen.
> It's very annoying. I went through the code and identified
> 3 or 4 places in the ex.exe start-up code where the window
> is forced to full-screen. Basically, any call to Watcom's
> library that does anything related to the screen. Even with those
> 3 or 4 places commented-out, it will still do it when the
> Euphoria program prints on the screen. It doesn't do that with 10.6.
> I wonder if anyone knows of a fix for this.
> I also tried right-clicking and setting the properties of ex.exe,
> but nothing seemed to fix the problem.
Since I learned to know Euphoria (i.e. since version 2.3) I *always* had
this problem on Windows 98. When I translate/compile a Euphoria DOS
program, I use DJGPP instead of Watcom in order to avoid this problem.
But there is no alternative for ex.exe, and the mentioned behaviour is
very annoying indeed! Rob, it would be really nice if you would find a
way to fix this problem.
Regards,
Juergen
--
Have you read a good program lately?
21. Re: Rob: Bug with Windows trasking translator
- Posted by Robert Craig <rds at RapidEuphoria.com>
Feb 20, 2006
-
Last edited Feb 21, 2006
Juergen Luethje wrote (re pop to full screen):
> Since I learned to know Euphoria (i.e. since version 2.3) I *always* had
> this problem on Windows 98. When I translate/compile a Euphoria DOS
> program, I use DJGPP instead of Watcom in order to avoid this problem.
> But there is no alternative for ex.exe, and the mentioned behaviour is
> very annoying indeed! Rob, it would be really nice if you would find a
> way to fix this problem.
As I recall, on Win95/98, it would go to full screen the first
time you ran ex.exe in a new DOS window, but after you pressed
Alt-Enter, it would switch back to a normal window, and it
would stay normal after that. With OW 1.4, it goes back to full screen
*every* time you run it.
I find out something surprising today.
Because of the tasksort.ex demo, I was led to believe
that OW 1.4 was over 5x faster on DOS graphics, namely
drawing line segments. I now see that this is not true.
Actually, the difference is in the cost of executing
the time() function (inside the task scheduler).
I was fooled because Euphoria's time() function speeds
up tremendously (factor of 100) when "with profile_time"
is in effect. In that situation, I handle hardware clock interrupts
myself, instead of relying on a call to DOS. The profile_time
showed over 95% of the time being spent drawing line segments,
so I assumed OW 1.4 must be *much* faster at doing that.
Actually, in the normal case, with no profile_time, the scheduler,
which calls time(), takes a very large chunk of the time.
Although, even in the worst case, time() requires less than a millisecond
to execute, it adds up quickly when you are yielding every few statements,
as in the tasksort demo.
I also confirmed this by trying the wire.ex demo, which
doesn't use multitasking. It ran at the same speed, 10.6 or OW.
It displays lots of line segments at various angles.
I don't know why moving the mouse speeds up the time() function,
but both involve hardware interrupts.
As a result of all this, I went through task_yield() and the scheduler,
and minimized the number of calls to time(). Now there is always
just one call, instead of two or three. tasksort now runs twice as fast
with 10.6.
I could *always* use the interrupt handling method, instead of
calling the DOS time function, but I found XP seems to miss some
interrupts, and the time can be off by 10% or so. This didn't
happen on the earlier systems. Also, there might be a problem
on some systems, if your program crashes (due to a hardware exception),
while clock interrupt handling has been altered. Your time might
advance too slow or too fast, at least under DOS.
Anyway, on Windows, Linux and FreeBSD this is not an issue
since time() is very fast.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
22. Re: Rob: Bug with Windows trasking translator
- Posted by Bernie Ryan <xotron at bluefrog.com>
Feb 20, 2006
-
Last edited Feb 21, 2006
Why not use a pif file an set the pif file to start up
in dos window mode ?
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
23. Re: Rob: Bug with Windows trasking translator
- Posted by Vincent <darkvincentdude at yahoo.com>
Feb 20, 2006
-
Last edited Feb 21, 2006
Robert Craig wrote:
> I found out something surprising today.
> Because of the tasksort.ex demo, I was led to believe
> that OW 1.4 was over 5x faster on DOS graphics, namely
> drawing line segments. I now see that this is not true.
> Actually, the difference is in the cost of executing
> the time() function (inside the task scheduler).
> I was fooled because Euphoria's time() function speeds
> up tremendously (factor of 100) when "with profile_time"
> is in effect. In that situation, I handle hardware clock interrupts
> myself, instead of relying on a call to DOS. The profile_time
> showed over 95% of the time being spent drawing line segments,
> so I assumed OW 1.4 must be *much* faster at doing that.
> Actually, in the normal case, with no profile_time, the scheduler,
> which calls time(), takes a very large chunk of the time.
> Although, even in the worst case, time() requires less than a millisecond
> to execute, it adds up quickly when you are yielding every few statements,
> as in the tasksort demo.
>
> I also confirmed this by trying the wire.ex demo, which
> doesn't use multitasking. It ran at the same speed, 10.6 or OW.
> It displays lots of line segments at various angles.
>
> I don't know why moving the mouse speeds up the time() function,
> but both involve hardware interrupts.
>
> As a result of all this, I went through task_yield() and the scheduler,
> and minimized the number of calls to time(). Now there is always
> just one call, instead of two or three. tasksort now runs twice as fast
> with 10.6.
>
> I could *always* use the interrupt handling method, instead of
> calling the DOS time function, but I found XP seems to miss some
> interrupts, and the time can be off by 10% or so. This didn't
> happen on the earlier systems. Also, there might be a problem
> on some systems, if your program crashes (due to a hardware exception),
> while clock interrupt handling has been altered. Your time might
> advance too slow or too fast, at least under DOS.
>
> Anyway, on Windows, Linux and FreeBSD this is not an issue
> since time() is very fast.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Thats just amazing!
Did you know "tick_rate(>= 18.3)" also speeds it up drastically?
tick_rate() and profile_time are my new best friends.
I also noticed when it's going that fast, moving the mouse doesn't have any
affect on speed any longer.
BTW, I tested the performance of your newly compiled interpreters. I done
sequence, sieve, and other benchmarks and it concludes a generous speed up in
overall execution. But now you've also kicked up DOS graphics 2x faster, that can
easily be sped up to 6x faster using one of the two methods above.
These are very impressive results and defiently a great performance gain for
Euphoria v3.0! Way to go friend!
Are you planning to upload new executables to the archive once again?
Regards,
Vincent
24. Re: Rob: Bug with Windows trasking translator
Bernie Ryan wrote:
> Why not use a pif file an set the pif file to start up
> in dos window mode ?
I tried that already. No luck.
If you want to give it a shot,
here's a version (not the very latest) of ex.exe,
built by Open Watcom 1.4:
http://www.rapideuphoria.com/uploads/owex.exe
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
25. Re: Rob: Bug with Windows trasking translator
Vincent wrote:
> Did you know "tick_rate(>= 18.3)" also speeds it up drastically?
Yes. Anything that makes ex.exe handle interrupts directly,
rather than calling the DOS system function for time().
> tick_rate() and profile_time are my new best friends.
Most programs probably don't care how long time() takes.
It's less than a millisecond on my machine, even in the slow case.
It's typically used just to measure elapsed time, such as when benchmarking.
In DOS, it can affect multitasking, depending on how often
your tasks yield, and whether they are time-shared, or real-time.
Language War spends 90% of it's time in the scheduler,
just waiting for some time to elapse so it can run the next task
at the desired time.
> I also noticed when it's going that fast, moving the mouse doesn't have any
> affect on speed any longer.
>
> BTW, I tested the performance of your newly compiled interpreters. I done
> sequence,
> sieve, and other benchmarks and it concludes a generous speed up in overall
> execution. But now you've also kicked up DOS graphics 2x faster, that can
> easily
> be sped up to 6x faster using one of the two methods above.
>
> These are very impressive results and defiently a great performance gain for
> Euphoria v3.0! Way to go friend!
>
> Are you planning to upload new executables to the archive once again?
Yes, maybe tomorrow.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
26. Re: Rob: Bug with Windows trasking translator
Rob before you dismiss OW,
Are you going to try removing the workaround code in a backup copy of the source
and see what kind of performance gain you'll get?
If you get a notable speed increase then maybe OW might still viable because
then you would have these benefits:
1) A speed improvement in time() without profile_time or tick_rate().
2) Speed improvement by removing bug workaround.
3) ?
Otherwise OW might not be worth switching to because of the full-screen issue?
If you don't use OW, are you planning to document that using profile_time or
tick_rate() can magically speed up graphic intensive multi-tasking DOS
applications?
Regards,
Vincent
27. Re: Rob: Bug with Windows trasking translator
Vincent wrote:
> Rob before you dismiss OW,
>
> Are you going to try removing the workaround code in a backup copy of the
> source
> and see what kind of performance gain you'll get?
There are places where I insert bits of machine code.
Watcom doesn't understand what I'm doing, so it sometimes
"optimizes" things the wrong way. To get around it,
I sometimes have to write my code in a strange way.
I tried undoing one of these with OW 1.4, and it worked,
but then I found it also works now with 10.6.
I can see now that most of these little workarounds
have zero effect on performance. The rest have an effect
so tiny you'd never be able to measure it.
> If you get a notable speed increase then maybe OW might still viable because
> then you would have these benefits:
>
> 1) A speed improvement in time() without profile_time or tick_rate().
> 2) Speed improvement by removing bug workaround.
> 3) ?
Bottom line: there's not enough here to possibly save OW 1.4,
even if it did eliminate a few workarounds. It's also very
tedious to test this. From what I can see, the code generation
algorithms are the same.
> Otherwise OW might not be worth switching to because of the full-screen issue?
It looks that way.
I can easily switch from 10.6 to 1.4, or vice versa.
Maybe we'll think of some other advantage in the future,
but for now I've gone back to 10.6.
> If you don't use OW, are you planning to document that using profile_time or
> tick_rate() can magically speed up graphic intensive multi-tasking DOS
> applications?
Yes, I've done that already.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
28. Re: Rob: Bug with Windows trasking translator
Robert Craig wrote:
> There are places where I insert bits of machine code.
> Watcom doesn't understand what I'm doing, so it sometimes
> "optimizes" things the wrong way. To get around it,
> I sometimes have to write my code in a strange way.
> I tried undoing one of these with OW 1.4, and it worked,
> but then I found it also works now with 10.6.
> I can see now that most of these little workarounds
> have zero effect on performance. The rest have an effect
> so tiny you'd never be able to measure it.
Heh... maybe you should go through and see how many you can actually remove?
> Bottom line: there's not enough here to possibly save OW 1.4,
> even if it did eliminate a few workarounds. It's also very
> tedious to test this. From what I can see, the code generation
> algorithms are the same.
Fair enough, I'm sure you've made a informed decision about this.
> It looks that way.
> I can easily switch from 10.6 to 1.4, or vice versa.
> Maybe we'll think of some other advantage in the future,
> but for now I've gone back to 10.6.
Fair enough. A project that will add LFN support to DOS Open Watcom is underway
and might become part of compiler and CLIB in the near future. That might be
something to check out later on. Thanks for evaluating it anyway.
I'm very impressed at the little things you've done to tasking Euphoria v2.5.
I'm looking forward to Euphoria v3.0, because it's really going to kick @$$! 
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Cheers,
Vincent
29. Re: Rob: Bug with Windows trasking translator
Bernie Ryan wrote:
> Why not use a pif file an set the pif file to start up
> in dos window mode ?
That is the way it *should* work, but it *doesn't* work
that way.
Regards,
Juergen
30. Re: Rob: Bug with Windows trasking translator
Robert Craig wrote:
> Juergen Luethje wrote (re pop to full screen):
>> Since I learned to know Euphoria (i.e. since version 2.3) I *always* had
>> this problem on Windows 98. When I translate/compile a Euphoria DOS
>> program, I use DJGPP instead of Watcom in order to avoid this problem.
>> But there is no alternative for ex.exe, and the mentioned behaviour is
>> very annoying indeed! Rob, it would be really nice if you would find a
>> way to fix this problem.
>
> As I recall, on Win95/98, it would go to full screen the first
> time you ran ex.exe in a new DOS window, but after you pressed
> Alt-Enter, it would switch back to a normal window, and it
> would stay normal after that.
Maybe ... I never keep a DOS window open.
I run my Euphoria DOS programs the following way:
On the Windows system level, the .ex programs are associated with
ex.exe. I start an .ex program by double clicking at it in the
Windows Explorer (or Total Commander). So the mentioned problem
occurs each time I start an .ex program.
> With OW 1.4, it goes back to full screen
> *every* time you run it.
[snipped other interesting information]
Regards,
Juergen
31. Re: Rob: Bug with Windows trasking translator
Robert Craig wrote:
>
> Bernie Ryan wrote:
> > Why not use a pif file an set the pif file to start up
> > in dos window mode ?
>
> I tried that already. No luck.
> If you want to give it a shot,
> here's a version (not the very latest) of ex.exe,
> built by Open Watcom 1.4:
>
> <a
> href="http://www.rapideuphoria.com/uploads/owex.exe">http://www.rapideuphoria.com/uploads/owex.exe</a>
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Rob:
I have some suggestions.
The only thing I can think of is that the difference may have to
something to do with a change within the dos extender.
I don't know if the OW uses DOS/4GW or causeway but you could
try re-stubing the program with an older version of causeway or
DOS/4GW because it may have something to do with the way the startup
code is writen also maybe there is an enviorment variable that
has to be set like set causeway = NODPMI ?
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
