At 07:50 AM 3/7/2005, Leopold Toetsch wrote:
Roger Browne <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-03-07 at 11:01 +0100, Leopold Toetsch wrote:
>> 4.1.1) implement a language pragma in assembler, e.g.:
>>
>> .HL_language Python
Sounds good to me except that I would prefer you remove the HL_
and just call it .language to be consistent with other directives.
Incidentally this is what .NET uses as well except its implementation
uses GUID instead of a string, and it also allows the compiler
vendor and source document type to be included in the directive.
Dan and I talked about this a couple of years ago on IRC.
Originally I wanted to stay away from GUIDs as I think they are overkill,
and had considered allowing ASCII:
.language Perl6
.language Perl6:ThePerlFoundation
But..., this requires this section in the bytecode to be variable sized,
so there might be some merit to using GUIDs, especially for vendors.
I think to keep PIR "convenient" for hackers I want to accept both
strings and 32 bit integers for each. If a string, it must be already
registered in IMCC and we can probably reserve the first 1024 for
"pre-registering" but IMCC still would be able to accept integers.
In any case, it needs to be fixed width in the bytecode header.
We need to revisit the bytecode format. Last time through, I put
an "Opcode type" at some offset, per Dan's request.
We store a magic number for that. I'm pretty sure we can use
this field to identify the language using whatever is provided in the
.language pragma, but I can't speak for Dan. I think he might
have had different plans for opcode type.
-Melvin
