From 351d42b158ba80980f3dfceada5fc5696251f030 Mon Sep 17 00:00:00 2001 From: Przemyslaw Czerpak Date: Tue, 4 Jul 2006 11:27:47 +0000 Subject: [PATCH] 2006-07-04 13:20 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) * harbour/include/hbstack.h * harbour/source/vm/estack.c - removed hb_stackTopItem() + added hb_stackItemBasePtr(), hb_stackAllocItem() * changed the item initialization/clearing in push/pop operation Now only complex item are cleared and it's not guaranteed that the top item will be set to NIL. In fact it was not guarantied even before my modifications. You coule be sure only that the allocated item will not be complex one and you can safely pass pointer to it to any other functions. It allow to clean a little bit some code and remove redundant and repeated setting HB_IT_NIL for allocated items. Now using hb_stackPush() can be necessary only in some very seldom cases. hb_stackAllocItem() allocates new item and returns pointer to this item. After some code cleaning hb_stackPush() is not used by core Harbour code at all so if you have it in your sources then please check if you should not update them. * harbour/source/rdd/usrrdd/usrrdd.c * use hb_vmPushNil() instead of hb_stackPush() * harbour/source/vm/arrays.c * changed hb_arrayNew() to be safe for automatic GC activation * some minor speed improvement * harbour/source/vm/codebloc.c * changed hb_codeblockNew() and hb_codeblockMacroNew() to be safe for automatic GC activation * harbour/source/vm/debug.c * use only stack function/macros instead of direct accessing hb_stack I hope that I haven't break anything. * harbour/source/vm/hvm.c ! use hb_stackAllocItem() instead of hb_stackTopItem() to make our HVM reentrant safe. This modifications also fixed some possible bugs which could be exploited by other modules which have to execute .prg code - f.e. in RDD when relation codeblock has to be executed to position record in fieldget/fieldput operations. * source/compiler/gencli.c ! .NET IL implementation for HB_P_POPLOCALNEAR and HB_P_PUSHLOCALNEAR Notice: These opcodes are responsable for loading the values on the locals and also for pushing the locals contents onto the virtual machine stack. You can already run tests like this: function Main() local c := "Hello world from Harbour.NET !" ? c return nil Remember the process to build a .NET app: Harbour.exe -gi -n hello.prg --> hello.il ilasm.exe hello.il --> hello.eor Ryszard. With the above exception now we are ready to implement destructors, add automatic GC and begin to work on MT though before that I'd like to clean the RT error support. Please carefully check if all is correct. It was modification in core code and even small typo can break whole application. --- harbour/ChangeLog | 58 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) diff --git a/harbour/ChangeLog b/harbour/ChangeLog index ed418c16de..5d6b22deb0 100644 --- a/harbour/ChangeLog +++ b/harbour/ChangeLog @@ -8,6 +8,64 @@ 2002-12-01 13:30 UTC+0100 Foo Bar */ + + common file lists and definitions shared between Bcc + and Msc makefiles + + TODO : add automatic building of contrib libs/dll(s) + +2006-07-04 13:20 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) + * harbour/include/hbstack.h + * harbour/source/vm/estack.c + - removed hb_stackTopItem() + + added hb_stackItemBasePtr(), hb_stackAllocItem() + * changed the item initialization/clearing in push/pop operation + Now only complex item are cleared and it's not guaranteed that + the top item will be set to NIL. In fact it was not guarantied + even before my modifications. You coule be sure only that the + allocated item will not be complex one and you can safely pass + pointer to it to any other functions. It allow to clean a little + bit some code and remove redundant and repeated setting HB_IT_NIL + for allocated items. + Now using hb_stackPush() can be necessary only in some very seldom + cases. hb_stackAllocItem() allocates new item and returns pointer + to this item. After some code cleaning hb_stackPush() is not used + by core Harbour code at all so if you have it in your sources then + please check if you should not update them. + + * harbour/source/rdd/usrrdd/usrrdd.c + * use hb_vmPushNil() instead of hb_stackPush() + + * harbour/source/vm/arrays.c + * changed hb_arrayNew() to be safe for automatic GC activation + * some minor speed improvement + + * harbour/source/vm/codebloc.c + * changed hb_codeblockNew() and hb_codeblockMacroNew() to be safe + for automatic GC activation + + * harbour/source/vm/debug.c + * use only stack function/macros instead of direct accessing hb_stack + I hope that I haven't break anything. + + * harbour/source/vm/hvm.c + ! use hb_stackAllocItem() instead of hb_stackTopItem() to make our + HVM reentrant safe. This modifications also fixed some possible + bugs which could be exploited by other modules which have to execute + .prg code - f.e. in RDD when relation codeblock has to be executed + to position record in fieldget/fieldput operations. + + * harbour/source/vm/itemapi.c + * harbour/source/vm/memvars.c + * use hb_stackAllocItem() + + The above modifications finish stack usage and making our HVM reentrant + safe. There is only one thing which have to be fixed yet. It's HVM + support for xbase++ syntax in things like: + func(&), aVal[&], {&} + To fix it we will have to change PCODE generated by compiler and + replace some PCODEs used for current code by the new one. I will + wait with this modifications for Ryszard. + With the above exception now we are ready to implement destructors, add automatic GC and begin to work on MT though before that I'd like to clean the RT error support. Please carefully check if all is correct. It was modification in core