[M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?]

[Dragiša Durić]

Single "execution space" can span over various architectures  in few ways. Examples - RPC and GPU.

RPC is nothing new and it does not presume multi architecture for single object file. Nor it presumes single address space for various components/processes. There is cross-process boundary where conversions (data marshaling/unmarshalling) happen. 

On the other hand, GPU programming… No cross-process boundary in RPC style, it almost looks like it is single executable - but it is not "multiple CPU architecture per single object". Nor does it include single address space for various object components included.

GPU is an excellent example of what you are, very obliquely, hinting at. But - it is not single object file for multiple architectures for single address space. 

It is probably good idea for you to look at GPU's today to see what is realistic in multi-architecture object generation/application.

On Apr 25, 2012, at 9:24 PM, Daniel Alejandro Benavides D. wrote:

> Hi all:
> Such as a module generating code, for sending both LONGINTs and LONGADDRESSes through networks of wide processing units MCU (e.g array processors)?
> http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=%22Address+register+2%22#search_anchor
> 
> http://books.google.com.co/books?id=oM4EAQAAIAAJ&q=74ACT8847#search_anchor
> 
> I guess I should tell you one, but there are too many to count examples, in any case you would want to be truly multi platform and cross-porting easier  in general, rather than based in one base case, though Modula was too good to make such things difficult in any case. If it serves to know multitasking of DEC has been emulated through the AMD Bulldozer microarchitecture with Array/Vector processor, etc. But it still needs more cooperation (or at least using shared standards) on the industry to return to those good days.
> 
> Thanks in advance 
> 
> --- El mié, 25/4/12, felipe valdez <dataf4l at gmail.com> escribió:
> 
> De: felipe valdez <dataf4l at gmail.com>
> Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?]
> Para: "Dragiša Durić" <dragisha at m3w.org>
> CC: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>, m3devel at elegosoft.com
> Fecha: miércoles, 25 de abril, 2012 11:08
> 
> that is quite a response.
> 
> 
> On Wed, Apr 25, 2012 at 8:08 AM, Dragiša Durić <dragisha at m3w.org> wrote:
> As my first hands-on CPU was 6502, I think I remember a lot.
> 
> ADDRESS is pointer size, and even C world spins around one pointer size per architecture. Of course there are various architectures, with their various specifics. Not only pointer size, of course.
> 
> What use would be to have two pointer sizes in single project? Do you expect one thread of your program to run on one CPU, second thread on another, different CPU?
> 
> On Apr 24, 2012, at 4:42 PM, Daniel Alejandro Benavides D. wrote:
> 
>> Hi all:
>> All the contrary Dragisha, do you remember the Micro's era 6809, 4004, etc, so then it became gradually 68000, 8088 - 80186, etc.
>> So we can see in ARM versions, but now, probably in AMD64, that they are planning the next step, as were the same histories for those days.
>> We could use it like for porting 32 bit backend to 64 bit painfully less stressful, I mean, even the OS/400 has this feature of 128 pointers to allow updating architecture, without language change.
>> 
>> So I'd guess is rather cross-portability, upwards and that's it. Of course this would require more TYPE declarations and VAR as well (LADR, LVAR), but could be less painful for the ones who want to port to that.
>> It must be done carefully aggressively because this is a changing world, what can I say? 
>> Thanks in advance
> 
> 
> 
> 
> -- 
> 312-444-2124
> Skype: f3l.headhunter
> Casa: 8043901
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120425/b8df354d/attachment-0002.html>