Оберон-клуб «ВЄДАsoft» • Просмотр темы - [Solved] Proper initialization of Oberon modules

Сообщения без ответов | Активные темы

Список форумов » Платформы и ОС (в контексте разработки для них на Оберон-языках) » ZX Spectrum

Часовой пояс: UTC + 2 часа

[Solved] Proper initialization of Oberon modules

Страница 1 из 3

[ Сообщений: 24 ]

На страницу 1, 2, 3 След.

Версия для печати

Пред. тема | След. тема

Автор

Сообщение

slenkar

Заголовок сообщения: Re: Roguelike with strategy

Добавлено: 08 авг 2013, 06:30

Сообщения: 104

When the game loads it doesnt start
The code is 17KB
it starts at 25000
the data is at 51000

in hi.list it says:
000061A8 _main hi
000061A8 _main_start hi

so it should start, as 61A8 is 25000

DATA is 7kb
HOME is 4kb

I think its because I have 2 modules that import each other
I think they keep caling each others init function

Вернуться к началу

Zorko

Заголовок сообщения: Re: Roguelike with strategy

Добавлено: 08 авг 2013, 11:28

Сообщения: 1019
Откуда: Днепропетровская обл.

slenkar писал(а):

I think they keep caling each others init function

It is a probable problem.

Код: "OBERON"

Expand Code | Выделить всё

	__INIT(argc, argv);
	__IMPORT(MyModule__init); // Here the imported module initialized
	__REGMAIN("MyModule2", 0);

And if other module imports MyModule too, it calls MyModule__init too. I've fixed this problem in macros __DEFMOD that Ofront has placed in a module initializer:

Код: "C"

Expand Code | Выделить всё

export void *GrConsole__init(void)
{
	__DEFMOD; // Check is the module already initialized? And return, if yes.
	__IMPORT(GrColors__init); // Call CrColors__init()
	__IMPORT(GrFonts__init); // Call GrFonts__init()
	__IMPORT(GrPixel__init); // Call GrPixel__init()
	__IMPORT(GrScr__init); // Call GrScr__init()
	__IMPORT(GrTiles__init); // Call GrTiles__init()
	__IMPORT(SdlLib__init); // SdlLibGrTiles__init()
	__REGMOD("GrConsole", 0);
...
}

This code does it:

Код: "C"

Expand Code | Выделить всё

#  define __DEFMOD	static char m; if(m!=0)return

(Because a static variable always initializes to 0 and keep its value for each using).

I recommend that you update SYSTEM.h where I've fixed this bug (but now SYSTEM.h is adapted for modified Ofront, therefore maybe just update the macros __DEFMOD).

Вернуться к началу

slenkar

Заголовок сообщения: Re: Roguelike with strategy

Добавлено: 08 авг 2013, 19:16

Сообщения: 104

I put the new system.h and system_cfg.h in there
and now get this error:
'auto' variable 'Basic' may be used before initialization
on this line:
__IMPORT(Basic);

and when linking:
?ASlink-Warning-Undefined Global '_Basic' referenced by module 'hi'

for all modules

These errors are only in the main file which is hi.c

Вернуться к началу

Zorko

Заголовок сообщения: Re: Roguelike with strategy

Добавлено: 08 авг 2013, 21:44

Сообщения: 1019
Откуда: Днепропетровская обл.

You must know that I've modified Ofront to generate __IMPORT(Basic__init) instead of __IMPORT(Basic). It's done for supporting C compilers that do not accept identifiers concatenation ## (like Turbo C).

And I think your Linux version of Ofront isn't compatible with the modified SYSTEM.h

I regret that hasty advise you to update SYSTEM.h

Probably will be a good idea to roll back to the old macros.

Was (new variant for modified Ofront):

Код: "C"

Expand Code | Выделить всё

#define __IMPORT(name__init)	SYSTEM_INCREF(name__init())

You need to use (old variant that isn't compatible with Turbo C):

Код: "C"

Expand Code | Выделить всё

#define __IMPORT(name)	SYSTEM_INCREF(name##__init())

Вернуться к началу

slenkar

Заголовок сообщения: Re: Roguelike with strategy

Добавлено: 09 авг 2013, 03:41

Сообщения: 104

ok thanks,
can ofront be compiled for linux? (if it is a command line utility it shouldnt need many changes)

(Its still doing the same problem where it calls the init functions forever)

I looked in GitHub at ofront but I didnt see any C++ code to compile

Вернуться к началу

Zorko

Заголовок сообщения: Re: Roguelike with strategy

Добавлено: 09 авг 2013, 11:33

Сообщения: 1019
Откуда: Днепропетровская обл.

slenkar писал(а):

can ofront be compiled for linux? (if it is a command line utility it shouldnt need many changes)

(Its still doing the same problem where it calls the init functions forever)

Hmm... maybe first I understand your "forever init" not so correctly. The idea was that each module can be initialized more than once due to the fact that modules that import the module would call its initializer several times. And the initializer must check is it called first time, or not, and return if it was already called.

Try to understand where is looped code, by printing control characters to screen. Try to emulate native module initializers by just Init procedures that may be called manually from main module only. In general, I guess that's not a problem of Ofront, SYSTEM.h or SDCC, and a problem of your code.

slenkar писал(а):

I looked in GitHub at ofront but I didnt see any C++ code to compile

All right. Ofront is written in Oberon and need to be translated to C by itself.

I have not tried to build Linux version of Ofront (and haven't experience with it), but I have a desire to make the console version for Linux and Windows, maybe I'll try to do it soon.

Вернуться к началу

slenkar

Заголовок сообщения: Re: Roguelike with strategy

Добавлено: 09 авг 2013, 16:46

Сообщения: 104

what do you use to compile ofront for windows?
I have the oxford oberon compiler, would that work?

I noticed that REGCMD is only used for some procedures but not others would this cause a problem?

here is what my System_cfg.h looks like

Код: "C"

Expand Code | Выделить всё

/*  Ofront 1.2 SYSTEM config */
 
#ifndef __SYSTEM_Cfg__h
#define __SYSTEM_Cfg__h
 
/* runtime system routines */
 
//#define SYSTEM_Cfg_IncRef
 
/* module registry */
 
//#define SYSTEM_Cfg_RegisterModules
//#define SYSTEM_Cfg_RegisterMain
//#define SYSTEM_Cfg_RegisterCommands
 
/* record type descriptors */
 
//#define SYSTEM_Cfg_RecTypeDesc
//#define SYSTEM_Cfg_InitTypes
 
/* Oberon-2 type bound procedures support */
//#define SYSTEM_Cfg_TypeBoundProcDynCalls
 
/* std procs and operator mappings */
#define SYSTEM_Cfg_MOD_as_in_C
#define SYSTEM_Cfg_NoASSERT
 
/* runtime checks */
#define SYSTEM_Cfg_NoCheck_X
#define SYSTEM_Cfg_NoCheck_CASE
 
#endif

is it ok?

Вернуться к началу

Zorko

Заголовок сообщения: Re: Roguelike with strategy

Добавлено: 09 авг 2013, 18:23

Сообщения: 1019
Откуда: Днепропетровская обл.

slenkar писал(а):

what do you use to compile ofront for windows?

Ofront for Windows is implemented as a subsystem of BlackBox Component Builder, and I use BlackBox as compiler and as IDE. I.e. Open -> Ofront -> Mod -> *.odc -> Dev -> Compile.

slenkar писал(а):

I have the oxford oberon compiler, would that work?

I don't know. But I think would be better to use Ofront and GCC for this work.

slenkar писал(а):

I noticed that REGCMD is only used for some procedures but not others would this cause a problem?

The macros REGCMD needed for Oberon system to register procedures without parameters as Oberon commands. I didn't use this feature, it's not needed for static compiled stand-alone code.

slenkar писал(а):

here is what my System_cfg.h looks like - is it ok?

Yes.

Вернуться к началу

slenkar

Заголовок сообщения: Re: Roguelike with strategy

Добавлено: 09 авг 2013, 21:44

Сообщения: 104

the problem is definitely in the init function
I printed the name of the module to the screen when it is done with its init function,
only 2 of them appeared, them the spectrum resets

there is nothing strange or new going on in the init functions

All I did was add a new module then these strange things started happening

this seems to be the only module that imports a module that imports it

Вернуться к началу

Zorko

Заголовок сообщения: Re: Roguelike with strategy

Добавлено: 10 авг 2013, 00:33

Сообщения: 1019
Откуда: Днепропетровская обл.

How do I solve similar problems? First need to look aren't there serious warnings after compiling by SDCC. Second I run EmuZWin - it has step-by-step debugger. I press F7/F8 to do a step and look at the asm code - where is breaking of a program logic? Also there is possibility to change any registers and look at memory. SDCC-generated *.asm sources can help you to establish a correspondence between C and asm source.

Вложения:

DebugEmuZWin.png [ 62.79 КБ | Просмотров: 30909 ]

Вернуться к началу

Страница 1 из 3

[ Сообщений: 24 ]

На страницу 1, 2, 3 След.

Список форумов » Платформы и ОС (в контексте разработки для них на Оберон-языках) » ZX Spectrum

Часовой пояс: UTC + 2 часа

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 4

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Перейти: