[M3devel] LONGADDRESS [was: Re: Downsides of Modula-3 ?]
Daniel Alejandro Benavides D.
dabenavidesd at yahoo.es
Thu Apr 26 20:56:59 CEST 2012
Hi all:
Well, I'm not so passing the fact that it is a computer more than a language what we are talking here.
I was reading had several kinds of invariant type rules or covariant ones, but they found it was harder than they thought, so, I'm more type-orthogonal as such in Modula-3, the questions are more related to that than how to control language capabilities, which are very much simplified, however no many languages try to do the other part see what's in the machine.
I think Dragisha's point is whether I reply myself, or just himself. So I don't care if anybody responses that's for sure, thought I won't do that my self.
Thanks in advance
--- El jue, 26/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: jueves, 26 de abril, 2012 13:34
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.headhunterCasa: 8043901
--
312-444-2124Skype: f3l.headhunterCasa: 8043901
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120426/230e5f19/attachment-0002.html>
More information about the M3devel
mailing list