Author Topic: Bytecode Interpreter concept  (Read 29554 times)

0 Members and 1 Guest are viewing this topic.

Charles Pegge

  • Guest
Re: Bytecode Interpreter concept
« Reply #75 on: July 24, 2014, 11:04:29 PM »
Yes I am working on the remedy. The problem appears to be a rogue optimization.

Mike Lobanovsky

  • Guest
Re: Bytecode Interpreter concept
« Reply #76 on: July 25, 2014, 04:53:32 AM »
Thanks, Charles.

Charles Pegge

  • Guest
Re: Bytecode Interpreter concept
« Reply #77 on: July 25, 2014, 02:35:46 PM »

Update with repaired compound conditional string comparisons:

http://www.oxygenbasic.org/o2zips/Oxygen.zip

This should not leak, since no temp strings are generated in the while clause:

Code: [Select]
sub get_ident()
token = ""
while is_alpha() or is_numeric() or cur_ch = "_"
token = token & cur_ch
next_char()
wend
    sym = search_key_words()
end sub


Mike Lobanovsky

  • Guest
Re: Bytecode Interpreter concept
« Reply #78 on: July 25, 2014, 06:48:06 PM »
Oh Charles,

Thanks a lot for fixing the problems so quickly. You're indeed very responsive to the needs of language users and extremely productive at that too. :)

Charles Pegge

  • Guest
Re: Bytecode Interpreter concept
« Reply #79 on: July 25, 2014, 10:40:23 PM »
Thanks Mike,

One minor correction to prevent a GPF in JIT mode:


sub press_a_key()
    print cr "Press any key to continue..."
    waitkey
    end
end sub


end is not normally required, but should be placed outside any procedures, in the main body of the program.

Mike Lobanovsky

  • Guest
Re: Bytecode Interpreter concept
« Reply #80 on: July 26, 2014, 03:47:26 AM »
Thanks for the tip, Charles.

Then I'd put it in the global code immediately following the call to main().

Aurel

  • Guest
Re: Bytecode Interpreter concept
« Reply #81 on: September 04, 2014, 06:26:52 AM »
For Mike

What could be the simpliest method for my interpreter that can intecept windows messages
properly and without any interference ?
Why i ask..hmm i think that old method i use is little bit clumsy
thanks !

Mike Lobanovsky

  • Guest
Re: Bytecode Interpreter concept
« Reply #82 on: September 04, 2014, 08:38:13 AM »
Hi Aurel,

Your WndProc() is the only place where you're supposed to process messages that are coming to the two main windows of your application. The same callback can also be used for any additional windows that you might add in the future as long as these windows are not of any special type e.g. control or dialog windows. And yes, you can differentiate between the windows by their handles like you do. From this standpoint, your design is absolutely correct.

I'd only suggest you observe the following simple rules when working with messages in this callback:

Firstly, almost every message is supposed to return a special value from this callback to the system. Presently all your messages fall through to the common Return DefWindowProc hwnd, wMsg, wParam, lParam command. This means that whatever you do in your message handlers, the system will also add its default processing after all your actions. If you look attentively into the MSDN, you will see that each window message entry there has the following hint:

Return Values

An application should return N if it processes this message.


where N is a numeric value that the callback should return to avoid default processing. Most of the messages should return 0 or 1, for example

Case WM_PAINT
    BitBlt hdc, 0, 0, width, height, hmemdc, 0, 0, SRCCOPY
    Return 0


This will prevent falling through to Return DefWindowProc(). A few messages however need to return other values. The MSDN is your best friend when working with the Windows message pipe.

Secondly, some of your actions don't need immediate response from the system and shouldn't break its default behavior. In this case, you shouldn't use SendMessage() in the callback when processing other messages. Use PostMessage() instead and let the current message fall through to DefWindowProc(), i.e. don't use any special Return for it.

The difference between SendMessages() and PostMessage() is that the former blocks the callback until the SendMessage() call is executed in full while the latter proceeds immediately not blocking it. The message you've just posted will be placed in the window message queue and executed in a natural non-blocking manner at some later time.

Here too, you should consult the MSDN to see if the message in question is normally sent or posted. Each message entry there will usually start with something like

An application sends the WM_PAINT message when ...

or

The WM_KEYDOWN message is posted to the window ...

There are only slight differences in how Windows would process sent and posted messages but in very many cases the effect of this difference is exactly what you're after in your code.

Aurel

  • Guest
Re: Bytecode Interpreter concept
« Reply #83 on: September 04, 2014, 12:53:06 PM »
Thank you Mike on very clear explanation  ;)
ok i will check all options.

Frankolinox

  • Guest
Re: Bytecode Interpreter concept
« Reply #84 on: September 05, 2014, 02:20:31 AM »
aurel, specify your problem with an example or code snippet, perhaps I can help too.

for programming and learning resources check also "petzold" win api examples for further studies, that's really a treasure ;)

regards, frank

Aurel

  • Guest
Re: Bytecode Interpreter concept
« Reply #85 on: September 05, 2014, 10:12:35 AM »
Hi Frank
I will post this question on my forum and i always want your experience
if i remember i ask you few times some things..
 :)