Welcome, Guest. Please login or register.

Author Topic: Counting on AllocVec's size memo..  (Read 13668 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show only replies by itix
Re: Counting on AllocVec's size memo..
« Reply #29 from previous page: December 28, 2006, 01:37:57 PM »
Quote

Neither of them do. SnoopDos68K runs in fact "better" than SnoopDosOS4 (you can't open the "Functions" window anymore).

That results from a nice "trick", doing some write accesses to const data sections. Nice, eh? SnoopDos68K doesn't break because 68K programs are still allowed to do this.


Program overwriting its own const data is not illegal as such and in SnoopDos it happens only because some strings are unexpectedly placed into .rodata section. There is nothing wrong in SnoopDos 68k; bug was created in 68k->PPC transition. Only PPC version of SnoopDos (inluding MorphOS port) writes to const data.

Fixing const data problem does not give you working packet monitor though.

Quote

If one looks at the practice to rely on the memory size notation of AllocMem(), one must say: Why do you do this? It's "forbidden", there is no real problem to do own notation of the alloc'd size, just do it the "right" way.


Even OS4 developers do it. DiskSpeed OS4 assumes that memory returned from AllocVec() is aligned to 8 bytes boundary. It is not documented feature but is "public knowledge". Neither is documented what newlib startup code (one that is statically linked to newlib programs) is doing. Build hello world program and link it against newlib and you are already using undocumented features.
My Amigas: A500, Mac Mini and PowerBook
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show only replies by Piru
    • http://www.iki.fi/sintonen/
Re: Counting on AllocVec's size memo..
« Reply #30 on: December 28, 2006, 01:44:59 PM »
@whose
Quote
But where's the point to discuss the compatibility question for older programs, when a programmer actually asks for this OS private special?

Historical context, and implementation details. He did ask if it had changed, too.

Also, in some rare occasions such details might be needed (for example debugging tools).

Quote
I bet there is. But I'm not "skilled" enough to judge or explain it. The Frieden brothers can explain it much better, I think.

Well, nothing in their explanation is good enough reason to justify this change (and I consider myself qualified enough to comment on this). See earlier posts in this thread.
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show only replies by itix
Re: Counting on AllocVec's size memo..
« Reply #31 on: December 28, 2006, 01:54:26 PM »
Quote

The real issue is that developers shouldn't habitually point loaded guns at their own feet and wonder why they might lose some toes one day


Is the real issue that Amiga developers in 80s and 90s were not very good afterall? :-) I mean, when old programs stop working when internals of the OS have changed is it because Amiga software is POS or Amiga operating system is POS? Or both? Or none? Obviously SW developers do mistakes (think about original IBrowse 2.3 issues in OS4) but if mistakes are common practise it is better fix the OS than software. The OS exists for the software.
My Amigas: A500, Mac Mini and PowerBook
 

Offline whose

  • Newbie
  • *
  • Join Date: Dec 2006
  • Posts: 13
    • Show only replies by whose
Re: Counting on AllocVec's size memo..
« Reply #32 on: December 28, 2006, 02:05:53 PM »
@itix:

Quote

Program overwriting its own const data is not illegal as such and in SnoopDos it happens only because some strings are unexpectedly placed into .rodata section.


Well, I would it call illegal, if everybody should know that these sections are write protected (well, in fact they weren't until final, but NDK states it).

Quote
Fixing const data problem does not give you working packet monitor though.


But this is a complete other topic, isn't it? Or does it break because of the new memory system? I would think that this a question of correct OS function use.

Quote

Even OS4 developers do it. DiskSpeed OS4 assumes that memory returned from AllocVec() is aligned to 8 bytes boundary.


I see... hence it is a good practice to encourage such methods by refering to historical errors made and giving them a late "absolution"? I don't think so.

Show them the correct way, if you know about. Don't discuss old "tricks" and the compatibility break of these tricks a new designed OS gives or will give.

Damn easy.

Greetz
 

Offline whose

  • Newbie
  • *
  • Join Date: Dec 2006
  • Posts: 13
    • Show only replies by whose
Re: Counting on AllocVec's size memo..
« Reply #33 on: December 28, 2006, 02:13:02 PM »
Quote

Historical context, and implementation details. He did ask if it had changed, too.


Ok. Well, but in this case it would have been sufficient to say: "this doesn't work anymore, it is not documented and therefore "forbidden" to use. It will break with OS4, don't use such a detail".

Quote

Also, in some rare occasions such details might be needed (for example debugging tools).


Maybe. But one should ask himself, if such tools would work with OS4 or other OS. If (perhaps or sure) not, search for another, working, way. There are ways to develop such tools in a friendly way, even for OS4.

I really don't understand why it is so important to use such tricks, which are already blamed decades before, sry.

Greetz
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show only replies by Piru
    • http://www.iki.fi/sintonen/
Re: Counting on AllocVec's size memo..
« Reply #34 on: December 28, 2006, 02:30:32 PM »
@whose
Quote
I really don't understand why it is so important to use such tricks, which are already blamed decades before, sry.

I am not promoting use of such tricks.
 

Offline whose

  • Newbie
  • *
  • Join Date: Dec 2006
  • Posts: 13
    • Show only replies by whose
Re: Counting on AllocVec's size memo..
« Reply #35 on: December 28, 2006, 02:40:35 PM »
@piru:

Not directly, that is true. But you do it indirectly by saying, that e.g. MOS supports such a practice and hence is "more compatible" (or better). See the difference?

OS4 discourages such practices active and I can't believe that they (the OS4 developers) did it to just say "hurray, we broke more applications than any other amiga-like OS".

It's now time to say "good bye" to tricks like this one (and some other).

Greetz
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show only replies by Piru
    • http://www.iki.fi/sintonen/
Re: Counting on AllocVec's size memo..
« Reply #36 on: December 28, 2006, 02:45:56 PM »
@whose
Quote
But you do it indirectly by saying, that e.g. MOS supports such a practice and hence is "more compatible" (or better). See the difference?

No. I know AmigaOS 2.x, 3.x and MorphOS works this way. If I knew how AROS works, I would have included it aswell. I see you're reading more to my comments, though.

Quote
OS4 discourages such practices active and I can't believe that they (the OS4 developers) did it to just say "hurray, we broke more applications than any other amiga-like OS".

That's fine. MorphOS does the same, really, but it tries to avoid breaking things if only possible. In this case the size could have been left to ptr - 4 without any ill effects.

Quote
It's now time to say "good bye" to tricks like this one (and some other).

Yes, was that in question anyway? The fact is that old, existing applications use such tricks, and the OS should not be broken here (even though such tricks are "illegal" and "undocumented").
 

Offline whose

  • Newbie
  • *
  • Join Date: Dec 2006
  • Posts: 13
    • Show only replies by whose
Re: Counting on AllocVec's size memo..
« Reply #37 on: December 28, 2006, 03:00:53 PM »
@piru:
Quote
No. I know AmigaOS 2.x, 3.x and MorphOS works this way. If I knew how AROS works, I would have included it aswell. I see you're reading more to my comments, though.


First: It was and is not meant as a personal offence, really.

Well, if I read more to your comments, why shouldn't (unexperienced) developers do? They will do it, and that's the problem. I spoke of "late absolution" given to such practices, this is an example.

Quote
Yes, was that in question anyway?


More or less.

Quote

The fact is that old, existing applications use such tricks, and the OS should not be broken here (even though such tricks are "illegal" and "undocumented").


Shouldn't it? Why? To support this tricks several decades more? To gain compatibility to broken software and discourage new developments in this direction?

I think that time will tell what the better way was. I don't see any real disadvantage for OS4 regarding the AllocVec() question.

Greetz
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show only replies by Piru
    • http://www.iki.fi/sintonen/
Re: Counting on AllocVec's size memo..
« Reply #38 on: December 28, 2006, 03:11:11 PM »
@whose

I've explained it already, but lets repeat once more:

Quote
Shouldn't it?

It shouldn't.

Quote
Why?

To avoid crashing old applications.

Quote
To support this tricks several decades more?

The only reason to have it here is to avoid crashing the apps that read the size from the ptr - 4. Nothing else.

Quote
To gain compatibility to broken software and discourage new developments in this direction?

Compatibility with old existing software. Debugging tools for the OS (or the debugging mode of the OS itself) should complain loudly if someone uses such tricks.

In fact, OS4 could have easily retained the "size at ptr - 4" for m68k apps (as far as I know). However, this was changed for both new and old apps. Why?
 

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16879
  • Country: gb
  • Thanked: 5 times
    • Show only replies by Karlos
Re: Counting on AllocVec's size memo..
« Reply #39 on: December 28, 2006, 04:07:10 PM »
I wonder just how difficult it would be to add this value back to ptr-4 with the new system.

Ok it isn't clean, but it shouldn't be that hard to do. Just clone the value from wherever else it is stored.
int p; // A
 

Offline Doobrey

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 1876
    • Show only replies by Doobrey
    • http://www.doobreynet.co.uk
Re: Counting on AllocVec's size memo..
« Reply #40 on: December 29, 2006, 03:13:16 PM »
Quote

Karlos wrote:
I wonder just how difficult it would be to add this value back to ptr-4 with the new system.


I was thinking the same earlier, but not I'm not 100% sure how OS4 handles the 68k->PPC library calls so this is all a wild guess.

I assume ExecSG must have a 68k jump table for compatibility with old apps( which jumps to a wrapper that does the 68k->PPC register handling and calls the PPC native function etc)
So is it just a simple matter of loading new AllocVec and FreeVec routines to memory and using SetFunction to insert them into the jump table?

Then again there's probably a major wrong assumption there somewhere, and  I could be talking outta my backside
On schedule, and suing
 

Offline Gilloo

  • Full Member
  • ***
  • Join Date: Apr 2006
  • Posts: 124
    • Show only replies by Gilloo
Re: Counting on AllocVec's size memo..
« Reply #41 on: January 05, 2007, 03:18:37 PM »
Quote

Jose wrote:
I was thinking on ways to keep track of a structs size and reminded that AllocVec keeps the size of allocated data in the pointer it returns - 1 IIRC.


Yes.
Look at this piece of ugly code: I use it in V34 routines...
APTR MAllocVec( unsigned long byteSize, unsigned long requirements )
{
  if (SysBase->LibNode.lib_Version >= 36)
  {
    return AllocVec(byteSize, requirements) ;
  }
  else
  {
    unsigned long *data = NULL ;

    byteSize += sizeof(unsigned long) ;
    data = (unsigned long *)AllocMem(byteSize, requirements) ;
 
    *data = byteSize ;
    data++ ;
    return data ;
  }
}

void MFreeVec( APTR memoryBlock )
{
  if (SysBase->LibNode.lib_Version >= 36)
  {
    FreeVec(memoryBlock) ;
  }
  else
  {
    unsigned long byteSize ;
    unsigned long *data ;

    data = (unsigned long*)memoryBlock ;
    data-- ;
    byteSize = *data ;
    FreeMem(data, byteSize) ;
  }
}

Quote

Jose wrote:
Probably a bit of a hack couting on it or it's not gonna change in the foresenable future, what do you guys think ?

AllocVec/FreeVec are shorthand implementations to AllocMem/FreeMem functions. Internaly, AllocVec uses AllocMem, and FreeVec... FreeMem.
AllocMem/FreeMem uses Allocate/Deallocate and so on...
You can modify AllocVec/FreeVec (with SetFunction) as you want, and add what you want before the data pointer returned by AllocVec (Process name, hunk, Programm name...) to track memory allocations. This story of size stored before pointer returned by AllocVec relies only on ONE implementation!!
 

Offline n-ary

  • Newbie
  • *
  • Join Date: Aug 2002
  • Posts: 8
    • Show only replies by n-ary
Re: Counting on AllocVec's size memo..
« Reply #42 on: January 09, 2007, 08:40:26 PM »
Quote

whose wrote:
Shouldn't it? Why? To support this tricks several decades more? To gain compatibility to broken software and discourage new developments in this direction?

Very good, as for a developer view.
But at the end of the day, isn't it how the end user experiences and appreciates the result what really matters?
The purpose of the whole endeavour?

So what does the end user get?

1. a working application + dirty code
 or
2. a crashing application + clean code + possibly some unperceivable performance gain?

Frankly, I see no way the option 2. could win, unless this is strictly a development system and "end users" are actually developers.
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show only replies by Piru
    • http://www.iki.fi/sintonen/
Re: Counting on AllocVec's size memo..
« Reply #43 on: January 09, 2007, 09:00:24 PM »
dupe (can be deleted if some mod runs into this)
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
    • Show only replies by Piru
    • http://www.iki.fi/sintonen/
Re: Counting on AllocVec's size memo..
« Reply #44 on: January 09, 2007, 09:02:13 PM »
MAllocVec will write zeropage if AllocMem fails, fixed version:
Code: [Select]
APTR MAllocVec( unsigned long byteSize, unsigned long requirements )
{
    if (SysBase->LibNode.lib_Version >= 36)
    {
        return AllocVec(byteSize, requirements);
    }
    else
    {
        unsigned long *data;

        byteSize += sizeof(unsigned long);
        data = (unsigned long *)AllocMem(byteSize, requirements);
        if (data)
        {
            *data = byteSize;
            data++;
        }
        return data;
    }
}


Small fix to MFreeVec aswell, in case this routine is to be used as drop-in replacement for FreeVec:
Code: [Select]

void MFreeVec( APTR memoryBlock )
{
    if (SysBase->LibNode.lib_Version >= 36)
    {
        FreeVec(memoryBlock);
    }
    else if (MemoryBlock)
    {
        unsigned long byteSize;
        unsigned long *data;

        data = (unsigned long*)memoryBlock;
        data--;
        byteSize = *data;
        FreeMem(data, byteSize);
    }
}


Excuse me, I just can't help myself. ;-)