On Thu, Jun 4, 2015 at 10:34 AM, René Jansen <rvjan...@xs4all.nl> wrote:
> But network order does not ring as relevant in my ears for this particular > usage. > > Thinking along lines of memory model, you once faced the decision of > having a 64 or 32 bit size for Rexx objects, and I remember the discussion > on the list in which we (iirc) all were in favor of 64 bitness and did not > realize this meant something for compatibility with RexxSAA. Without > wanting to return to that discussion, I would like to pose as an > hypothetical a model in which we can address the full address space but > limit the pointers to the objects to 32 bits - or 31 in a particular > environment that I have in mind. > > Would that be at least thinkable? (Well thunkable - to insert the obvious > OS/2 in-joke here). > Good luck finding somebody to implement this. I certainly would not try this. And I also do not agree with the assertion that this lbroke RexxSAA compatibility. The only compatibility problem was between ooRexx and Regina because Mark chose to continue using 32-bit lengths for string values in the interface (long before ooRexx was made 32-bit capable). The ooRexx version of the API made the change to use ansi-defined portable integer types so that sizes were appropriate to the compilation environment. At the point I took up that work, I had a considerable amount of experience with 32/64-bit portability issues from my years working on the IBM JVM, not to mention my prior experience in moving from 16-bit to 32-bit on OS/2. I believed (and still believed) that the approach taken with the APIs was the appropriate one. And the issue was not one of pointer size, but rather how the sizes of string lengths are defined. Restricting the lengths to 32-bits would really not help with compatibility and would just cause grief to any developers who were wishing to make the transition to 64-bit....and they would get a crippled implementation that would not be fully capable of exploiting the 64-bit addressing. Rick > > best regards, > > René. > > On 29 mei 2015, at 13:30, Rick McGuire <object.r...@gmail.com> wrote: > > Big Endian is also known as network order in some contexts, but the > network order usage does seem to include a term for "non-network order". > > Rick > > > On Fri, May 29, 2015 at 7:06 AM, René Jansen <rvjan...@xs4all.nl> wrote: > >> > >> > 2) Also not sure I like the "architecture" name, since this is not >> really a hardware architecture. >> >> Address size? >> Another possibility is memory model, there could be different operand >> sizes than address sizes, like some JVMs do. >> >> > >> > 3) An actual hardware architecture one might be nice...not sure I want >> to get into the issue of defining what is returned for that at this time. >> This can easily be added later. >> >> It would be great if this could just match what the OS reports to us, >> like in uname -a. Windows must have a call for that also. >> >> > 4) Do we need some sort of byte-order indicator (i.e., endian-ness). >> Not sure what values we're return for that. >> >> I think Big Endian or Little Endian, alternatively. MSB-first or LSB-first >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfoorexx-devel >> <https://lists.sourceforge.net/lists/listinfo/oorexx-devel> >> > > > ------------------------------------------------------------------------------ > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > >
------------------------------------------------------------------------------
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
