Stupid question about if it's possible to link and create two separate executables

[thorrin]

Dern, y'all are going to make me get an AmigaOne and start coding up some stuff...  This all sounds like good fun.

-Thorrin

[Jose]

Thx all for your time, I decided I'll just go for the messages and ports solution... Semaphores won't be needed because the data won't be dynamic.

[bloodline]

Karlos wrote:
@bloodline

Slight variation on that - simply create a struct that has all your shared globals in it and pass a pointer to that structure (via a Message) to the other task.

That struct could also contain a SignalSemaphore as part of its definition which would be used solve the concurrency issue.

One point though, can you allocate the struct in memory that has an MEMF_PUBLIC flag? (I'm having visions of some pointer magic here :-P)

With my method, the memory is labled as sharable, so even if memory protection were implemented (no I'm not going to start a debate on that topic :-D), it would still work... but if you use a struct then the memory would be allocated from the Program's heap and would be protected against another task.

[bloodline]

thorrin wrote:
Dern, y'all are going to make me get an AmigaOne and start coding up some stuff...  This all sounds like good fun.

-Thorrin

Why not just download AROS and Code up some stuff right now!?!?! :lol:

[Jose]

@bloodline

"One point though, can you allocate the struct in memory that has an MEMF_PUBLIC flag? (I'm having visions of some pointer magic here )....
 "... but if you use a struct then the memory would be allocated from the Program's heap and would be protected against another task."

Code: [Select]

struct OurStructure *OurMessage

OurMessage = (struct OurStructure*)AllocMem (sizeof(OurStructure), MEMF_PUBLIC|MEMF_CLEAR))
/* Initialize the structure after*/

[bloodline]

Jose wrote:
@bloodline

"One point though, can you allocate the struct in memory that has an MEMF_PUBLIC flag? (I'm having visions of some pointer magic here )....
 "... but if you use a struct then the memory would be allocated from the Program's heap and would be protected against another task."

Code: [Select]

struct OurStructure *OurMessage

OurMessage = (struct OurStructure*)AllocMem (sizeof(OurStructure), MEMF_PUBLIC|MEMF_CLEAR))
/* Initialize the structure after*/

Ahhh pointer magic then :-) :pint:

[Piru]

Code: [Select]

struct OurStructure *OurMessage

OurMessage = (struct OurStructure*)AllocMem (sizeof(OurStructure), MEMF_PUBLIC|MEMF_CLEAR))
/* Initialize the structure after*/


That would be either:

Code: [Select]


struct OurStructure *OurMessage;

OurMessage = (struct OurStructure *) AllocMem(sizeof(struct OurStructure), MEMF_PUBLIC|MEMF_CLEAR);

or:

Code: [Select]


struct OurStructure *OurMessage;

OurMessage = (struct OurStructure *) AllocMem(sizeof(*OurMessage), MEMF_PUBLIC|MEMF_CLEAR);


[Karlos]

bloodline wrote:

Ahhh pointer magic then :-) :pint:

Well, this is only C after all. You have 2 options

1) allocate memory using exec or clib (the former is better for OS specific stuff of course)

2) create a constructor / destructor function pair, that in turn use (1) in order to achieve their task.

Either way, it always comes down to pointer magic. C++ offers various other approaches, except that too is also pointer magic, you just don't necessarily have to cast manually (depending on how you allocated your object,that is).

Let's face it, any raw memory handling for object memory will always involve some form of explicit/implicit pointer conversion.

[PiR]

Let's face it, any raw memory handling for object memory will always involve some form of explicit/implicit pointer conversion.

Yes. No more miserable excuses. We're all grown men here, we can stand the truth. ;-)

[Karlos]

*drunkenly staggers, points and shouts angrily*

Truth? You can't handle the truth!

*collapses in stupor at keyboard and writes the next generation memory allocation mechanism accidently from a series of random face+keyboard interactions...*

[bloodline]

It's a curious thought that AOS doesn't have any memory sharing functions... with semaphor protection etc... I suppose one could use "files" on the Ram: device... but that sounds too Unixie to me :-D

[Karlos]

@bloodline

It isn't really needed as you can semaphore protect anything you choose to, the SignalSemaphore is completely general purpose. Hence you can allocate some memory and simply make sure you appropriately use the semaphore before accessing it. SignalSemaphores are quite flexible, you can get exclusive and read only (shared) locks etc.

[PiR]

Hi

I dig through all the documentation I could find and I give up.
Can anyone (yes, Piru, I'm talking to you...) be so kind and explain me, why in all examples with fakeSegList there is always '16' put in the 'size' field?
To be more curious - why there is anything at all, if you are not allowed to call UnloadSeg() for it anyway...

And one last related thing - what is the interpretation of this size in this DOS/BCPL world? Number of bytes/words/longs/doubles/lines/pages/magic_number_that_is_always_set_to_16_regardles_of_anything?

Code: [Select]


struct fakeseg
{
  ULONG size;
  BPTR  next;
  UWORD jmp;
  APTR  myfunc;
};


From my calculations sizeof( struct fakeseg ) = 14.
But hmmm... If I remember correctly BCPL uses only longs. So mayby sizeof() must always be multiplication of 4? So, to be precise it should be rather:

Code: [Select]


struct fakeseg
{
  ULONG size;
  BPTR  next;
  UWORD jmp;
  APTR  myfunc;
  UWORD _filler;
};


On the other hand if it's not used for anything, why to bother and initiate it at all?

Correct me if I'm wrong.

Thanks.

[Speelgoedmannetje]

:nervous: pointers :nervous:

no really, I think you need to redesign your programme
use multithreading (sweet Amiga :-))

and make use of MUTEXES

[Piru]

@PiR

Try to put 6 bytes of data (yes 'size' and 'next' are not really part of it) to a segment. Then load the segment with LoadSeg. Segment 'size' will be 16.

Basically the size of the data is padded to multiple of longwords (4), and thus to stay consistent the fake segment size is also 16 and not 14.

So in a sense using _filler like that is not a bad idea, it makes the sizeof() correct, too. It is not strictly speaking needed, though.

On the other hand if it's not used for anything, why to bother and initiate it at all?

Some applications scan the seglists, and if the fields would not be set properly these apps could crash.

[Noster]

Hi

@Jose

Haven't read the whole thread (no time :-() but you can use a really simple fake seglist instead of a real seglist in CreateProc():

Think you have a pointer to the function that should be the entrypoint into your new process:

void (*pfv)(void);

Now you can simply get a BPTR to this function using:

BPTR sl;

sl = MKBADDR(pfv) - 1;

Now you can create your process:

struct MsgPort *mp;

mp = CreateProc ("ChildProc", DEFAULT_PRI, sl, DEFAULT_STACK);

The entry address of a function used this way must be aligned to a longword address, under SAS/C the first function of an object module can be considered appropriate for this conversion; it may have to be declared with the __saveds keyword.

This is documented in "The Amiga Guru Book" from Ralph Babel and I have tested it under every AmigaOS 1.3+. I think you will get problems if the code should be converted to OS 4.0 :-)

Noster