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

Thu Apr 26 20:34:08 CEST 2012

English, here, is the keyword.

On Thu, Apr 26, 2012 at 12:44 PM, Dragiša Durić <dragisha at m3w.org> wrote:

> Daniel,
>
> LONGINT and INTEGER are scalar types with no relation except one's values
> are subset of another. References to them are strongly typed in Modula-3 -
> meaning types are semantically different - but their representation is same
> as ADDRESS. In single address space you have all memory location
> addressable by same pointer type - ADDRESS. They can differ in alignment,
> depending on implementation decisions, but that is something else.
> Implementation-wise, REF LONGINT and REF INTEGER are same type. Implied
> semantical informationis used where it is needed and it is not worry of
> language user unless she/he does something related to language environments
> other than Modula-3. Think RPC, OpenCL (GPU), ...
>
> On LINUXLIBC6 ADDRESS type is 32bit, 4byte. On AMD64_DARWIN it's 64bit,
> 8byte. Most 64bit platforms today are limited in number of address lines
> from CPU to memory, IIRC Alpha had 48bit physical memory interface. I am
> sure it is limited to some number smaller than 64 on every 64bit platform
> today. But - that does not mean (Modula-3) language implementor will make
> PHYSADDRESS pointer type 6 bytes long. You probably can find such types in
> some experimental languages you are interested in. Good luck there, for/but
> I am not :).
>
> Unless my English-foreign is mismatched more than I think to your
> English-foreign, we are almost orthogonal in this discussion for some time.
> I checked, I am still writing to m3devel. Are you? :)
>
> dd
>
> On Apr 26, 2012, at 6:58 PM, Daniel Alejandro Benavides D. wrote:
>
> Hi all:
> In that sense, it's neither Physical or logical but process communications
> are both (so hat's why its called Inter-process), but conceptually, you can
> speak of that if that's what you mean.
> In one of such architectures (as a Bus-oriented architecture
> micro-processor) there are Logical Address (INTEGER), as the direction of a
> physical processor bus ID, (where there is a one to one mapping LBID to
> PBID) or a System Bus ID (ADDRESS), which identifies the location of a
> kernel function.
> Thank your  LONGINT  is easy just to say  LONGINT->LONGADDRESS, because
> you would want such a type of LBID address and function location, wouldn't
> you? And then the location itself is and expressed by REF LONGINT<:REF
> INTEGER
> and LONGADDRESS<:ADDRESS so that the same function maps
> LONGINT ->ADDRESS
> Modula-3 type hierarchy does say that, doesn't it? This is because it is
> contra variant type hierarchy.
> Thanks in advance
>
>
> --- El *mié, 25/4/12, Dragiša Durić <dragisha at m3w.org>* escribió:
>
>
> De: Dragiša Durić <dragisha at m3w.org>
> Asunto: Re: [M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?]
> Para: "Daniel Alejandro Benavides D." <dabenavidesd at yahoo.es>
> CC: "felipe valdez" <dataf4l at gmail.com>, m3devel at elegosoft.com
> Fecha: miércoles, 25 de abril, 2012 16:37
>
> 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
>
>
>
>
>

-- 
312-444-2124
Skype: f3l.headhunter
Casa: 8043901
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120426/326c1599/attachment-0002.html>