Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On 11/21/2013 01:03 AM, Sieghard wrote: the values you assign to the symbols (bit patterns, in this case) are just convention. And don't matter as long as no calculation can return a result outside of the base set. Yep. And for casting them to bigger types (also implicitly when doing operation between them and a bigger partner) the obvious way is sign-extension (i.e. duplicate highest order bit i.e. sign bit) for signed types and zero-extend unsigned types. As the extend operation is not allowed to change the value, it's obvious that for a 1 bit signed type the possible values are 0 and -1. This is what I tried to show with the example. -Michael -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On 11/19/2013 09:20 PM, Sieghard wrote: Yep. The highest order bit in a number in the 2's complement encoding is the sign bit. Ok, let's look at it this way. Then, what's the value of this lone sign bit? This is obvious. Take a look at the predecessor of zero as done by the algorithm any (modern) ALU does with eight bits: - : interpreted as signed: 0 - -1, interpreted as unsigned 0 - 255 (=2^8-1) with two bits: 00 - 11 : interpreted as signed: 0 - -1, interpreted as unsigned 0 - 3 (=2^2-1) with one bits: 0 - 1 : interpreted as signed: 0 - -1, interpreted as unsigned 0 - 1 (=2^1-1 ) -Michael -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Michael, Du schriebst am Wed, 20 Nov 2013 11:22:41 +0100: Ok, let's look at it this way. Then, what's the value of this lone sign bit? This is obvious. Then give the value. Take a look at the predecessor of zero as done by the algorithm any (modern) ALU does That's simply the same as its successor, because we're dealing with a cyclically ordered number set. Just like, e.g. weekdays. The arithmetic used for these is called modulus arithmetic. Yes, and the values you assign to the symbols (bit patterns, in this case) are just convention. And don't matter as long as no calculation can return a result outside of the base set. -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On 11/18/2013 10:51 PM, Sieghard wrote: Hallo Michael, Could you please keep sufficient context so even a casual reader can surmise what was meant? Thank you. Nope. That is what message threads do. So you say a single bit can be signed? Yep. The highest order bit in a number in the 2's complement encoding is the sign bit. No. Show me an ALU that calculates with signed bits. How does it determine whether a 1 is positive or negative? Not at all. (Please do read more about 2's complement encoding. ) When adding or subtracting, the ALU does not care about the type being signed or unsigned. The resulting bits are the same. (i.e. the resulting status Bits also are the same in the ALU, the compiler only interprets them according to the type of the result if it needs to take care of the potential sign of the result. ) -Michael -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On 11/18/2013 11:03 PM, Sieghard wrote: Even if it is larger than any of the other operands? Yep. That is how it usually is done. Extend or sign-extend after the operation if the target is larger, truncate if it is smaller. Size extend always at runtime? Yep (If necessary): Adding leading sign bits for signed types and adding leading Zeros with unsigned types. - use signed if one operand is signed And what if another one of the same or larger bit size is not? First extend either to appropriate bit count and then take care of different signedness of the two. -Michael -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Michael, Du schriebst am Tue, 19 Nov 2013 12:40:11 +0100: [about constant folding] I sure hope you'll never get to working on a compiler (and fear you might have already...) -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Michael, Du schriebst am Tue, 19 Nov 2013 12:32:40 +0100: Could you please keep sufficient context so even a casual reader can surmise what was meant? Thank you. Nope. Alright. I'll not respond to such garbage then. So you say a single bit can be signed? Yep. The highest order bit in a number in the 2's complement encoding is the sign bit. Ok, let's look at it this way. Then, what's the value of this lone sign bit? _Where_ does it have a value? There's not one bit that could give it a value, so it's 0, and constantly so. It doesn't need to be stored, so you can remove it. You can remove all single bit variables then. When adding or subtracting, the ALU does not care about the type being signed or unsigned. The resulting bits are the same. (i.e. the resulting status Bits also are the same in the ALU, the compiler only interprets them according to the type of the result if it needs to take care of the potential sign of the result. ) Give proof. -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On 11/15/2013 08:28 PM, Sieghard wrote: _What_ bit count should it use if you use it within an expression where operands of different I already did mention this. The obvious definition is - neglect the size of the variable to store the result in - for constants use the smallest bit count it fits in - use signed if one operand is signed - use the bit count of the operand with the greater bit count (here it optionally might be added rounded up to one of a native architecture's word size, usually 8, 16, 32, 64, ...) -Michael -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Michael, Du schriebst am Mon, 18 Nov 2013 12:30:09 +0100: [min/max constants] _What_ bit count should it use if you use it within an expression where operands of different I already did mention this. The obvious definition is Obvious to whom? - neglect the size of the variable to store the result in Even if it is larger than any of the other operands? - for constants use the smallest bit count it fits in What if larger bit size values appear in the calculation? Size extend always at runtime? - use signed if one operand is signed And what if another one of the same or larger bit size is not? - use the bit count of the operand with the greater bit count (here it optionally might be added rounded up to one of a native architecture's word size, usually 8, 16, 32, 64, ...) -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Michael, Du schriebst am Mon, 18 Nov 2013 11:25:36 +0100: I.e. there's no difference, you say? Could you please keep sufficient context so even a casual reader can surmise what was meant? Thank you. So you say a single bit can be signed? Yep. This is how binary operations work in all modern architectures. (In No. Show me an ALU that calculates with signed bits. How does it determine whether a 1 is positive or negative? the past, there have been some machines that did have a separate sign bit and thus there was a +0 and a -0, but this kind of arithmetic dies The +0 vs. -0 ambiguity stems from the time when the 2's complement representation wasn't so firmly established as nowadays yet. It is a property of thew so-called 1's complement arithmetic implementation, where the negative of a number was derived ba simply inverting it bit-wise. Thus, +0 was represented by a all-0s memory cell, but then -0 had the representation as an all-1s memory cell, although it is the same value. Note from that that the commonly used implementation of arithmetic functions and the accompanying number representation is a _convention_ _only_! There _are_ other implementations in use, and many more are conceivable. They just need different calculation units and produce (and use) different number representations. -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On 11/14/2013 09:28 PM, Sieghard wrote: It might not be very neccessary if these types aren't compatible among each other. Range checking has to be done only on coercion then, i.e. when assigning a value cast from a - any - different type. I understand that Martin is (IMHO) correctly assuming that range restricted numerical types (only) make sense if you do realtime range checking on them. You won't usually even realize that it's been done. It would be noticably only under very specific circumstances, such as a loop with many deeply nested calculations using a lot of different variables of such type, running over a large range of the controlling variable, i.e. a long time, or very often. Martin explicitly stated that compile and execution speed is one of the reasons that nudged him to start the mseLang project. So this should not be invalidated by not having the possibility to use bitsize restricted (but not explicitly range restricted) variables without realtime range checking. simulated bit fields this is not at all what I would want. Typical C attitude - no checking, please, I want to shoot me in the foot silently! ;- Yep. It should be possible to decide if I want the fastest or the most secure code. You wouldn't be satisfied by a compiler directive, like Delphi, FPC and most others do it? Even C has the pragma statement for such puposes, and gcc extends its syntax quite far to achieve similar things. First I ask for a syntax that frees me from manually calculating the range that is imposed by a bit count: with 1 Bits -1..0 means the same as signed and 0...1 means the same as unsigned. with 2 Bits -2..1 means the same as signed and 0...3 means the same as unsigned. with 3 Bits -4..4 means the same as signed and 0...7 means the same as unsigned. with n Bits -(2^(n-1))..(2^(n-1)-1) means the same as signed and 0...(2^n-1) means the same as unsigned. on top of that this syntax _might_ decide whether or not range checking is imposed. This of course might be decided by another keyword. but I don't think this is necessary. A compiler option is not a good Idea, as with same you can't define the range checking separately for each type. Her I feel that it's really logical to define that range checking is imposed exactly when the programmer explicitly defines a range. -Michael -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On 11/14/2013 08:12 AM, Martin Schreiber wrote: I don't like it. Or with reserved words: type boolty = max: 8; //bool8 cardty = 0 to max: 8;//card8 intty = smin to smax: 8; //int8 charty = #max: 8;//char8 floatty = -.max to .max: 64; //flo64 recordty b: max: 8;//bool8 c: 0 to max: 8; //card8 i: smin to smax: 8; //int8 ch: #max: 8; //char8 f: -.max to .max: 64; //flo64 end; IMHO using the keyword signed and unsigned with a given bit size (instead of something like 0..max and -max..max) is shorter and more intuitive. -Michael -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Friday 15 November 2013 09:37:29 Michael Schnell wrote: On 11/14/2013 08:12 AM, Martin Schreiber wrote: I don't like it. Or with reserved words: type boolty = max: 8; //bool8 cardty = 0 to max: 8;//card8 intty = smin to smax: 8; //int8 charty = #max: 8;//char8 floatty = -.max to .max: 64; //flo64 recordty b: max: 8;//bool8 c: 0 to max: 8; //card8 i: smin to smax: 8; //int8 ch: #max: 8; //char8 f: -.max to .max: 64; //flo64 end; IMHO using the keyword signed and unsigned with a given bit size (instead of something like 0..max and -max..max) is shorter and more intuitive. That is not enough, keywords for boolean, character and float types are necessary too. Martin -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Friday 15 November 2013 09:33:32 Michael Schnell wrote: On 11/14/2013 09:28 PM, Sieghard wrote: It might not be very neccessary if these types aren't compatible among each other. Range checking has to be done only on coercion then, i.e. when assigning a value cast from a - any - different type. I understand that Martin is (IMHO) correctly assuming that range restricted numerical types (only) make sense if you do realtime range checking on them. Compile time range checks already have a benefit. type subty = 0 to 5; var sub1: subty; i1: int32; ... sub1:= 123; --- compiler error sub1:= i1; --- compiler error sub1:= subty(i1); --- runtime range check Martin -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Friday 15 November 2013 13:46:48 Michael Schnell wrote: On 11/15/2013 10:21 AM, Martin Schreiber wrote: That is not enough, keywords for boolean, character and float types are necessary too. Boolean: of course it needs to be possible to define 1 Bit booleans, so using the same syntax does make sense But I doubt that providing bitcount-restricted chars or floats is really useful o doable in a sensible way. How do you define char8/char16/char32 float32/float64 then if you don't want to be forced to write the range? Remember, the proposal was to define bit size by the range type the4bitcard = 0 to $0f; but you didn't like to calculate the range yourself. Martin -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On 11/15/2013 02:08 PM, Martin Schreiber wrote: How do you define char8/char16/char32 float32/float64 then if you don't want to be forced to write the range? Neither a bit limitation nor a range makes sense for floats. Bits: you would need to specify a bit count as well for the Mantissa and for the exponent. Range: I see no practical use for this (other when assigning constants or when runtime range check is done). In the range is independent of the bit count. -Michael -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Compile time range checks already have a benefit. == Sure. Anyaway specifing (or assuming) bitlength is range check as well :) Also if range is 2pwrN then overflow check may rely on CPU hardware (checking its Overflow flag with a single JNO ASM ibstruction). -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Martin, Du schriebst am Fri, 15 Nov 2013 07:18:59 +0100: could you do this if the values depend on some unspecified type? Use something like max (boolty) or min (l)? No, max (or another keyword) denotes maximum of the value with the given bit count. Fine. _What_ bit count should it use if you use it within an expression where operands of different - but compatible - sizes (bit counts) are used? The smallest operand's range or the largest one's? Or the result variable's range, if that differs from both? Or do you simply plan to fobid such use, allowing min and max keywords only for type definitions? signed integers (using 2's complement representation as usual nowadays) don't have a symmetric range: a 16-bit integer ranges fron -32768 to ... You reacted exactly as I thought. :-) I.e. you didn't think of the asymmetry of the range? (BTW, with strict binary 2's complement represented numbers with the usual sign convention the equation min = bitwise_not (max) [C-style: min == ~max] holds. I recommend against using this in the discussed context.) -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Michael, Du schriebst am Fri, 15 Nov 2013 09:33:32 +0100: It might not be very neccessary if these types aren't compatible among ^^^ I understand that Martin is (IMHO) correctly assuming that range restricted numerical types (only) make sense if you do realtime range checking on them. If you do calculations on them and possibly define some compatibility relations as well, this will be neccessary (assuming you meant to say _runtime_ range checking above). You won't usually even realize that it's been done. It would be ... be invalidated by not having the possibility to use bitsize restricted (but not explicitly range restricted) variables without realtime range checking. There's no problem with me - I just wouldn't like being deprived of the possibility do include such checking. There aren't so many programs that need utmost speed without concern to other things - any software that's mostly interacting with a user won't be noticeably slowed down by range checking, e.g. Even database software won't be affected much, as most of its processing is command interpretation, data selection and mass storage accesses. There's not much that's adversely affected at all, at least not on your average PC, which will be the carrier for MSElang software, in general. It _might_ be different with embedded systems, but even there it's rather an exception than the rule. simulated bit fields this is not at all what I would want. Typical C attitude - no checking, please, I want to shoot me in the foot silently! ;- Yep. It should be possible to decide if I want the fastest or the most secure code. Just state clearly that it's from you, and I will avoid to use it. Isn't software already bad enough as it is? You wouldn't be satisfied by a compiler directive, like Delphi, FPC ... First I ask for a syntax that frees me from manually calculating the range that is imposed by a bit count: That's a different topic from range checking. So I assume, you _would_ be satisfied by a compiler directive. Now on this one: with 1 Bits -1..0 means the same as signed and 0...1 means the same as unsigned. I.e. there's no difference, you say? No, there's just no space for a sign bit, and thus there's _no_ signed type of that size at all. with 2 Bits -2..1 means the same as signed and 0...3 means the same as unsigned. Even -1..1 would have to be taken as signed, and 1..3 as unsigned. ... with n Bits -(2^(n-1))..(2^(n-1)-1) means the same as signed and 0...(2^n-1) means the same as unsigned. Well, yes, thes are the usual ranges for fully populated sets of number of a given bit count. on top of that this syntax _might_ decide whether or not range checking The _syntax_ _never_ can decide anything. Either the implementor decides what his software does on behalf of the prospective user, or he lets the user decide, giving him a means to turn on the desired behaviour. The syntax just might provide access to such a mechanism, or it could be decided through external data provided to the compiler. is imposed. This of course might be decided by another keyword. but I don't think this is necessary. You think of something like TYPE MyByte: -256..255 unchecked; ? Well... no, unwieldy, as you cannot just turn on range checking for invetigating some problem. Better use a compiler directive, or even better, use a compiler command switch. A compiler option is not a good Idea, as with same you can't define the range checking separately for each type. Why shouldn't it be possible to add a paramter to the option stateing which type you want to check? It _is_ possible, to any degree of detail, althoguh possibly somewhat cumbersome for the compiler writer... range checking separately for each type. Her I feel that it's really logical to define that range checking is imposed exactly when the programmer explicitly defines a range. If you turn _off_ range checking for some type you defined, why'd you _define_ that type in the first place? The definition won't give you any benefit - it does _exactly_ _nothing_. The only effect might be undetected range overflows leading to unexpected program behaviour. Good luck tracing them down. -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Martin, Du schriebst am Fri, 15 Nov 2013 07:33:08 +0100: type boolty = :8;//bool8 cardty = :+8; //card8 intty = :-8;//int8 charty = :#8; //char8 What's the difference between # and +? Why do you think it should be neccessary? What's the difference between booln and cardn? Just to specify any number of wasted bits? floatty = :.64; //flo64 Do you really think this is neccessary? Do you really want to define your special float type different from the established IEEE standard? You won't be able to use _any_ exisiting floting point processor or library then, as none of these allow for arbitrary sized floating point numbers. IEEE defines just two sizes, AFAIK: single precision with 32 bits and double proecision with 64 bits. Even the 80 bit extended type formerly used by intel is not contained in this standard. So you might contemplate doing what everyone else does and simply provide two fixed keywords for these two sizes. They aren't _integer_ constructs after all, they already _are_ some kind of bitpacked records, comprised of three fields, an exponent field, possibly signed or otherwise biased, a sign field for the value as a whole, and the mantissa field, specifying the first few digits of the value. You could declare it somewhat like this (I think, the bit counts might be off a little): TYPE double = bitpacked RECORD exponent: 9; negative: 1; mantissa: 54; END; In addition, the mantissa has a size of _55_ bits, as there's usually an implied 1 as the highest bit. Manipulating this construct is rather involved and requires multiplestages of disassembling the parts of the value, checking for compatibility, shifting and calculating, and reassembling the result. There _was_ a reason why it took quite some time until FPUs were as ubiquitous components of a processor as they are today, where a few thousand gates aren't considered highly complex any more. -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On 11/14/2013 09:16 AM, Michael Schnell wrote: x6: unsigned : 2; This syntax would allow for x7: unsigned : 1024; It would be a nice and consequent to provide arbitrary precision integer arithmetic :-) . -Michael -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Michael, Du schriebst am Thu, 14 Nov 2013 09:16:18 +0100: Do you intend to implement runtime range checking with any of these types ? It might not be very neccessary if these types aren't compatible among each other. Range checking has to be done only on coercion then, i.e. when assigning a value cast from a - any - different type. While as an option, this of course is great, but I think for performance sake it should not always be done. Especially with this You won't usually even realize that it's been done. It would be noticably only under very specific circumstances, such as a loop with many deeply nested calculations using a lot of different variables of such type, running over a large range of the controlling variable, i.e. a long time, or very often. simulated bit fields this is not at all what I would want. Typical C attitude - no checking, please, I want to shoot me in the foot silently! ;- Maybe some syntax for could be provided that not explicitly defines a range and switches off range checking. This seems rather intuitive to me. You wouldn't be satisfied by a compiler directive, like Delphi, FPC and most others do it? Even C has the pragma statement for such puposes, and gcc extends its syntax quite far to achieve similar things. -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Martin, Du schriebst am Thu, 14 Nov 2013 08:12:45 +0100: The range could default to the maximum of the bit size: ... What an awkward syntax. My suggestion: don't. I don't like it. Thank you. Or with reserved words: You would have to devise a way to do the calculations, and you might even get forced to provide a way to request the actual values - how could you do this if the values depend on some unspecified type? Use something like max (boolty) or min (l)? I don't like it, especially the smin smax. We can't write -max to max because Sieghard will read it. ;-) That's _not_ a reason, a reason you cannot use -max to max is that signed integers (using 2's complement representation as usual nowadays) don't have a symmetric range: a 16-bit integer ranges fron -32768 to 32767, or in hex notation -$8000 to $7FFF. It _will_ be necessary to define separate limits for both ends of the range, if you want to be safe. Or you might rely on the fact that the absolute value of the negative limit always is greater by 1 than the positive limit, i.e. -(max+ 1) to max. Not neat, I think. -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Thursday 14 November 2013 21:39:05 Sieghard wrote: Or with reserved words: You would have to devise a way to do the calculations, and you might even get forced to provide a way to request the actual values - how could you do this if the values depend on some unspecified type? Use something like max (boolty) or min (l)? No, max (or another keyword) denotes maximum of the value with the given bit count. max - boolean 0 to max - cardinal smin to smax - integer (or -max to max) ;-) #max - character I don't like it, especially the smin smax. We can't write -max to max because Sieghard will read it. ;-) That's _not_ a reason, a reason you cannot use -max to max is that signed integers (using 2's complement representation as usual nowadays) don't have a symmetric range: a 16-bit integer ranges fron -32768 to 32767, or in hex notation -$8000 to $7FFF. It _will_ be necessary to define separate limits for both ends of the range, if you want to be safe. Or you might rely on the fact that the absolute value of the negative limit always is greater by 1 than the positive limit, i.e. -(max+ 1) to max. Not neat, I think. You reacted exactly as I thought. :-) Martin -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Thursday 14 November 2013 08:12:45 Martin Schreiber wrote: The range could default to the maximum of the bit size: type boolty = : 8; //bool8 cardty = 0 to: 8; //card8 intty = -to: 8;//int8 charty = #0 to: 8; //char8 floatty = -. to .: 64; //flo64 recordty b: : 8; //bool8 c: 0 to: 8; //card8 i: -to: 8; //int8 ch: #0 to: 8; //char8 f: -. to .: 64; //flo64 end; I don't like it. Or with reserved words: type boolty = max: 8; //bool8 cardty = 0 to max: 8;//card8 intty = smin to smax: 8; //int8 charty = #max: 8;//char8 floatty = -.max to .max: 64; //flo64 recordty b: max: 8;//bool8 c: 0 to max: 8; //card8 i: smin to smax: 8; //int8 ch: #max: 8; //char8 f: -.max to .max: 64; //flo64 end; I don't like it, especially the smin smax. We can't write -max to max because Sieghard will read it. ;-) or type boolty = :8;//bool8 cardty = :+8; //card8 intty = :-8;//int8 charty = :#8; //char8 floatty = :.64; //flo64 recordty b: :8; //bool8 c: :+8; //card8 i: :-8; //int8 ch: :#8; //char8 f: :.64; //flo64 end; Martin -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On 11/13/2013 02:27 PM, Martin Schreiber wrote: therefore int64: 2; is invalid, i I don't agree that this is sensible, but it's up to you. how would you define a bitpacked record filed with two bits that is intended to be handled as a signed integer ? ty tr = ??; r : tr; i: int32 r.x2 := -1; i := 0; i := i + r.x2 the result should be i = -1 (Additional issue: when doing i := r.x2 shl 10; what should the result be ? By definition (IMHO) any two-operand operation should be done using the smallest bit size bigger than the bit size of both operands (maybe up rounded to 8^n), The bit size of the variable to store the result in is ignored. here r.x2: bit size 2 rounded to 8 10: bit size 3 rounded to 8 shl done in 8 bit result is 0 (Maybe the definition is at least bigger than the bit size of both operands) and a correct result would be acceptable. But if more bits than the default integer size of the architecture is involved, it is very common, that for speed sake operations are done with smaller bit sizes than expected on the first sight. -Michael -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Wednesday 13 November 2013 15:39:27 Michael Schnell wrote: On 11/13/2013 02:27 PM, Martin Schreiber wrote: therefore int64: 2; is invalid, i I don't agree that this is sensible, but it's up to you. how would you define a bitpacked record filed with two bits that is intended to be handled as a signed integer ? type recordty = bitpacked record x2: -2 to 1; x3: -2 to 1: 2; //same as above x4: 0 to 5: 4; //subrange in 4 bits end; Martin -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On 11/13/2013 05:19 PM, Martin Schreiber wrote: type recordty = bitpacked record x2: -2 to 1; x3: -2 to 1: 2; //same as above x4: 0 to 5: 4; //subrange in 4 bits end; While I don't like to be forced to calculate the range manually from the intended bit count, this of course is possible -Michael -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Wednesday 13 November 2013 17:29:11 Michael Schnell wrote: On 11/13/2013 05:19 PM, Martin Schreiber wrote: type recordty = bitpacked record x2: -2 to 1; x3: -2 to 1: 2; //same as above x4: 0 to 5: 4; //subrange in 4 bits end; While I don't like to be forced to calculate the range manually from the intended bit count, this of course is possible Then you will be banned from developing security relevant software. ;-) Martin -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Martin, Du schriebst am Wed, 13 Nov 2013 06:47:11 +0100: On Tuesday 12 November 2013 20:24:07 Sieghard wrote: [...] As said above, that depends on the implementation or rather the likings of the implementor. If more people than just the implementor are to use it, it just needs to be documented. After all, endiandness issues are notoriously tricky, even fallacious. Do *you* accept the above proposals? _Which_ proposals? You deleted them! Anyway, that's of no consequence - I'll just be a user, design decisions belong to the implementor. And, after all, I'm just a very casual user, as the (two main) projects I used your stuff for probabely won't evolve a lot any more; I even might have to keep a frozen old version of mseidemsegui for maintenance purposes... -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Wednesday 13 November 2013 17:29:11 Michael Schnell wrote: On 11/13/2013 05:19 PM, Martin Schreiber wrote: type recordty = bitpacked record x2: -2 to 1; x3: -2 to 1: 2; //same as above x4: 0 to 5: 4; //subrange in 4 bits end; While I don't like to be forced to calculate the range manually from the intended bit count, this of course is possible The range could default to the maximum of the bit size: type boolty = : 8; //bool8 cardty = 0 to: 8; //card8 intty = -to: 8;//int8 charty = #0 to: 8; //char8 floatty = -. to .: 64; //flo64 recordty b: : 8; //bool8 c: 0 to: 8; //card8 i: -to: 8; //int8 ch: #0 to: 8; //char8 f: -. to .: 64; //flo64 end; I don't like it. Or with reserved words: type boolty = max: 8; //bool8 cardty = 0 to max: 8;//card8 intty = smin to smax: 8; //int8 charty = #max: 8;//char8 floatty = -.max to .max: 64; //flo64 recordty b: max: 8;//bool8 c: 0 to max: 8; //card8 i: smin to smax: 8; //int8 ch: #max: 8; //char8 f: -.max to .max: 64; //flo64 end; I don't like it, especially the smin smax. We can't write -max to max because Sieghard will read it. ;-) Martin -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On 11/11/2013 11:00 AM, Ivanko B wrote: That signedness isn't more than just a old (and not obvious) assumption. Thus -1 is greater than 1 as the representation of -1 is all bits set ? -Michael -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Martin, Du schriebst am Tue, 12 Nov 2013 08:33:29 +0100: The C-like syntax FIELDNAME ':' FIELDTYPE [':' BITSIZE] ';' is accepted? It's much more broadly used than just with C. In fact, C seems to have it adopted only recently. You might use alternate delimiters, though. Is a record with BITSIZE automatically bitpacked? Is It depends on the implementation. If more people than just the implementor are to use it, it just needs to be documented. 'type' TYPENAME '=' RANGEMIN '..' RANGEMAX [':' BITSIZE] ';' This might be seen as an on the fly type definition. accepted too? Defining of little/big-endian could be useful too. As said above, that depends on the implementation or rather the likings of the implementor. If more people than just the implementor are to use it, it just needs to be documented. After all, endiandness issues are notoriously tricky, even fallacious. -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Martin, Du schriebst am Tue, 12 Nov 2013 10:19:38 +0100: Is a record with BITSIZE automatically bitpacked? I gather this does make sense. I am not sure. I don't like implicit things much. That's right - but bitsize specifications aren't really useful without packing. But you might decide that omitting the bitpacked keyword makes a record implementation dependendly packed. Or you might make it even more complex, packing the adjacent fields with bitsize specifications by bits and other, possibly intervening fields by some other alignment. I gather it made sense to not make it overly complicated. x1: int64: 2; Invalid because int64 is defined as -8000..7fff which does not fit in 2 bits. What would imply that you had to define a fitting type first. Don't forget the compatibility issues - although I'd opt for general incompatibility, these types are really all numeric types that could be coerced, so there should probabely be a method to force compatibility (casting) that has to be implemented, usually by (sign) extending the smaller type to comply with the larger for calculations, and extension or truncation as required for assignments. Also, what will you do about a signed / unsigned result that overflows the range of a signed / unsigned result type? (I.e. assigning a 16 bit unsigned integer of, say, value 4, to a signed 16 bit variable.) -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Michael, Du schriebst am Tue, 12 Nov 2013 09:30:11 +0100: On 11/11/2013 11:00 AM, Ivanko B wrote: That signedness isn't more than just a old (and not obvious) assumption. Thus -1 is greater than 1 as the representation of -1 is all bits set ? You may define an ordering relation where it is - in fact, there _is_ such an ordering defined already, and it is called unsigned representation. You might perhaps find it useful, maybe even intersting, to read a little about number theory, specifically about cyclic number sets, modulo artihmetic, rest classes and the like. These are very important for digital data processing, not only for encryption, where these concepts are broadly employed, but even for the very mundane task of general calculations. E.g., given a 16 bit representation, add the numbers 32109 and 34567 correctly. Can you do it? Or multiply 1234 * 56. Equally interesting. -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Martin, Du schriebst am Tue, 12 Nov 2013 08:09:42 +0100: MSEide editor is not limited to fixed pitch fonts so column blocks may be Column blocks simply don't make sense with proportional fonts. Source code can in principle be written with proportional fonts, but even that doesn't make much sense - writing code with a structured layout is inconvenient, indentation is cumbersome, you cannot use tabs reasonably, and so on. But, of course, it can be done, much in contrast to column block manipulation. -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Tuesday 12 November 2013 20:24:07 Sieghard wrote: [...] As said above, that depends on the implementation or rather the likings of the implementor. If more people than just the implementor are to use it, it just needs to be documented. After all, endiandness issues are notoriously tricky, even fallacious. Do *you* accept the above proposals? Martin -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On 11/08/2013 05:32 PM, Martin Schreiber wrote: Or ord8, ord16, ord32, ord64, int8, int16, int32, int64? So why invent new names instead of using the really well known names such as uint8_t, int16_t -Michael -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On 11/09/2013 08:27 PM, Sieghard wrote: C-ish type IMHO C-ish stuff only should be avoided if there is not already a really decent alternative in well known Pascal dialects. In fact C-ish naming _should_ be used if the most well known (GNU) C dialect or the most well known C-Libraries (glibc and friends) provide something useful an clear . (Such as the the names for integer types with fixed or minimum bit length). -Michael -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On 11/08/2013 07:46 PM, Martin Schreiber wrote: One probably would write Register = bitpacked RECORD Field_1: $..$007f; Field_2: $..$0003; Field_3: $..$001f; Field_4: $..$0001; Field_5: $..$0001; END; Why not something like bitpacked RECORD Filed_1: integer: 7; Filed_2: integer: 2; Filed_3: integer: 5; Filed_4: integer: 1; Filed_5: integer: 1; end Pro 1: It defines the way operations on the fields are to be executed (here signed integer, or whatever basic type mselang will define for this, but of course could be unsigned integer or whatever). IMHO this is strictly necessary to allow for predictable calculations with such fields. Pro 2: This is not limited on a single hardware Word, but can define to arbitrary length memory areas. Con 1: you need to add dummy fields if you intent to ignore some part of the bits (no real problem IMHO) Con 2: the bit position is implementation dependent (should be done like GNU C does this). A decent documentation might help. I doubt that MSElang ever will exist for high-byte first languages, so the distinction GNU C does on this behalf is not relevant.) -Michael -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
So why invent new names instead of using the really well known names such as uint8_t, int16_t == Sounds reasonable. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Why not something like bitpacked RECORD Filed_1: integer: 7; Filed_2: integer: 2; Filed_3: integer: 5; Filed_4: integer: 1; Filed_5: integer: 1; end === For non-2^N ranging. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
This is not limited on a single hardware Word, but can define to arbitrary length memory areas. == Really, it's important for bitpacked data. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Definitions like - var1: 0..22; or var1: integer from 0 to 22; might by useful multiarch programming since compiler may select needed internal (arch-specific) type - emulated 64bit even for 8-bit arch for instance so that programs work in same manner on any supported architecture. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Monday 11 November 2013 10:02:39 Michael Schnell wrote: On 11/08/2013 05:32 PM, Martin Schreiber wrote: Or ord8, ord16, ord32, ord64, int8, int16, int32, int64? So why invent new names instead of using the really well known names such as uint8_t, int16_t Because if there is a u for unsigned there must be a s for signed (orthogonality). But int is already signed (as Sieghard pointed out) so sint is bad. Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
But int is already signed (as Sieghard pointed out) so sint is bad. == That signedness isn't more than just a old (and not obvious) assumption. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On 11/11/2013 10:53 AM, Martin Schreiber wrote: Because if there is a u for unsigned there must be a s for signed (orthogonality). But int is already signed (as Sieghard pointed out) so sint is bad. While I do see you point, IMHO this is trading strictness vs readability, and thus a matter of taste, and this given I still vote for the traditional (C) but unambiguous naming. -Michael -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On 11/11/2013 10:34 AM, Ivanko B wrote: Why not something like bitpacked RECORD Filed_1: integer: 7; Filed_2: integer: 2; Filed_3: integer: 5; Filed_4: integer: 1; Filed_5: integer: 1; end === For non-2^N ranging. I don't understand This suggestion is for 2^N ranges (denoting the same that the OP's notation suggests.) Non 2^N subranges are not very useful, IMHO (other than for defining Arrays, what Martin supposedly would not like to support, anyway). -Michael -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Monday 11 November 2013 11:42:58 Michael Schnell wrote: On 11/11/2013 10:53 AM, Martin Schreiber wrote: Because if there is a u for unsigned there must be a s for signed (orthogonality). But int is already signed (as Sieghard pointed out) so sint is bad. While I do see you point, IMHO this is trading strictness vs readability, and thus a matter of taste, and this given I still vote for the traditional (C) but unambiguous naming. card32, int32 is based on Pascal types and unambiguous too. cardinal, integer - recommended type, card, int - size of the CPU registers. Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On 11/11/2013 12:15 PM, Martin Schreiber wrote: card32, int32 is based on Pascal types and unambiguous too. cardinal, integer - recommended type, card, int - size of the CPU registers. Yep. As said: mater of taste. So it's up to you. -Michael -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Ivanko, Du schriebst am Mon, 11 Nov 2013 15:00:12 +0500: But int is already signed (as Sieghard pointed out) so sint is bad. == That signedness isn't more than just a old (and not obvious) assumption. It's a mathematical convention. The set of integer numbers usually comprises all whole numbers from -infinity to +infinity except the bounds (as these are no numbers). Whole _positive only_ numbers make up the set of natural numbers, starting at one (1) and leaving off zero, denoted by IN sometimes. The union of IN and [0] is sometimes used and called IN0 or so. (The IN should denote a capital letter N with a thicker upstroke.) Of course, these are _conventions_ only, everyone is free to use the names differently or use different names for the same things. -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Monday 11 November 2013 21:38:18 Sieghard wrote: BTW, I like to use copy paste for such repetitive stuff as declarations or such. When I have to create a table, I might even change editors when there's one around that can do column block manipulations, build the table, and possibly switch back to the previous one to continue, if neccessary (like when I hav to use an IDE e.g.). (BTW: pun intended;) MSEide editor is not limited to fixed pitch fonts so column blocks may be cumbersome. Write your own editor? The source is here: https://gitorious.org/mseide-msegui/mseide-msegui/source/556709ca70c5b0a5090973e9d9c1201cf767780f:apps/ide/sourcepage.pas Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Monday 11 November 2013 22:25:07 Sieghard wrote:
My previous egregious example
Register = RECORD
Field_1: 0..77;
Field_2: 1..3;
Field_3: 5..25;
Field_4: 111..112;
Field_5: -2..-1;
END;
might thus be specified like this:
TYPE
Basevalue = 0..77;
Selector = 1..3;
FiveStep = 5, 10, 15, 20, 25; { or just 5..25; }
{ maybe allow for incompletely populated subranges as well? }
HighEnd = 111..112;
LowEnd = -2..-1;
Register = RECORD
Field_1: Basevalue: 7;
Field_2: Selector: 2;
Field_3: FiveStep: 5;
Field_4: HighEnd: 1;
Field_5: LowEnd:1;
END;
The C-like syntax
FIELDNAME ':' FIELDTYPE [':' BITSIZE] ';'
is accepted?
Is a record with BITSIZE automatically bitpacked? Is
'type'
TYPENAME '=' RANGEMIN '..' RANGEMAX [':' BITSIZE] ';'
accepted too? Defining of little/big-endian could be useful too.
Martin
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Martin, Du schriebst am Sat, 9 Nov 2013 20:31:58 +0100: Your suggestion how to define the bit size of a type? Well, specify the requested number of bits together with the bitfield's identifier. There's a host of notations in use, e.g. the C-ish name: bits, or a functional expression name (bits) or something like Delphi's string or array length spectification: name [bits]. Or even a notation that includes the exact location of the field as used by hardware register field definitions sometimes: name highbit:lowbit. On the other hand, your invention of the new keyword bitpacked looks quite good to me, as it makes clear that this record definition ... No invention, FPC has it already. Well, yes, the keyword, but it's rather useless: Note that the internals of the bitpacking are opaque: they can change at any time in the future. What is more: the internal packing depends on the endianness of the platform for which the compilation is done, and no conversion between platforms are possible... My suggestion: if you're going to implement such a thing, use it. (The bitpacked keyword, i.e.) I don't understand. Huh? What's so hard to understand if I say, if you're going to provide bitpacked records, use the keyword to declare them? Should I say it in german? -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Martin, Du schriebst am Sun, 10 Nov 2013 08:00:07 +0100: After all, a programmer should not type most of the time, but _think_ ^ about the structures his typing is to describe. Shouldn't he? BTW, how does your editor program know if you write Err, _should_ it? Shouldn't the guy in front of the screen know better? Or cannot even a programmer be held knowledgeable enough to decide which number to type after the editor already wrote the type base name for him? BTW, _I_ usually disable such a mechanism, as by now, I'm able to type fast enough not to be slowed down thereby. Thinking _what_ to type takes most of the time, and I think it should. -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Sunday 10 November 2013 14:14:26 Sieghard wrote: Hallo Martin, Du schriebst am Sun, 10 Nov 2013 08:00:07 +0100: After all, a programmer should not type most of the time, but _think_ ^ about the structures his typing is to describe. Shouldn't he? BTW, how does your editor program know if you write Err, _should_ it? Shouldn't the guy in front of the screen know better? Or cannot even a programmer be held knowledgeable enough to decide which number to type after the editor already wrote the type base name for him? BTW, _I_ usually disable such a mechanism, as by now, I'm able to type fast enough not to be slowed down thereby. Thinking _what_ to type takes most of the time, and I think it should. Then we should maybe think again about your argument: Adding confusion to obscurity? Why insist on foreshortening everything when nearly every editor around offers programmability of some sort, and completion can be had for free most everywhere (even if it is often more disturbing than helpful, IMHO). Or, as another approach: Type once, paste often - if the words are lengthy, just copy one line and paste it as often as needed. Sometimes, the ability to manipulate column blocks is helpful also, it eases modification of line sections in multiple lines. And more. Which means, there's not much to gain with foreshortened identifiers, when the editors make typing easy anyway. Can you describe how typing easy with your editor program works so it is as easy to enter cardinal32 as typing card32? Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Martin, Du schriebst am Sun, 10 Nov 2013 15:47:30 +0100: Can you describe how typing easy with your editor program works so it is as easy to enter cardinal32 as typing card32? Yes. It doesn't, as I don't _want_ to have such a feature. I _do_ want to type myself, without interference from some well-meaning(ly designed) automatism. (But I know this stuff, from LibreOffice, e.g., where I was to lazy yet to disable it. In LibreOffice, this is a self-learning automat that tries to recognize already used words and phrases and to complete the partial entry while you type. Usually, the suggested completions don't fit... BTW, the Delphi IDE, at least some versions of it, offers a similar feature, though I think to recall that it only offers predefined fixed completions - just what would be of use here. After the completion is displayed, you have to accept it before you type on, then you can add to the word or use it as is. I don't like this because it requires one to be _aware_ of the feature and always be on the watch for a completion to accept [or reject] it, which I find is more distracting than useful. But others might think different, otherwise this feature wouldn't be offered, I suppose.) -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Monday 11 November 2013 00:07:54 Sieghard wrote: Hallo Martin, Du schriebst am Sun, 10 Nov 2013 15:47:30 +0100: Can you describe how typing easy with your editor program works so it is as easy to enter cardinal32 as typing card32? Yes. It doesn't, as I don't _want_ to have such a feature. I _do_ want to type myself, without interference from some well-meaning(ly designed) automatism. (But I know this stuff, from LibreOffice, e.g., where I was to lazy yet to disable it. In LibreOffice, this is a self-learning automat that tries to recognize already used words and phrases and to complete the partial entry while you type. Usually, the suggested completions don't fit... BTW, the Delphi IDE, at least some versions of it, offers a similar feature, though I think to recall that it only offers predefined fixed completions - just what would be of use here. After the completion is displayed, you have to accept it before you type on, then you can add to the word or use it as is. I don't like this because it requires one to be _aware_ of the feature and always be on the watch for a completion to accept [or reject] it, which I find is more distracting than useful. But others might think different, otherwise this feature wouldn't be offered, I suppose.) I think the same. The first I do in any IDE is to switch off all autocompletion and other automatic stuff. So card32 instead of cardinal32 has a reason. Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
So card32 instead of cardinal32 = Sure, all shortened types should have similar length shortened parts : integer = int cardinal = card word = (no need to shorten) -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Martin, Du schriebst am Fri, 8 Nov 2013 19:46:05 +0100: Register = bitpacked RECORD Field_1: $..$007f; Field_2: $..$0003; Field_3: $..$001f; Field_4: $..$0001; Field_5: $..$0001; END; which already looks a little bit better. :-) Disregarding that it's identical to my example, I don't think it looks any _better_, it in fact adds a lot of fuzz (the $ signs and the many zeros) that effectively hide the real information from immediate recognition. I still maintain that for such a use, a direct bit size specfication would be clearer. On the other hand, your invention of the new keyword bitpacked looks quite good to me, as it makes clear that this record definition describes a densely packed data structure that's unequivocally defined - no padding of any size, and no wasted space from access optimisation for some processor. My suggestion: if you're going to implement such a thing, use it. (The bitpacked keyword, i.e.) -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Saturday 09 November 2013 19:56:55 Sieghard wrote: Disregarding that it's identical to my example, I don't think it looks any _better_, it in fact adds a lot of fuzz (the $ signs and the many zeros) that effectively hide the real information from immediate recognition. I still maintain that for such a use, a direct bit size specfication would be clearer. Your suggestion how to define the bit size of a type? On the other hand, your invention of the new keyword bitpacked looks quite good to me, as it makes clear that this record definition describes a densely packed data structure that's unequivocally defined - no padding of any size, and no wasted space from access optimisation for some processor. No invention, FPC has it already. My suggestion: if you're going to implement such a thing, use it. (The bitpacked keyword, i.e.) I don't understand. Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Martin, Du schriebst am Fri, 8 Nov 2013 19:23:43 +0100: Currently I prefer cardinal - cardXX and integer - intXX because of the Pascal types. It would be even better if the two had same count of characters. carXX? :- Adding confusion to obscurity? Why insist on foreshortening everything when nearly every editor around offers programmability of some sort, and completion can be had for free most everywhere (even if it is often more disturbing than helpful, IMHO). Or, as another approach: Type once, paste often - if the words are lengthy, just copy one line and paste it as often as needed. Sometimes, the ability to manipulate column blocks is helpful also, it eases modification of line sections in multiple lines. And more. Which means, there's not much to gain with foreshortened identifiers, when the editors make typing easy anyway. After all, a programmer should not type most of the time, but _think_ about the structures his typing is to describe. Shouldn't he? -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Martin, Du schriebst am Fri, 8 Nov 2013 06:46:55 +0100: You might opt to spell it out as integer, I think. That is not better IMHO. uint, sint - uinteger, sinteger. What about unum, snum? I rather thought about using integer as a name for the signed int C-ish type _only_. The unsigned whole number type should be named differently, although I must admit not to have a very good name myself. One might think of cardinal, for example, but that has some conotation mathematically (cardinality of sets, e.g.). Anyway, that makes it a number type with a lower bound, as is required for positive-only whole numbers. (Didn't you set out to recreate a _Pascal_ compiler? Then that's how it .. We create a future compiler for the MSEide+MSEgui project. In a first Ok, I got that now. Although I'm not convinced that yet another [tool kit] specific language (a YA[TK]SL?) is really required. I'd opt for a full implementation of Algol 68 instead, as this had nearly everything ever conceived for any programming language, and more... ;- Except objects and classes. -- -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) --- Mit freundlichen Grüßen, S. Schicktanz --- -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Saturday 09 November 2013 20:37:11 Sieghard wrote: Which means, there's not much to gain with foreshortened identifiers, when the editors make typing easy anyway. After all, a programmer should not type most of the time, but _think_ about the structures his typing is to describe. Shouldn't he? OK, cardinal8, cardinal16, cardinal32, cardinal64, integer8, integer16, integer32, integer64 then. BTW, how does your editor program know if you write var i: in... which integer type is meant? Do you click in a popup window? Or do you use the Up/Down keys + Enter? Another method? Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Friday 08 November 2013 08:56:23 Ivanko B wrote: two syntaxes for same thing Which should be avoided. --- Why ? Just shortcuts (short/simplified notations) for user convinience :) From the Wiki: The design goals 1. Simple. Reduce the language concepts one has to learn to the minimum, make them as orthogonal as possible. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Reduce the language concepts one has to learn to the minimum == Typedefs aren't language complications - they just use the language. Shortcuts are very handy for instance @ instaed of addr()/ -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Ranging for integers may also help to build not yet hardware suported types, like : - var i1: integer from 0 to 2^^256; // 2prw256 i2: integer:256; --- Sure, with emulated access to them. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On 11/08/2013 11:30 AM, Ivanko B wrote: Ranging for integers may also help to build not yet hardware suported types, Somewhat similar, but IMHO by far not as useful as Records defining bit-field variables. -Michael -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Friday 08 November 2013 06:46:55 Martin Schreiber wrote: On Friday 08 November 2013 00:08:09 Sieghard wrote: Hallo Martin, Du schriebst am Thu, 7 Nov 2013 06:27:46 +0100: BTW, int(eger) already does imply signedness, usually (mathematically). Yup. What could be used instead of int? You might opt to spell it out as integer, I think. That is not better IMHO. uint, sint - uinteger, sinteger. What about unum, snum? Or ord8, ord16, ord32, ord64, int8, int16, int32, int64? Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Friday 08 November 2013 17:32:56 Martin Schreiber wrote: You might opt to spell it out as integer, I think. That is not better IMHO. uint, sint - uinteger, sinteger. What about unum, snum? Or ord8, ord16, ord32, ord64, int8, int16, int32, int64? Or card8, card16, card32, card64, int8, int16, int32, int64? :-) Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Or ord8, ord16, ord32, ord64, int8, int16, int32, int64? MS Or card8, card16, card32, card64, int8, int16, int32, int64? MS :-) Why ordXX, not wordXX? Look at Context language by Andrey Hohlov. -- WBR, Vladislav Javadov -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Friday 08 November 2013 19:14:31 Vladislav Javadov wrote: Or ord8, ord16, ord32, ord64, int8, int16, int32, int64? MS Or card8, card16, card32, card64, int8, int16, int32, int64? MS :-) Why ordXX, not wordXX? Look at Context language by Andrey Hohlov. We need a base name for unsigned numbers and a base name for signed numbers. Why do you suggest word for unsigned number? Currently I prefer cardinal - cardXX and integer - intXX because of the Pascal types. It would be even better if the two had same count of characters. carXX? :- Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Friday 08 November 2013 00:39:58 Sieghard wrote: Suppose there's some part having a 16 bit register that's subdivided into 5 fields, bits 0 through 6, 7...8, 9...13, 14 and 15 (the latter are 1-bit fields, of course). Your construct might then look like: Register = RECORD Field_1: 0..127; Field_2: 0..3; Field_3: 0..31; Field_4: 0..1; Field_5: 0..1; END; One probably would write Register = bitpacked RECORD Field_1: $..$007f; Field_2: $..$0003; Field_3: $..$001f; Field_4: $..$0001; Field_5: $..$0001; END; which already looks a little bit better. :-) Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Why do you suggest word for unsigned number? == word - longword(=dword = cardinal) - qword.. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Friday 08 November 2013 20:19:54 Ivanko B wrote: Why do you suggest word for unsigned number? == word - longword(=dword = cardinal) - qword.. Yes, but word in Pascal is fixed 16bit. I more like card - cardinal. Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Cardinal is 32 bits only as long as word expresses unsiged types of 2,4,8 so on bytes length. That's currently in Pascal : *int=signed and *word=unsigned (with aliaces shortint=int8,integer=int16, byte=1/2word, cardinal=dword). -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Friday 08 November 2013 22:48:28 Ivanko B wrote: Cardinal is 32 bits only as long as word expresses unsiged types of 2,4,8 so on bytes length. Not in TP mode. From Delphi 7 manual: The generic integer types are Integer and Cardinal. Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
integer = sint32; What for ? How about longest harware supported type (found by compiler automatically for target architcture ) ? -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Thursday 07 November 2013 09:53:48 Ivanko B wrote:
integer = sint32;
What for ? How about longest harware supported type (found by compiler
automatically for target architcture ) ?
{$if REGISTERSIZE = 64}
integer = sint64;
{$else}
integer = sint32;
{endif}
Why do you want that integer has different sizes on different platforms?
Martin
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Why do you want that integer has different sizes on different platforms?
==
The BASE (no user attention about range) integer. Not ranged one.
{$if REGISTERSIZE = 64}
==
User attention about range. Knowing underlying arch. Can be (and will
be) done by compliler while generating code.
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Thursday 07 November 2013 10:24:38 Ivanko B wrote: Why do you want that integer has different sizes on different platforms? == The BASE (no user attention about range) integer. Not ranged one. The user *must* have an attention about range. So this type can not be the base. If the user attention is register size of the current arch he should use ptrint or its MSElang equivalent. Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Thursday 07 November 2013 14:01:07 Ivanko B wrote: The user *must* have an attention about range. So this type can not be the base. Why ? Both my large projects PODPISKA ROZNITSA don't care about value ranges - they just rely on the default INTEGER type LONGINT (or CARDINAL for unsigned data) fits any data of these projects. Compile in default TP mode and you will be surprised. ;-) I can not accept your argument, sorry. Why INTEGER FLOAT are same as to their nature ? I don't understand. They're assigmnent operation compatible even without type casting. They can be mixed in arithmetic expressions... integer - float only. Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Both my large projects PODPISKA ROZNITSA don't care about value ranges - they just rely on the default INTEGER type LONGINT (or CARDINAL for unsigned data) fits any data of these projects. Compile in default TP mode and you will be surprised. ;-) What for ? It's hardly usable. I can not accept your argument, sorry. === Worring about integer ranges is rare issue :) Signedness is much more frequent, though. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Hallo Martin,
Du schriebst am Thu, 7 Nov 2013 07:10:56 +0100:
BTW, float sounds awfully C-ish to me. No reals any more, really?
Because there could be a complex datatype which has two float fields.
Oh, I see, you think of the real/imaginary components. Indeed, that mighht
be distracting to the user, although the real _type_ and the _fieldname_
real are very different things to the compiler.
You might consider to have a look at FORTRAN's type system, which
provides a convenient notation for specifying the size of a variable or
type. And its advantage is that it's _not_ restricted in advance.
I do more like the min..max notation.
This doesn't really define storage requirements directly, which I supposed
was your goal. And it makes for a very clumsy notation for bitfields, that
you mentioned you'd like to support also. E.g.:
Suppose there's some part having a 16 bit register that's subdivided into 5
fields, bits 0 through 6, 7...8, 9...13, 14 and 15 (the latter are 1-bit
fields, of course).
Your construct might then look like:
Register = RECORD
Field_1: 0..127;
Field_2: 0..3;
Field_3: 0..31;
Field_4: 0..1;
Field_5: 0..1;
END;
An equivalent C struct would look like this:
struct Register = {
int Field_1: 7,
int Field_2: 2,
int Field_3: 5,
int Field_4: 1,
int Field_5: 1,
};
A common notation used by hardware technicians, looks somewhat similar to
C's notation:
Register = (
Field_1: (0:6);
Field_2: (7:8);
Field_3: (9:13);
Field_4: (14:14);
Field_5: (15:15);
);
or something similar.
The subrange method even might allow ranges of non-binary size, i.e.
such that don't use the full range of values a given number of bits can
represent, making it even more difficult to recognize the required number
of bits for a field.
You might specify a data structure taking the same area as above like this:
Register = RECORD
Field_1: 0..77;
Field_2: 1..3;
Field_3: 5..25;
Field_4: 111..112;
Field_5: -2..-1;
END;
(where I assumed that you would allow for negative range limits also.)
BTW, as these are real subranges, what about limit checking?
Although this approach certainly is the most flexible, it might be
considered as a rather obscure notation, requiring quite an amount of
decoding to assess the real size of the data.
This much for your consideration, the final decision is yours, of course.
--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
---
Mit freundlichen Grüßen, S. Schicktanz
---
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Friday 08 November 2013 00:08:09 Sieghard wrote: Hallo Martin, Du schriebst am Thu, 7 Nov 2013 06:27:46 +0100: BTW, int(eger) already does imply signedness, usually (mathematically). Yup. What could be used instead of int? You might opt to spell it out as integer, I think. That is not better IMHO. uint, sint - uinteger, sinteger. What about unum, snum? (Didn't you set out to recreate a _Pascal_ compiler? Then that's how it is spelled by these.) We create a future compiler for the MSEide+MSEgui project. In a first step the language will be what is currently used in MSEide+MSEgui, a subset of Delphi7/FPC 2.6.2. Later changes of the syntax are possible. I started the questions in order to implement the first step with the second in mind and to have enough time for discussion. Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Friday 08 November 2013 08:01:05 Ivanko B wrote: by subrange should be changed to define signed/unsigned and bit count. or extended to define :) Anyway specifying bitcount even defining as typesize are ranging as well but rougher (inexact). That means two concepts to define integer types instead of one. Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
two concepts === If handled in same manner by compiler - two syntaxes for same thing ? -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
two syntaxes for same thing Which should be avoided. --- Why ? Just shortcuts (short/simplified notations) for user convinience :) -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
For new language, why not to leave only one size per type - of max register length of target arch (may be controled by compiler options) ? X86_32 X86_64: bool(=bool32), uint(=uint64), sint(=sint64), float(=float64) ... ARM-32 boxes: bool(=bool32), uint(=uint32), sint(=sint32), float(=float32) ... -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Wednesday 06 November 2013 11:42:22 Ivanko B wrote: For new language, why not to leave only one size per type - of max register length of target arch (may be controled by compiler options) ? Why? -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Wednesday 06 November 2013 12:04:21 Ivanko B wrote: To be readable as letter :) So that user don't have to think worry about value limitations ( AV in runtine) unless they (range checks) are defined explicitly by some keyword/clause (a new compiler feature BTW). If you like you can define type integer = sint64; in order to be save. Maybe there should be sint128 in order to be super save. ;-) Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
type integer = sint64; === Not portable between architectures. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Wednesday 06 November 2013 12:19:46 Ivanko B wrote:
type
integer = sint64;
===
Not portable between architectures.
Isn't the idea So that user don't have to think worry
about value limitations?
Otherwise write
type
{$if CPUSIZE=64}
integer = sint64;
{$else}
integer = sint32;
{$endif}
Martin
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
{$if CPUSIZE=64}
integer = sint64;
{$else}
integer = sint32;
{$endif}
==
It's the deal of compiler swicthes which should be done automatically
by build environment.
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
var i1: integer from 1 to 10; // assigned to UINT8 by compiler i2: cardinal; // assigned to UINT(max_len) by compiler i3: integer; // assigned to SINT(max_len) by compiler begin i1:= 0; // compile time error i1:= 12; // compile time error i1:= 3; // OK -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Wednesday 06 November 2013 12:41:25 Ivanko B wrote:
{$if CPUSIZE=64}
integer = sint64;
{$else}
integer = sint32;
{$endif}
==
It's the deal of compiler swicthes which should be done automatically
by build environment.
You miss the point. In FPC one has to make typedefs in order to have known
size types. I think it should be the opposite, make typedefs if you want
platform dependent sizes. In daily work the size of the base types should be
unambiguously visible. I often need to check if smallint is smaller than
shortint. ;-)
Martin
--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
Run-time range checking (it can slow down target program) might be switched on/of by a compiler option or $ifdef. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
In daily work the size of the base types should be unambiguously visible. == How about its replacement by explicit range defining/checking (possibly with the mention reversal typedef for simplier syntax) ? The same + some more (compiler) functionality.. And reading letter by default (without defining ranges). -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
On Wednesday 06 November 2013 13:22:31 Ivanko B wrote: In daily work the size of the base types should be unambiguously visible. == How about its replacement by explicit range defining/checking (possibly with the mention reversal typedef for simplier syntax) ? The same + some more (compiler) functionality.. And reading letter by default (without defining ranges). What is wrong to read in a letter the word sint32 instead of integer? Martin -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Re: [MSEide-MSEgui-talk] MSElang, fixsize numeric base types
What is wrong to read in a letter the word sint32 instead of integer? === Means CPU architecture knowledge etc special skills. Specifying a range instead is more meaningful. And the range supplies all needed info to the compiler so that it makes proper choice of actually needed data type. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
