From dabenavidesd at yahoo.es Fri Oct 13 05:50:01 2017 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 13 Oct 2017 03:50:01 +0000 (UTC) Subject: [M3devel] Legacy of Modula-3 References: <1195349916.1409114.1507866601710.ref@mail.yahoo.com> Message-ID: <1195349916.1409114.1507866601710@mail.yahoo.com> Hello folks:I admire you too much because keep my learning and what a surprise, the underlying theory of JVM verifier in its latest version, (in the sense of bytecode verifier, not JVM architecture exerciser which AFAIK is proprietary, but heck we have VAX one) is derived from Cardelli/Nelson veneer (with Cardelli-Abadi seminal work on Baby Modula-3 and a Theory of objects as Nelson/George Necula Peter Lee Proof Carrying code).As I understand these type systems are so solid and strong that you can prove besides programs don't go wrong many more properties than simpler systems can, e.g security. See [1]:https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-0-preface7.html Keep the language alive folks [1] ?CiteSeerX ? Towards Secure Bytecode Verification on a Java Card?. [On line]. Available on: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.50.4920. [Accesed: 13-oct-2017]. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sun Oct 22 02:14:12 2017 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 21 Oct 2017 19:14:12 -0500 Subject: [M3devel] Assert problem In-Reply-To: References: Message-ID: On 10/15/2017 05:28 PM, Peter McKinna wrote: > Hi Rodney, > > I'm getting an assert error in M3CG_LLVM.m3 line 2131 running test p004 (and a couple of others) Can you duplicate it? I'm using the latest I think. > Are you asking for debug info from the llvm backend? This has assertion failures that I have not tracked down. I disable llvm generation of debug info by commenting out /usr/local/bin/config/Unix.common:144 'args += "-g'. However, when I enable it, m3llvm runs to completion on p004, so I am not getting the failure you are. But later, in llc, I get a different, C++ assertion failure: llc -disable-fp-elim -filetype=asm -relocation-model=pic Main.mb -o Main_m.s llc: /home/rodney/proj/llvm/llvm-3.6.1/llvm-3.6.1.src/include/llvm/CodeGen/MachineInstr.h:261: llvm::DIExpression llvm::MachineInstr::getDebugExpression() const: Assertion `Expr.Verify() && "not a DIExpression"' failed. This seems to be some undocumented invariant that llvm has for its IR, but, unlike many others, does not get checked by the llvm C++ IR-building code linked into m3llvm, instead showing up only later in llc. That makes it difficult even to find what part of the compiled program has this problem. This is on AMD64_LINUX, the only target I have done any testing on. > Also, how do you run the test suite using the llvm backend? I just put that define > M3_BACKEND_MODE="StAloneLlvmAsm" in the top level m3makefile in m3tests/src and ran it. But I think the define does not make it into the local m3makefile in each test directory so it just runs the default gcc backend. > I have M3_BACKEND_MODE="StAloneLlvmAsm" in my /usr/local/cm3/bin/cm3.cfg, and it seems to propagate to all the tests. For a quick (but verbose) check, I invoke with 'cm3 -commands' which will show the invocation of m3llvm, llc, etc. The flow of information of these options is a huge maze, and I always dread trying to trace it for some specific thing, Info goes back and forth between quake and m3 code, and there is no simple way to dig out the set and order of quake files being interpreted. There should be a better way, that applies only to the tests, not everything you run cm3 on. I have to remember to keep changing my cm3.cfg back and forth to recompile a new compiler, using gcc backend, then run tests using the llvm backend. (Fortunately, I have it scripted.) The llvm backend will produce a correctly built compiler, but only without any significant debug info, making it hard to move to the next step. > Regards Peter -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sun Oct 22 02:40:54 2017 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 21 Oct 2017 19:40:54 -0500 Subject: [M3devel] Assert problem In-Reply-To: References: Message-ID: On 10/15/2017 05:28 PM, Peter McKinna wrote: > Hi Rodney, > > I'm getting an assert error in M3CG_LLVM.m3 line 2131 running test p004 (and a couple of others) Can you duplicate it? I'm using the latest I think. > A quick glance at this line hints to me that you might not be getting the front end to pull nested procedures out and put them after their parent. I do not get this failure. p004 does not have explicit nested procs in source code, but it has FINALLY blocks, which get lowered by the front end into nested procs. I have, in /usr/local/cm3/bin/config/cm3cfg.common:549, M3_FRONT_FLAGS = ["-unfold_nested_procs", "-check_procs" ] which should make the front end do this. -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sun Oct 22 03:14:22 2017 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 21 Oct 2017 20:14:22 -0500 Subject: [M3devel] Correction: Re: [modula3/cm3] Packed set literal generation issue (#21) In-Reply-To: <59d825fa-832d-c945-6334-ea905ba55db7@lcwb.coop> References: <59d825fa-832d-c945-6334-ea905ba55db7@lcwb.coop> Message-ID: <9e76ff0f-a477-2608-4587-95a194ba584a@lcwb.coop> On 09/23/2017 10:59 AM, Rodney M. Bates wrote: > The following didn't come through the first time, at least not to me: > > > Fixed on github, commit 12f50b4cde746056b943bd8aaa105c3fcb46b1a8 > > Deleted the assertion, which is neither true nor needed. > > But see below: > > On 09/16/2017 11:54 PM, jcchu wrote: >> See the fragment below. >> >> VAR r := SET OF [0..31] { 0 }; (* OK *) >> s := BITS 32 FOR SET OF [0..31] { 0 }; (* -- assertion failure in ?SetExpr.m3? *) > > Are you aware that the BITS 32 here has no effect on the size of the global variable? > > Quoting from 2.2.5, Packed types: > > TYPE T = BITS n FOR Base > > where Base is a type and n is an integer-valued constant expression. > The values of type T are the same as the values of type Base, but variables of type T > that occur in records, objects, or arrays > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > will occupy exactly n bits and be packed adjacent to the preceding field or element. > > s is not inside a record, object, or array, so the BITS specification has no effect on > the memory allocated by the compiler. > > There are, however some more obscure differences: > > 1) Although T and BITS n FOR T are are assignable to each other, > BITS n FOR T and BITS m FOR T, (n#m) have no subtype or assignability > relationship, so to assign one to the other would require two assignment > steps, with a T as the intermediate type. I had thought the above was true was true for a long time, but recently realized I was mistaken about that. Since <: is transitive, these two packed types are subtypes of each other, transitively through T, and thus mutually assignable. I haven't checked whether we have this implemented correctly. > > 2) Anywhere type equality, as opposed to assignability, is required, T and > BITS n FOR T will not match. For example, you cannot pass one of these to > the other as a VAR parameter. > > -- Rodney Bates rodney.m.bates at acm.org From jcchu at acm.org Sun Oct 22 05:18:07 2017 From: jcchu at acm.org (JC Chu) Date: Sun, 22 Oct 2017 03:18:07 +0000 Subject: [M3devel] Correction: Re: [modula3/cm3] Packed set literal generation issue (#21) In-Reply-To: <9e76ff0f-a477-2608-4587-95a194ba584a@lcwb.coop> References: <59d825fa-832d-c945-6334-ea905ba55db7@lcwb.coop> <9e76ff0f-a477-2608-4587-95a194ba584a@lcwb.coop> Message-ID: >> 1) Although T and BITS n FOR T are are assignable to each other, BITS n FOR T and BITS m FOR T, (n#m) have no subtype or assignability relationship, so to assign one to the other would require two assignment steps, with a T as the intermediate type. > > I had thought the above was true was true for a long time, but recently realized I was mistaken about that. Since <: is transitive, these two packed types are subtypes of each other, transitively through T, and thus mutually assignable. This got me wondering, where is the subtyping rules for packed types? The language definition, in ?2.10, says specifically that, ?for example, a?record or array type with packed fields contains the same values as the corresponding type with unpacked fields, but there is no subtype relation between them?. ? JC -----Original Message----- From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] Sent: Sunday, October 22, 2017 9:14 To: m3devel ; JC Chu ; Rodney Bates Subject: Correction: Re: [modula3/cm3] Packed set literal generation issue (#21) On 09/23/2017 10:59 AM, Rodney M. Bates wrote: > The following didn't come through the first time, at least not to me: > > > Fixed on github, commit 12f50b4cde746056b943bd8aaa105c3fcb46b1a8 > > Deleted the assertion, which is neither true nor needed. > > But see below: > > On 09/16/2017 11:54 PM, jcchu wrote: >> See the fragment below. >> >> VAR r := SET OF [0..31] { 0 }; (* OK *) >> s := BITS 32 FOR SET OF [0..31] { 0 }; (* -- assertion failure in ?SetExpr.m3? *) > > Are you aware that the BITS 32 here has no effect on the size of the global variable? > > Quoting from 2.2.5, Packed types: > > TYPE T = BITS n FOR Base > > where Base is a type and n is an integer-valued constant expression. > The values of type T are the same as the values of type Base, but variables of type T > that occur in records, objects, or arrays > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > will occupy exactly n bits and be packed adjacent to the preceding field or element. > > s is not inside a record, object, or array, so the BITS specification has no effect on > the memory allocated by the compiler. > > There are, however some more obscure differences: > > 1) Although T and BITS n FOR T are are assignable to each other, > BITS n FOR T and BITS m FOR T, (n#m) have no subtype or assignability > relationship, so to assign one to the other would require two assignment > steps, with a T as the intermediate type. I had thought the above was true was true for a long time, but recently realized I was mistaken about that. Since <: is transitive, these two packed types are subtypes of each other, transitively through T, and thus mutually assignable. I haven't checked whether we have this implemented correctly. > > 2) Anywhere type equality, as opposed to assignability, is required, T and > BITS n FOR T will not match. For example, you cannot pass one of these to > the other as a VAR parameter. > > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Sun Oct 22 23:51:13 2017 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 22 Oct 2017 16:51:13 -0500 Subject: [M3devel] Correction: Re: [modula3/cm3] Packed set literal generation issue (#21) In-Reply-To: References: <59d825fa-832d-c945-6334-ea905ba55db7@lcwb.coop> <9e76ff0f-a477-2608-4587-95a194ba584a@lcwb.coop> Message-ID: On 10/21/2017 10:18 PM, JC Chu wrote: >>> 1) Although T and BITS n FOR T are are assignable to each other, BITS n FOR T and BITS m FOR T, (n#m) have no subtype or assignability relationship, so to assign one to the other would require two assignment steps, with a T as the intermediate type. >> >> I had thought the above was true was true for a long time, but recently realized I was mistaken about that. Since <: is transitive, these two packed types are subtypes of each other, transitively through T, and thus mutually assignable. > > This got me wondering, where is the subtyping rules for packed types? The language definition, in ?2.10, says specifically that, ?for example, a record or array type with packed fields contains the same values as the corresponding type with unpacked fields, but there is no subtype relation between them?. > Not sure what you are asking here. All the subtyping rules are in and only in 2.2.10. \ The only ones specific to packed types are BITS n FOR T <: T and T <: BITS n FOR T plus the general transitivity and reflexiveness of the relation. The specific rules given ensure that every value of a subtype is a value of any supertype, but types that satisfy this value inclusion rule are not necessarily in the subtype relation. The example of two records with corresponding fields that have different types but one is a proper subtype of the other illustrates this. So does the example of AU and AT. It would be a big implementation complexity if you could assign a record to a different record type that was the same except for the bit packing of the fields. That is presumably why such records are not subtype-related. > ? JC > > > -- Rodney Bates rodney.m.bates at acm.org From jcchu at acm.org Mon Oct 23 03:08:29 2017 From: jcchu at acm.org (JC Chu) Date: Mon, 23 Oct 2017 01:08:29 +0000 Subject: [M3devel] Correction: Re: [modula3/cm3] Packed set literal generation issue (#21) In-Reply-To: References: <59d825fa-832d-c945-6334-ea905ba55db7@lcwb.coop> <9e76ff0f-a477-2608-4587-95a194ba584a@lcwb.coop> Message-ID: My apologies; please ignore my previous message. Obviously I misread the article: didn?t see the rules I was looking for and misinterpreted what I quoted. :( ? JC -----Original Message----- From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] Sent: Monday, October 23, 2017 5:51 To: m3devel at elegosoft.com; JC Chu Subject: Re: [M3devel] Correction: Re: [modula3/cm3] Packed set literal generation issue (#21) On 10/21/2017 10:18 PM, JC Chu wrote: >>> 1) Although T and BITS n FOR T are are assignable to each other, BITS n FOR T and BITS m FOR T, (n#m) have no subtype or assignability relationship, so to assign one to the other would require two assignment steps, with a T as the intermediate type. >> >> I had thought the above was true was true for a long time, but recently realized I was mistaken about that. Since <: is transitive, these two packed types are subtypes of each other, transitively through T, and thus mutually assignable. > > This got me wondering, where is the subtyping rules for packed types? The language definition, in ?2.10, says specifically that, ?for example, a record or array type with packed fields contains the same values as the corresponding type with unpacked fields, but there is no subtype relation between them?. > Not sure what you are asking here. All the subtyping rules are in and only in 2.2.10. \ The only ones specific to packed types are BITS n FOR T <: T and T <: BITS n FOR T plus the general transitivity and reflexiveness of the relation. The specific rules given ensure that every value of a subtype is a value of any supertype, but types that satisfy this value inclusion rule are not necessarily in the subtype relation. The example of two records with corresponding fields that have different types but one is a proper subtype of the other illustrates this. So does the example of AU and AT. It would be a big implementation complexity if you could assign a record to a different record type that was the same except for the bit packing of the fields. That is presumably why such records are not subtype-related. > ? JC > > > -- Rodney Bates rodney.m.bates at acm.org From jcchu at acm.org Tue Oct 24 17:00:10 2017 From: jcchu at acm.org (JC Chu) Date: Tue, 24 Oct 2017 15:00:10 +0000 Subject: [M3devel] Are ROOT and OBJECT END the same type? Message-ID: First, no subtyping rule is given for pairs of branded and unbranded types. For example, it's neither the case that BRANDED REF BOOLEAN <: REF BOOLEAN nor vice versa, based on what's given in ?2.10. This explains why the an opaque type declared as a subtype of the latter cannot be revealed to be the former. By the same reasoning, the compiler is also correct in rejecting T <: OBJECT END to be revealed as T = BRANDED OBJECT END, ... or is it? It's pretty common to declare some T <: ROOT and then reveal T as a branded object type. So the fact that the revelation above is not accepted means that ROOT and OBJECT END are not the same type. But according to ?2.9, ROOT is "the traced object type with no fields or methods", which (I think) is OBJECT END. Or am I missing something here? - JC -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcchu at acm.org Wed Oct 25 04:31:33 2017 From: jcchu at acm.org (JC Chu) Date: Wed, 25 Oct 2017 02:31:33 +0000 Subject: [M3devel] Are ROOT and OBJECT END the same type? In-Reply-To: References: Message-ID: Thanks. ?2.9 does say that if the prefix "is omitted, it defaults to ROOT". - JC From: Hosking, Antony L [mailto:hosking at purdue.edu] Sent: Tuesday, October 24, 2017 23:13 To: JC Chu Cc: m3devel at elegosoft.com Subject: Re: [M3devel] Are ROOT and OBJECT END the same type? OBJECT END is the same as ROOT OBJECT END. All object types inherit from ROOT. Sent from my iPad On Oct 24, 2017, at 8:00 AM, JC Chu > wrote: First, no subtyping rule is given for pairs of branded and unbranded types. For example, it's neither the case that BRANDED REF BOOLEAN <: REF BOOLEAN nor vice versa, based on what's given in ?2.10. This explains why the an opaque type declared as a subtype of the latter cannot be revealed to be the former. By the same reasoning, the compiler is also correct in rejecting T <: OBJECT END to be revealed as T = BRANDED OBJECT END, ... or is it? It's pretty common to declare some T <: ROOT and then reveal T as a branded object type. So the fact that the revelation above is not accepted means that ROOT and OBJECT END are not the same type. But according to ?2.9, ROOT is "the traced object type with no fields or methods", which (I think) is OBJECT END. Or am I missing something here? - JC _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Oct 25 17:40:29 2017 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 25 Oct 2017 10:40:29 -0500 Subject: [M3devel] Assert problem In-Reply-To: References: Message-ID: <1dad1ec3-0746-dad0-4ccc-bd6ea9b82cd9@lcwb.coop> On 10/22/2017 08:56 PM, Peter McKinna wrote: > Oh and a couple of other things. > > I hadn't tried commands, very useful. > > Running cm3 -O to optimise to O2 our only optimisation level sets O0 in llc, in effect removing optimisation. > (I don't know why we cant replicate gcc and llvm on some of these command line options ie having O0 O1 O2 etc which get passed to the backend) > Yes, we should do this. It could force somebody to update some existing scripts with different options, but probably not too big a problem, if we communicate it well. > I've installed llvm version 5.0 and built a set of swig based bindings for DIBuilder, only partially tested. I could put on github in a directory dibindings ?? under llvmbindings and you could evaluate and see if its worth using. The benefit is that it's quite easy to upgrade the bindings when they change versions. Or I could email a tarball. > That would be great. How about a directory named something like m3-sys/llvm5.0bindings? When we first went to git, I tried out git branches, but found it almost impossible to be able to look at diffs between branches, something I need to do often. It seems git will only check out one branch at a time into one's working directory, removing the previous branch in the process. In any case, since m3llvm is a separate executable and llvmbindings is a separate library, it seems like having multiple versions in different subdirectories in the same branch should not create problems. Then we could create m3-sys/llvm5.0 for the m3llvm version to use llvm5.0bindings. There was discussion in the llvm mailing list of significant reorganization of DIBuilder's type hierarchy, affecting the API, so probably all the DIBuilder calls in m3llvm will need review and some of them changed. I think this will probably be a change for the better, in producing debug info. > We should probably upgrade to llvm 5.0. There are lots of bugfixes and I'd like to test their 128 bit floating point stuff in the hope of changing EXTENDED to use it someday, assuming its easy to change the gcc backend at the same time. I think they have changed the C api again judging by the release notes so the m3 interface will need updating. > > Regards Peter > -- Rodney Bates rodney.m.bates at acm.org