Where should the type information be 226

Whoa! You are talking about a philosophy; I'm talking about where I, the compiler, would place the bits you told me to generate. I, the compiler, cannot put your single-user code in any area, disk or memory, that is "available" to other users.

For example, you wish to reverse the heirarchy of arithmetic operators for some reason. You tell the compiler to replace its heirarchy with yours. It cannot merge that code with itself because that would change the default heirarchy to any body who uses the compiler after you do.

So your code generating requestion have to stay within your computing system boundaries and never placed in an area that would be used by other compiler users.

I suspect that this is why you and the others don't communicate well. They are viewing the problem from a developer's point of view, and you're viewing them from a single user's point of view.

I don't know enough about compiler development concepts to be able to helpfully comment here. Again you do seem to be buttuming that a compiler can generate compiler parsing rules according to your list. It shouldn't; that's what interpreters were for.

I'm going to play the Token Dummy here. Why do I, writing my little random access program using FORTRAN, have to know what machine instructions were generated by the compiler to give a number back?

Every FORTRAN compiler had its own methods for preserving arguments and it was very specific to the hardware architecture and resource limitations (memory, code vs. data size, and storage space). The reason some of the routine argument list definitions, generated by the compiler, were so klunky is because of a shortage of resources. As more resources became available per user, the klunkiness had to remain because of backwards compatibility of old programs.

For instance, on PDP-10s no registers were preserved when the core image was saved. IIRC, nothing below address 40 octal was saved. In order for FORTRAN to safely transmit all arugment lists from one segment to the next segment of code, all lists had to be in memory, not the ACs.

No, he never can. He doesn't have all the information to be able to override existing functional specifications. You are asking compiler developers to be able to throw out standards if you, as a user, write code to do so. This is folly. The whole point of using an HLL is so the user does not have to know all the details about how all architectures do their computing.

You can only give numbers for a particular architecture for a particular "snapshot", a.k.a. EXE file, of a compilation done at one point in time. Given most hard-software systems, I can change those numbers even though you never change your program.

But I think we're side-tracked here.

What you need is a better method to "look" at the code generated and an ability to "watch" that code execute. I don't know how people do this in today's HLL-Unix environment. I can almost guarantee that MS have removed that feature from NT.

BAH

Subtract a hundred and four for e-mail.