Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #140908 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2019-02-13 03:16 -0800 |
| Last post | 2019-02-15 18:19 -0600 |
| Articles | 18 on this page of 78 — 13 participants |
Back to article view | Back to comp.lang.c
list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-13 03:16 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-13 04:56 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-13 05:16 -0800
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-13 15:43 +0100
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-13 09:55 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-13 11:05 -0800
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-13 20:29 +0100
Re: list of chars to introduce in future c "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-13 20:33 +0100
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-13 12:08 -0800
Re: list of chars to introduce in future c John Bode <jfbode1029@gmail.com> - 2019-02-13 12:02 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-13 12:16 -0800
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 09:34 +0100
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-14 02:04 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-14 02:08 -0800
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 11:28 +0100
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-14 02:38 -0800
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 14:54 +0100
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-14 06:39 -0800
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 16:26 +0100
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-14 02:49 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-14 02:59 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-14 03:10 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-14 03:34 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 05:25 -0800
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-15 13:54 +0000
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 06:07 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 06:10 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 06:14 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 06:18 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 06:22 -0800
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-15 14:24 +0000
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 06:32 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 06:39 -0800
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-15 14:47 +0000
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 07:32 -0800
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-15 15:56 +0000
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 08:18 -0800
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-15 17:10 +0100
Re: list of chars to introduce in future c Keith Thompson <kst-u@mib.org> - 2019-02-14 12:20 -0800
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 21:32 +0100
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-14 13:52 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-14 02:31 -0800
Re: list of chars to introduce in future c BGB <cr88192@hotmail.com> - 2019-02-13 12:48 -0600
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 09:45 +0100
Re: list of chars to introduce in future c BGB <cr88192@hotmail.com> - 2019-02-14 04:06 -0600
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 11:39 +0100
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-14 14:34 +0000
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 16:31 +0100
Re: list of chars to introduce in future c Robert Wessel <robertwessel2@yahoo.com> - 2019-02-14 14:39 -0600
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-14 23:48 +0000
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-15 09:20 +0100
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-15 11:09 +0000
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-15 17:25 +0100
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-15 16:46 +0000
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-15 18:05 +0100
Re: list of chars to introduce in future c BGB <cr88192@hotmail.com> - 2019-02-17 14:45 -0600
Re: list of chars to introduce in future c James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-02-15 10:51 -0800
Re: list of chars to introduce in future c BGB <cr88192@hotmail.com> - 2019-02-14 13:59 -0600
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 21:36 +0100
Re: list of chars to introduce in future c BGB <cr88192@hotmail.com> - 2019-02-15 00:47 -0600
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-15 09:26 +0100
Re: list of chars to introduce in future c BGB <cr88192@hotmail.com> - 2019-02-15 14:15 -0600
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-16 01:36 +0000
Re: list of chars to introduce in future c BGB <cr88192@hotmail.com> - 2019-02-16 01:25 -0600
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-16 12:17 +0000
Re: list of chars to introduce in future c BGB <cr88192@hotmail.com> - 2019-02-16 15:08 -0600
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-16 23:10 +0000
Re: list of chars to introduce in future c BGB <cr88192@hotmail.com> - 2019-02-17 00:56 -0600
Re: list of chars to introduce in future c Bart <bc@freeuk.com> - 2019-02-17 17:30 +0000
Re: list of chars to introduce in future c BGB <cr88192@hotmail.com> - 2019-02-17 16:02 -0600
Re: list of chars to introduce in future c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-14 13:49 +0000
Re: list of chars to introduce in future c Philipp Klaus Krause <pkk@spth.de> - 2019-02-14 09:08 +0100
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 09:56 +0100
Re: list of chars to introduce in future c Philipp Klaus Krause <pkk@spth.de> - 2019-02-14 11:06 +0100
Re: list of chars to introduce in future c David Brown <david.brown@hesbynett.no> - 2019-02-14 15:01 +0100
Re: list of chars to introduce in future c mark.bluemel@gmail.com - 2019-02-15 05:30 -0800
Re: list of chars to introduce in future c fir <profesor.fir@gmail.com> - 2019-02-15 05:42 -0800
Re: list of chars to introduce in future c Lynn McGuire <lynnmcguire5@gmail.com> - 2019-02-15 18:19 -0600
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-15 09:26 +0100 |
| Message-ID | <q45t3b$6h7$1@dont-email.me> |
| In reply to | #141062 |
On 15/02/2019 07:47, BGB wrote: > On 2/14/2019 2:36 PM, David Brown wrote: >> >> Ah, yes - you have your own ISA and your own C compiler for it. (Why >> don't you port gcc or llvm?) >> > > GCC's codebase looks a bit intimidating; to port GCC it looks like it > would be necessary to edit code all over the place. If I were to go over > to GCC, would probably then be easier to jump ship over to RISC-V or > something (given their "on paper" stats look kinda similar). > There is no doubt gcc is a big project, and no doubt that porting it to a new architecture is hard. Equally, however, there is no doubt that making a C compiler yourself is hard - and when you put the effort in to make the gcc port, you have a /huge/ amount extra for free. And there is lots of information and examples about porting it, as well as people to help - it supports many dozen official ports and lots of unofficial ports. LLVM should be less difficult to port than gcc (though I don't pretend it is simple). > > Previously, I had been using GCC with an SH4 target, and while > conceptually simple, SH4 has its own drawbacks: > There are some "sharp corners" in the way parts of the ISA are designed; > Given each instruction does relatively little work in itself (if > compared with something like RISC-V or ARM), it requires considerably > more instructions to be executed to perform a similar amount of work. > > This is partly why I ended up mostly abandoning SH4. > > > But, now I am left in a situation with: > > My own ISA, for which its main "practical" use-case is in an emulator on > a RasPi2, being used as part of the control software for a CNC lathe > (which is used in a way that, in a straightforward description, would > likely sound a bit absurd). > It does sound a little convoluted, yes :-) > > There was work towards a Verilog/FPGA implementation, but I have put > this is "on hold" for now. Was sinking effort into it, and don't > currently have much of a use-case for it (and not going to use a $150 > Arty board for something I could do with a $20 MSP432 board). > > Basically, far too much effort trying to make things work and trying to > keep everything passing timing constraints at 100 MHz on an Arty S7. > > > I have a C compiler, but its code-generation isn't super great. > It is "basically adequate" though, and works well enough to compile > things like Doom and Quake and similar into a usable form (so, basic C > stuff generally works). > When this is all for fun and learning, I can fully appreciate it. Who doesn't dream of making their own ISA and cpu implementation, and compiler to go with it? Few of us have the time to get as far in that dream as you have already. > > The same compiler also now does a version of my BS2 language, which in > some ways sounds like "the worst of both worlds" (in many ways, it goes > pretty much exactly the opposite direction of most current "trendy" > languages). > > For BS2, its syntax is sorta like the lovechild of C, Java, and AS3. > Semantics also borrow a fair bit from C# and C++, and is statically > typed, does not use garbage collection, can still make use of raw > pointers, ... > > But, I am not designing this language to try to appeal to popular > sensibilities (nor aims to replace existing languages). > > This goes along with some really crappy versions of C++ and C# built on > top of the same core as BS2. Luckily, lots of things are more the same > than different (so it isn't too hard to share a lot of this). > > There are some language specific differences exist in terms of how > parsing is handled and the major compiler stages in the frontend (in > terms of how it is parsed and deals with declaration scope, BS2 is more > like C#). Some compiler stages exist for BS2 (and C#) which don't exist > for C or C++, and what happens in these stages may differ based on > source language. > > By the time it reaches the compiler backend it is all pretty much > normalized though. > > ...
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2019-02-15 14:15 -0600 |
| Message-ID | <q476lf$jns$1@news.albasani.net> |
| In reply to | #141066 |
On 2/15/2019 2:26 AM, David Brown wrote: > On 15/02/2019 07:47, BGB wrote: >> On 2/14/2019 2:36 PM, David Brown wrote: > >>> >>> Ah, yes - you have your own ISA and your own C compiler for it. (Why >>> don't you port gcc or llvm?) >>> >> >> GCC's codebase looks a bit intimidating; to port GCC it looks like it >> would be necessary to edit code all over the place. If I were to go over >> to GCC, would probably then be easier to jump ship over to RISC-V or >> something (given their "on paper" stats look kinda similar). >> > > There is no doubt gcc is a big project, and no doubt that porting it to > a new architecture is hard. Equally, however, there is no doubt that > making a C compiler yourself is hard - and when you put the effort in to > make the gcc port, you have a /huge/ amount extra for free. And there > is lots of information and examples about porting it, as well as people > to help - it supports many dozen official ports and lots of unofficial > ports. > OK. Though, luckily I didn't do all of it all at once. My C compiler was written incrementally over the course of about a decade, usually getting worked on "when it seems like it might be relevant". Amusingly, it was originally a fork off of my original "BGBScript" VM, which started mostly as a lazy JavaScript knock-off I made ~ 2004 (which gradually moved in a different direction than JS). Similarly, for quite a while, my C compiler, was pretty terrible. Though, it got beaten into its current form mostly by throwing a lot of effort at it over the past few years. > LLVM should be less difficult to port than gcc (though I don't pretend > it is simple). > An issue I have with LLVM is how long it takes to compile, and how much HDD space it eats up in doing so, ... It seems like at best the iteration cycle would be pretty slow. > >> >> Previously, I had been using GCC with an SH4 target, and while >> conceptually simple, SH4 has its own drawbacks: >> There are some "sharp corners" in the way parts of the ISA are designed; >> Given each instruction does relatively little work in itself (if >> compared with something like RISC-V or ARM), it requires considerably >> more instructions to be executed to perform a similar amount of work. >> >> This is partly why I ended up mostly abandoning SH4. >> >> >> But, now I am left in a situation with: >> >> My own ISA, for which its main "practical" use-case is in an emulator on >> a RasPi2, being used as part of the control software for a CNC lathe >> (which is used in a way that, in a straightforward description, would >> likely sound a bit absurd). >> > > It does sound a little convoluted, yes :-) > Yep. Though, it does appear that "VEX Robotics" does something which seems superficially similar, I am not sure if for similar reasons. They basically have user-code running in a VM on top of a Cortex-M, with most of the lower-level stuff (networking, low-level sensor / motor control / ...) done in native code. Partial reason I am going for an CPU emulator design rather than a more conventional (higher-level) VM design, is that it works out easier to timeslice a CPU emulator. Similarly for presenting native-land stuff via MMIO interfaces (and message passing) rather than allowing the VM to make calls into native-land. Though, it helps to have an ISA which: * Can achieve a reasonable amount of work per instruction ** For interpreters and naive JITs, per-instruction cost is significant. * Can be emulated cheaply and efficiently ** This puts some constraints on the ISA design. ** If per-instruction logic cost is high, performance suffers. * Isn't overly complicated. * ... To some extent, my BJX2 ISA was designed to try address both the emulator use-case as well as to hopefully be viable to implement on an FPGA. Battling with Verilog and FPGAs is kinda slow and painful though. Could have technically emulated ARM on top of ARM, but ARM is a more complicated ISA in some ways, and difficult to emulate efficiently. >> >> There was work towards a Verilog/FPGA implementation, but I have put >> this is "on hold" for now. Was sinking effort into it, and don't >> currently have much of a use-case for it (and not going to use a $150 >> Arty board for something I could do with a $20 MSP432 board). >> >> Basically, far too much effort trying to make things work and trying to >> keep everything passing timing constraints at 100 MHz on an Arty S7. >> >> >> I have a C compiler, but its code-generation isn't super great. >> It is "basically adequate" though, and works well enough to compile >> things like Doom and Quake and similar into a usable form (so, basic C >> stuff generally works). >> > > When this is all for fun and learning, I can fully appreciate it. Who > doesn't dream of making their own ISA and cpu implementation, and > compiler to go with it? Few of us have the time to get as far in that > dream as you have already. > Mostly it is for hobby and personal use. Yeah, was sort of a lot of effort. My dad sort of wants me to try to commercialize CNC conversion kits, which is partly why I am keeping the code for my CNC stuff private for now. I have doubts as to how viable this is, since it depends on (not just on making the software "usable" / "not crap"), the ability to make a fair number of mechanical parts (IOW: production runs). Most likely, would try to set it up so I can do cast aluminum for a lot of them. >> >> The same compiler also now does a version of my BS2 language, which in >> some ways sounds like "the worst of both worlds" (in many ways, it goes >> pretty much exactly the opposite direction of most current "trendy" >> languages). >> >> For BS2, its syntax is sorta like the lovechild of C, Java, and AS3. >> Semantics also borrow a fair bit from C# and C++, and is statically >> typed, does not use garbage collection, can still make use of raw >> pointers, ... >> >> But, I am not designing this language to try to appeal to popular >> sensibilities (nor aims to replace existing languages). >> >> This goes along with some really crappy versions of C++ and C# built on >> top of the same core as BS2. Luckily, lots of things are more the same >> than different (so it isn't too hard to share a lot of this). >> >> There are some language specific differences exist in terms of how >> parsing is handled and the major compiler stages in the frontend (in >> terms of how it is parsed and deals with declaration scope, BS2 is more >> like C#). Some compiler stages exist for BS2 (and C#) which don't exist >> for C or C++, and what happens in these stages may differ based on >> source language. >> >> By the time it reaches the compiler backend it is all pretty much >> normalized though. >> >> ... >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-16 01:36 +0000 |
| Message-ID | <GOJ9E.1238186$Fi6.1102052@fx12.am4> |
| In reply to | #141062 |
On 15/02/2019 06:47, BGB wrote: > The same compiler also now does a version of my BS2 language, which in > some ways sounds like "the worst of both worlds" (in many ways, it goes > pretty much exactly the opposite direction of most current "trendy" > languages). > > For BS2, its syntax is sorta like the lovechild of C, Java, and AS3. > Semantics also borrow a fair bit from C# and C++, and is statically > typed, does not use garbage collection, can still make use of raw > pointers, ... > > But, I am not designing this language to try to appeal to popular > sensibilities (nor aims to replace existing languages). I've recently started on a new language, but it is nothing earth-shattering, and is certainly not trendy. (Such languages I tend to ignore; mine tend to be much more practical, to design, implement and use.) It is also a hybrid, somewhere between my static language and my dynamic language. The latter is great to code in, but is interpreted so that programs will be slow. (I was doing some image processing stuff with it, and I didn't like that you sometimes had to wait for things to finish.) Too early to say how it will pan out. The idea is that it will replace both of the current languages. (I tried this experiment a few years ago, but my compilers of the time were not deft enough to do instant whole-program or run-from-source compilation.) At best, it will give both C and C++ a run for their money. (The current static one only does that for C.)
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2019-02-16 01:25 -0600 |
| Message-ID | <q48dss$1tv$1@news.albasani.net> |
| In reply to | #141106 |
On 2/15/2019 7:36 PM, Bart wrote:
> On 15/02/2019 06:47, BGB wrote:
>
>> The same compiler also now does a version of my BS2 language, which in
>> some ways sounds like "the worst of both worlds" (in many ways, it
>> goes pretty much exactly the opposite direction of most current
>> "trendy" languages).
>>
>> For BS2, its syntax is sorta like the lovechild of C, Java, and AS3.
>> Semantics also borrow a fair bit from C# and C++, and is statically
>> typed, does not use garbage collection, can still make use of raw
>> pointers, ...
>>
>> But, I am not designing this language to try to appeal to popular
>> sensibilities (nor aims to replace existing languages).
>
> I've recently started on a new language, but it is nothing
> earth-shattering, and is certainly not trendy. (Such languages I tend to
> ignore; mine tend to be much more practical, to design, implement and use.)
>
Yeah. A few years ago, people were obsessing over Go, now it is Rust.
Most of what I do is still C, and I don't really expect this to change
much in the near future.
> It is also a hybrid, somewhere between my static language and my dynamic
> language. The latter is great to code in, but is interpreted so that
> programs will be slow. (I was doing some image processing stuff with it,
> and I didn't like that you sometimes had to wait for things to finish.)
>
> Too early to say how it will pan out. The idea is that it will replace
> both of the current languages. (I tried this experiment a few years ago,
> but my compilers of the time were not deft enough to do instant
> whole-program or run-from-source compilation.)
>
> At best, it will give both C and C++ a run for their money. (The current
> static one only does that for C.)
>
I am not trying to replace C, FWIW.
However, it is not always the best possible language either.
BS2 is pretty much on the statically-typed side of things, with a
similar type-system to other C-family languages (ex: C, C++, Java, and
C#), I would probably also classify it as C-family.
It has some limited dynamic-typing capabilities, but these still exist
within the context of an overarching static typesystem. They are mostly
intended for edge-cases, as they will come with a performance penalty.
Rough list of types:
Integer
char, cchar (char is 16-bit, like Java; whereas cchar is 8-bit).
byte, sbyte (bytes are given their own types)
short, ushort
int, uint
long, ulong
int128, uint128 (secondary)
bool
Floating Point
float
double
hfloat (16-bit half-float)
bfloat (16-bit, truncated float)
float128 (secondary)
Reference Types
object
variant (dynamic)
string
...
Others
auto (type-inferred)
enum (decays to an integer type)
cstring (basically a C-style string, alias for '*cchar').
...
Object
class (like in Java)
interface (like in Java)
struct
Behaves roughly like in C#
Limited to "POD classes" in the C++ sense.
union (like in C, similar restrictions to 'struct')
dynamic class
...
'object' and 'variant' are similar in that both are tagged reference
types, but differ in how they behave:
object is "opaque" but can be cast to/from other types;
variant will try to figure out what to do at runtime.
Various operations can be applied, with dynamic results.
Dynamic subtypes of 'variant':
fixnum (62 bit long);
flonum (62 bit double);
object instances and array references;
strings, symbols, keywords, ...
'auto' behaves roughly like 'auto' in C++.
'enum' differs from C in that, rather than always decaying to 'int', it
may also decay to a smaller type (such as byte or short).
Pointer/Array:
*int foo1; //pointer, '*' is attached to the type.
int *foo2; //pointer, '*' is attached to the declarator.
int[] bar; //array ref
int[256] arr1; //array, size assigned to type.
int arr2[256]; //array, size assigned to declarator.
Sized arrays can decay to either array-refs or pointers. An array ref
will generally be bounds-checked, and a pointer will not (pointers
basically behave the same as in C; supporting pointer arithmetic and
other fun, ...). Array-refs can exhibit many similar behaviors to
pointers in C, though the underlying mechanism differs (and they still
preserve bounds checking behavior).
In terms of use, foo1 and foo2 are functionally equivalent in this case,
but '*' placement may become relevant in more complex declarations.
'arr1' and 'arr2' are fairly similar, but differ in semantics. 'arr1'
will nominally decay to 'int[]' whereas 'arr2' will nominally decay to
'*int'. Both are explicitly sized arrays which will reserve storage at
their point of declaration, with a lifetime tied to the scope of their
declaration.
It is also possible to create arrays via 'new', "arr=new int[128];", or
inline, "arr=[1,2,3,4,5,6,7,8]SI;".
Structs:
Have a defined memory layout (like in C).
Are pass-by-value by default (like in C).
Don't support inheritance;
Don't support virtual methods or overloading;
Don't support interfaces.
Class:
Exact memory layout depends on the implementation;
Pass-by-reference by default;
Support inheritance, virtual methods, interfaces, ...;
...
Dynamic classes are a subtype of class objects, which support fields
being added dynamically. Either the "obj.foo" or "obj[#foo]" syntax may
be used for accessing fields within dynamic objects.
A special case exists, known as an "ex-nihilo" object: "obj={x: 3, y:
4};", which is fully dynamic and lacks a parent class.
For other dynamic objects (from a base-class), the creation syntax is
"obj={x: 3, y: 4}:Foo();", with the base class still requiring the
'dynamic' modifier. Note that "obj=new Foo();" also works for dynamic
objects, though will not create any dynamic fields.
By default, any objects created this way will still require 'delete',
however, objects created with "new!" will have automatic storage
duration instead (and thus 'delete' would not be used), though 'new!' is
one-off (and thus may not be used in a loop).
Implicitly:
"Foo! obj();"
is functionally equivalent to:
"Foo obj=new! Foo();"
There are also regions:
"Foo obj=new(someRegion) Foo();"
Which assigns the lifetime of the object to a region (rather than it
being part of the global heap).
When a region is destroyed (or cleared), any contained objects are
implicitly deleted. Similarly, it is possible to "mark" or "clear to
mark" within a region (where "clear to mark" would delete anything
created after the mark was created; sort of like Quake's 'Hunk' allocation).
There are also closures, with several sub-versions. The normal version
(heap allocated, dynamic lifetime; still needs 'delete') captures bound
variables by value, and can be represented via a function pointer (the
closure pointer points to an executable stub-function).
Ex:
"fptr=function():int {x+1};" //heap storage
"fptr=function!():int {x+2};" //automatic storage
"fptr=new(someRgn) function():int {x+3};" //region storage
Though, the current (new) implementation isn't entirely complete on
these fronts.
...
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-16 12:17 +0000 |
| Message-ID | <SbT9E.535245$AD1.195800@fx05.am4> |
| In reply to | #141110 |
On 16/02/2019 07:25, BGB wrote: > On 2/15/2019 7:36 PM, Bart wrote: >> I've recently started on a new language, but it is nothing >> earth-shattering, and is certainly not trendy. > Yeah. A few years ago, people were obsessing over Go, now it is Rust. And there's Nim (mentioned in this group a few weeks ago), which actually also tries to replace languages like Python. It's quite a bloated language where they've tried to cram in too much, so it doesn't really work. However, it did give me the idea for my own hybrid language. > I am not trying to replace C, FWIW. > However, it is not always the best possible language either. (I just don't like C. I was programming for 16 years before I decided to switch to C, because on paper, that seemed the most sensible (for finding a job, working with Windows APIs, using libraries etc.) But I tried it, thought it was rubbish (this was c. 1992) and decided to revamp my own language instead. (And I became self-employed so that took care of that side.)) > It has some limited dynamic-typing capabilities, but these still exist > within the context of an overarching static typesystem. They are mostly > intended for edge-cases, as they will come with a performance penalty. > > > Rough list of types: > Integer > char, cchar (char is 16-bit, like Java; whereas cchar is 8-bit). > byte, sbyte (bytes are given their own types) > short, ushort > int, uint > long, ulong > int128, uint128 (secondary) > bool > Floating Point > float > double > hfloat (16-bit half-float) > bfloat (16-bit, truncated float) > float128 (secondary) > Reference Types > object > variant (dynamic) > string > ... > Others > auto (type-inferred) > enum (decays to an integer type) > cstring (basically a C-style string, alias for '*cchar'). > ... > Object > class (like in Java) > interface (like in Java) > struct > Behaves roughly like in C# > Limited to "POD classes" in the C++ sense. > union (like in C, similar restrictions to 'struct') > dynamic class > ... > > > 'object' and 'variant' are similar in that both are tagged reference > types, but differ in how they behave: This list, especially the way your object and variant types are added in doesn't sound that different from what I've cobbled together: https://github.com/sal55/qx/blob/master/types.md Here I've thrown in everything I thought might be useful and doable (within a short time frame), but many are likely to dropped. My 'flex' type sounds similar to your 'object' type. > Pointer/Array: > Structs: > Class: ... I can't tell you yet how this stuff is going to work. (Working on the the intermediate language at the moment. Since the aims are fairly ambitious, whatever approach I take is always threatening to to get out of hand and become impractical.)
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2019-02-16 15:08 -0600 |
| Message-ID | <q49u5c$9r0$1@news.albasani.net> |
| In reply to | #141111 |
On 2/16/2019 6:17 AM, Bart wrote:
> On 16/02/2019 07:25, BGB wrote:
>> On 2/15/2019 7:36 PM, Bart wrote:
>
>>> I've recently started on a new language, but it is nothing
>>> earth-shattering, and is certainly not trendy.
>
>
>> Yeah. A few years ago, people were obsessing over Go, now it is Rust.
>
> And there's Nim (mentioned in this group a few weeks ago), which
> actually also tries to replace languages like Python. It's quite a
> bloated language where they've tried to cram in too much, so it doesn't
> really work. However, it did give me the idea for my own hybrid language.
>
Not looked much into Nim.
Personally, don't use Python much either, though it did have a few misc
features which I borrowed, like """ ... """ string syntax.
I used a prior implementation of BS2 in my last 3D engine (in ~ 2016),
and these strings were quite helpful.
Though, one drawback they have is with whitespace:
Formatting them nicely introduces potentially unwanted linebreaks;
Indenting them (to match surrounding code) also results in the
indentation being included in the string;
...
So, not perfect, but still useful for cases where one needs "big blobs
of text".
>> I am not trying to replace C, FWIW.
>> However, it is not always the best possible language either.
>
> (I just don't like C. I was programming for 16 years before I decided to
> switch to C, because on paper, that seemed the most sensible (for
> finding a job, working with Windows APIs, using libraries etc.)
>
> But I tried it, thought it was rubbish (this was c. 1992) and decided to
> revamp my own language instead. (And I became self-employed so that took
> care of that side.))
>
I have been using C for most of my life.
I tried various other languages, but few really fit what I was doing
well enough to cause me to switch.
I started originally with BASIC, but the language saw little usage much
outside DOS and similar. I also used ASM, but ASM has some obvious
drawbacks (I do remember though that as a child, I found ASM easier to
understand than C).
Early on, I also used C++ a lot more, but the frequent "rather hit or
miss" support was a bit of a turn-off:
If I write code in C, I can use it pretty much anywhere I need it;
If I write code in C++, it is limited to targets with a working C++
compiler.
For occasional tinkering with embedded targets, it wasn't terribly
uncommon to encounter:
GCC builds which only have GCC, but no G++ or similar;
one off compilers which frequently only supported C89 or similar;
...
I have occasionally written code in Java, however:
Early on, its performance was rather poor;
Single top level class per source file gets old;
Generally, less range of supported targets than C;
...
>> It has some limited dynamic-typing capabilities, but these still exist
>> within the context of an overarching static typesystem. They are
>> mostly intended for edge-cases, as they will come with a performance
>> penalty.
>>
>>
>> Rough list of types:
>> Integer
>> char, cchar (char is 16-bit, like Java; whereas cchar is 8-bit).
>> byte, sbyte (bytes are given their own types)
>> short, ushort
>> int, uint
>> long, ulong
>> int128, uint128 (secondary)
>> bool
>> Floating Point
>> float
>> double
>> hfloat (16-bit half-float)
>> bfloat (16-bit, truncated float)
>> float128 (secondary)
>> Reference Types
>> object
>> variant (dynamic)
>> string
>> ...
>> Others
>> auto (type-inferred)
>> enum (decays to an integer type)
>> cstring (basically a C-style string, alias for '*cchar').
>> ...
>> Object
>> class (like in Java)
>> interface (like in Java)
>> struct
>> Behaves roughly like in C#
>> Limited to "POD classes" in the C++ sense.
>> union (like in C, similar restrictions to 'struct')
>> dynamic class
>> ...
>>
>>
>> 'object' and 'variant' are similar in that both are tagged reference
>> types, but differ in how they behave:
>
> This list, especially the way your object and variant types are added in
> doesn't sound that different from what I've cobbled together:
>
> https://github.com/sal55/qx/blob/master/types.md
>
> Here I've thrown in everything I thought might be useful and doable
> (within a short time frame), but many are likely to dropped.
>
> My 'flex' type sounds similar to your 'object' type.
>
The 'object' type was borrowed from C#.
In the original BGBScript, both use-cases were handled by "variant", but
in BS2, I ended up splitting them up because they have different
semantics (and partly also due to C# influence).
The 'variant' in BS2 differs from the one in C#, in that BS2 uses the
term for a dynamic type, whereas C# uses it for something similar to 'auto'.
Calling it "variant" originally came about when the original BGBScript
migrated from dynamic to static types, and basically used this name
because this was what this was called in QBasic and Visual Basic.
The BS2 'auto' type is basically borrowing the C++ 'auto' type.
As for other types:
cchar is basically a byte, but has its own type in signature strings.
char is basically ushort, but also has its own signature type.
bool is basically a byte, but likewise has its own type.
Half float and BFloat exist mostly because they are often useful, and
are also supported as C extensions. These types only really exist in
structs/pointers/arrays, but in most other cases are quietly promoted to
float or double.
The two types have different tradeoffs:
Half float has more precision but limited dynamic range (S.E5.F10).
BFloat has higher dynamic range but limited precision (S.E8.F7).
>> Pointer/Array:
>
>> Structs:
>
>> Class:
> ...
>
> I can't tell you yet how this stuff is going to work. (Working on the
> the intermediate language at the moment. Since the aims are fairly
> ambitious, whatever approach I take is always threatening to to get out
> of hand and become impractical.)
>
I already have a prior implementation, just it runs in a VM rather than
being compiled to machine-code (of some sort).
For the most part, it tries to be a fairly thin abstraction.
Arrays are problematic, as there are two major ways to do these:
Object address + small base offset (in a 64-bit tagged reference), with
object header;
128-bit Fat pointer, which encodes the base address, base offset, and
array size directly.
Originally, I was going to go with the fat pointer (in this
implementation), but switched back to the 64b tagref + header as this is
easier (this is more like the prior implementation).
The fat-pointer approach would give better performance though.
Class/Instance objects are basically a similar layout to what is used in
a typically C++ ABI (object payload with a VTable pointer, ...).
Interfaces are basically just tacked on the end of the object (with an
interface pointer being a pointer to the vtable-pointer for that
interface within an object).
Dynamic classes are a special case, where a pointer is provided (in the
object's layout) which points to a dynamic object header (effectively,
it is daisy-chained from the class/instance object).
Within a dynamic object, if an named field ("obj.name") has a
statically-defined declaration, this will be used instead of a dynamic
lookup (main functional difference is a dynamic object will emit a
dynamic lookup for missing fields, rather than a compiler error).
In the BJX2 ISA, the tag-refs can be used directly as pointers, mostly
because the high 16 bits of pointers are basically ignored (1). This
differs some from x86-64, where it is necessary to mask off these bits.
The high-order 2/4 bits give the tagref type, and the remaining 12 bits
may be used for an object-type-tag (objects) or base-offset (arrays).
As noted, the type of the object is generally encoded directly in the
tagref (rather than relying on an object header in a heap allocated object).
This allows in some cases tagrefs to refer to non-heap locations (such
as pointing to objects or arrays located on the stack).
1: Pointers are basically 48 bits, of which 47 bits are usable for
userland addresses. In many cases, the addressing is also 4GB modular
(in my prototype FPGA implementation; mostly timing related).
Though, there is a sub-mode which uses 32-bit addresses (with a 31-bit
userland), which is the variant used in my CNC project. In this mode,
the high 32 bits of address registers are ignored, and operations like
LEA and similar only produce a 32-bit output (the high-order bits are
undefined).
This mode is sorta like the "x32" ABI, with 32-bit pointers but can
still use 64-bit operations for data.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-16 23:10 +0000 |
| Message-ID | <hL0aE.1224457$3si.1092901@fx08.am4> |
| In reply to | #141119 |
On 16/02/2019 21:08, BGB wrote: > On 2/16/2019 6:17 AM, Bart wrote: > Personally, don't use Python much either, though it did have a few misc > features which I borrowed, like """ ... """ string syntax. > > I used a prior implementation of BS2 in my last 3D engine (in ~ 2016), > and these strings were quite helpful. > > Though, one drawback they have is with whitespace: > Formatting them nicely introduces potentially unwanted linebreaks; > Indenting them (to match surrounding code) also results in the > indentation being included in the string; > ... > > So, not perfect, but still useful for cases where one needs "big blobs > of text". You mean text that acts like a large string constant within source code? I have a feature used as 'strinclude filename', which incorporates any file as a string constant (text-only for static language; text or binary for dynamic). As far as I remember, it was based on one of your features that you posted about a few years ago (when you were cr-something or other). I don't remember if it was the """ strings or something different. > I have been using C for most of my life. > > I tried various other languages, but few really fit what I was doing > well enough to cause me to switch. I needed such a language when I wasn't working and having to build my own stuff with bare microprocessors, ram chips and logic. C (which I'd never used anyway) was out of the question, as was anything else really. Anyway I preferred what I came up with to C, even when it became possible to use it. (But decide for yourself: https://github.com/sal55/qx/blob/master/bignum.m https://github.com/sal55/qx/blob/master/bignum.c First link is to a numeric library in my current language. Second to a manual C port of it. (The C requires a separate header file, the other doesn't; it's self-contained.). Slightly unfair comparison though as github knows how to syntax highlight C; it can't do the same for mine.) > Though, there is a sub-mode which uses 32-bit addresses (with a 31-bit > userland), which is the variant used in my CNC project. In this mode, > the high 32 bits of address registers are ignored, and operations like > LEA and similar only produce a 32-bit output (the high-order bits are > undefined). > > This mode is sorta like the "x32" ABI, with 32-bit pointers but can > still use 64-bit operations for data. My first x64 compiler uses 32-bit pointers. But it started becoming fiddly to deal with pointers from outside (OS and external libraries) which were still 64-bit. Also, when translating to C, some compilers put my code at 'high' addresses, IIRC, screwing up my 32-bit function pointers.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2019-02-17 00:56 -0600 |
| Message-ID | <q4b0jn$695$1@news.albasani.net> |
| In reply to | #141121 |
On 2/16/2019 5:10 PM, Bart wrote: > On 16/02/2019 21:08, BGB wrote: >> On 2/16/2019 6:17 AM, Bart wrote: > >> Personally, don't use Python much either, though it did have a few >> misc features which I borrowed, like """ ... """ string syntax. >> >> I used a prior implementation of BS2 in my last 3D engine (in ~ 2016), >> and these strings were quite helpful. >> >> Though, one drawback they have is with whitespace: >> Formatting them nicely introduces potentially unwanted linebreaks; >> Indenting them (to match surrounding code) also results in the >> indentation being included in the string; >> ... >> >> So, not perfect, but still useful for cases where one needs "big blobs >> of text". > > > You mean text that acts like a large string constant within source code? > Yeah, rather than being like: string str= "first line\n" "second line\n" "third line\n"; It is possible to write: string str=""" first line second line third line """; If dealing with needing to have random paragraph-sized blobs of text and similar, this can be pretty useful. > I have a feature used as 'strinclude filename', which incorporates any > file as a string constant (text-only for static language; text or binary > for dynamic). > > As far as I remember, it was based on one of your features that you > posted about a few years ago (when you were cr-something or other). I > don't remember if it was the """ strings or something different. > I am not sure, I don't really remember. >> I have been using C for most of my life. >> >> I tried various other languages, but few really fit what I was doing >> well enough to cause me to switch. > > I needed such a language when I wasn't working and having to build my > own stuff with bare microprocessors, ram chips and logic. C (which I'd > never used anyway) was out of the question, as was anything else really. > > Anyway I preferred what I came up with to C, even when it became > possible to use it. (But decide for yourself: > > https://github.com/sal55/qx/blob/master/bignum.m > > https://github.com/sal55/qx/blob/master/bignum.c > > First link is to a numeric library in my current language. Second to a > manual C port of it. (The C requires a separate header file, the other > doesn't; it's self-contained.). Slightly unfair comparison though as > github knows how to syntax highlight C; it can't do the same for mine.) > OK. Here is a few examples of my language (as it was used in my 3D engine): https://github.com/cr88192/bgbtech_engine2/blob/master/resource/bte3d/EntMain.bs https://github.com/cr88192/bgbtech_engine2/blob/master/resource/bte3d/npc_tron.bs https://github.com/cr88192/bgbtech_engine2/blob/master/resource/bte3d/misc_rocket.bs The current effort is a different implementation, but the same basic language design. It was going reasonably well at the time, though activity on my 3D engine mostly fizzled out as I have mostly ended up working on other stuff. >> Though, there is a sub-mode which uses 32-bit addresses (with a 31-bit >> userland), which is the variant used in my CNC project. In this mode, >> the high 32 bits of address registers are ignored, and operations like >> LEA and similar only produce a 32-bit output (the high-order bits are >> undefined). >> >> This mode is sorta like the "x32" ABI, with 32-bit pointers but can >> still use 64-bit operations for data. > > My first x64 compiler uses 32-bit pointers. But it started becoming > fiddly to deal with pointers from outside (OS and external libraries) > which were still 64-bit. Also, when translating to C, some compilers put > my code at 'high' addresses, IIRC, screwing up my 32-bit function pointers. > In the 32-bit mode, only the low 2GB are allowed for userland code. Memory map, is basically: 00000000..7FFFFFFF: Userland 80000000..9FFFFFFF: System / Kernel A0000000..BFFFFFFF: MMIO (No-MMU) C0000000..DFFFFFFF: System, No-MMU (first 512MB of physical space). E0000000..FFFFFFFF: Processor/Chipset In the 32-bit addressing mode, this is the entire memory map (the rest of the register is ignored). If MMU is used, it generally uses a page-table layout like that in 32-bit x86. The 48/64 bit addressing mode is similar, just with the addresses extended out. The address range of 0000_80000000..0000_FFFFFFFF is special, and still functions as it does in the 32-bit memory map. 0001_00000000..7FFF_FFFFFFFF is userland, but currently only relevant for the MMU (the prototype Verilog implementation used 32-bit physical addressing). In the memory map, DRAM may be located at 01000000..7FFFFFFF. In the CNC controller, currently there is 128MB reserved for RAM for the VM, so: 01000000..09FFFFFF: RAM Additionally: 00000000..00007FFF: Boot ROM (32K) 0000C000..0000DFFF: Boot SRAM (8K) Externally, there is also a currently 32MB SDcard image (basically as a FAT filesystem image accessed via an SDcard interface via SPI). The 32K boot ROM generally loads the VM part of the control program from the FAT image, which may also include any other files needed by the control program (such as G-Code files and similar). Currently, the UI is still done over SSH, but there is the possibility of moving the UI over to a sort of more specialized program (though, effectively, it would still be a glorified terminal emulator, but with in-band file-transfer capabilities and similar). TBD is if the UI will still be based around drawing stuff via ANSI codes, or based on streaming the contents of an 80x25 character-cell buffer (which the UI draws into directly), or some combination thereof (using ANSI codes to draw into the character-cell buffer, which is then streamed over the network). Note that the streamed console would be capable of color-cell graphics modes. Which are more funky than conventional bitmapped framebuffer graphics, but require a lot less VRAM (ex: 320x200 in 16K or 32K, or 640x400 in 64K). Going much lower than this (eg: 4K or 8K) basically limits one to either reduced-resolution color-cells or drawing "graphics" via character cells (eg: CP437 or PETSCII or similar). Either way, if I went this route, the contents of the console buffer would be regularly delta'd and sent over a network connection. A bit of uncertainty here. While not exactly well polished, doing this stuff via PuTTY and FTP is tried and true (and, for another interface, I would need to configure things to run at boot daemon-style, ..., complicating the process). But, I don't expect a SSH+FTP driven UI would go over well if I do ever try to sell this (more so as most of the competition here is using GUIs; but I have never been particularly good at making passable GUIs).
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-02-17 17:30 +0000 |
| Message-ID | <2TgaE.456098$9F1.69770@fx39.am4> |
| In reply to | #141128 |
On 17/02/2019 06:56, BGB wrote: > On 2/16/2019 5:10 PM, Bart wrote: >> You mean text that acts like a large string constant within source code? >> > > Yeah, rather than being like: > string str= > "first line\n" > "second line\n" > "third line\n"; > > It is possible to write: > string str=""" > first line > second line > third line > """; > > If dealing with needing to have random paragraph-sized blobs of text and > similar, this can be pretty useful. I use such a feature on a big scale, with sometimes dozens of files with 100s of KB added in to a project (eg. library sources). But I can see that being able to directly paste in smaller blocks would also be useful. (So yet another feature to consider.) I can see also your point about indentation (from your links): is it possible that the same amount of indent used for the """s can be disregarded for the body of the text? (Although there will be the usual issues with tabs vs spaces.) > Note that the streamed console would be capable of color-cell graphics > modes. Which are more funky than conventional bitmapped framebuffer > graphics, but require a lot less VRAM (ex: 320x200 in 16K or 32K, or > 640x400 in 64K). > > Going much lower than this (eg: 4K or 8K) basically limits one to either > reduced-resolution color-cells or drawing "graphics" via character cells > (eg: CP437 or PETSCII or similar). (8KB for graphics isn't so bad. The first graphics board I built had 8KB static ram (mapped as 16K 4-bit nibbles), which could display 128x128x4 greyscale, or 256x256 mono. Not bad for the time. (The greyscale was used for TV capture, and the mono for 3D graphics, among a bunch of other stuff.) I'm not sure how it would compare now to my HD colour monitor, but it was a million times easier to program that 16KB memory-mapped display than doing it via Windows' APIs. Lots of things were. Personally, I would stay clear of cell-mapped graphics (ie. defining the character cells of a text display) unless that was the only possibility.)
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2019-02-17 16:02 -0600 |
| Message-ID | <q4clmi$3fc$1@news.albasani.net> |
| In reply to | #141132 |
On 2/17/2019 11:30 AM, Bart wrote: > On 17/02/2019 06:56, BGB wrote: >> On 2/16/2019 5:10 PM, Bart wrote: > >>> You mean text that acts like a large string constant within source code? >>> >> >> Yeah, rather than being like: >> string str= >> "first line\n" >> "second line\n" >> "third line\n"; >> >> It is possible to write: >> string str=""" >> first line >> second line >> third line >> """; >> >> If dealing with needing to have random paragraph-sized blobs of text >> and similar, this can be pretty useful. > > I use such a feature on a big scale, with sometimes dozens of files with > 100s of KB added in to a project (eg. library sources). > > But I can see that being able to directly paste in smaller blocks would > also be useful. (So yet another feature to consider.) > > I can see also your point about indentation (from your links): is it > possible that the same amount of indent used for the """s can be > disregarded for the body of the text? (Although there will be the usual > issues with tabs vs spaces.) > I had considered this, but implicit formatting-sensitive parsing is something I would prefer to avoid if possible. Sorta passable in Python (since the whole language basically works this way), but is sort-of out-of-place with a C-family syntax. >> Note that the streamed console would be capable of color-cell graphics >> modes. Which are more funky than conventional bitmapped framebuffer >> graphics, but require a lot less VRAM (ex: 320x200 in 16K or 32K, or >> 640x400 in 64K). >> >> Going much lower than this (eg: 4K or 8K) basically limits one to >> either reduced-resolution color-cells or drawing "graphics" via >> character cells (eg: CP437 or PETSCII or similar). > > (8KB for graphics isn't so bad. The first graphics board I built had 8KB > static ram (mapped as 16K 4-bit nibbles), which could display 128x128x4 > greyscale, or 256x256 mono. Not bad for the time. (The greyscale was > used for TV capture, and the mono for 3D graphics, among a bunch of > other stuff.) > > I'm not sure how it would compare now to my HD colour monitor, but it > was a million times easier to program that 16KB memory-mapped display > than doing it via Windows' APIs. Lots of things were. > > Personally, I would stay clear of cell-mapped graphics (ie. defining the > character cells of a text display) unless that was the only possibility.) > For a CNC UI, generally it would more need to be 640x400 (or higher), with primarily textual contents. Typically, most graphical elements would be things like border-lines (around flat colored regions) and similar, many of which can also be done via character cells and/or attribute flags. Typically, things like reverse color and blinking text are also useful, ... Sometimes, it is also useful to display things like wireframe graphics (say, if you want to plot out the path taken by a cutting tool). So, unlike a game, actual graphics are typically a small minority of the UI. On actual (big commercial style) CNC machines, typically the UI is driven via a specialized keyboard interface, frequently with also with jog-wheels and similar. These are typically on a control-panel with a monitor, typically mounted onto the CNC machine via a swivel-arm. On the machines I have dealt-with (mostly Haas and Fanuc), the main display was either a CRT or LCD, generally with multi-colored text (reminiscent of many MS-DOS era applications), but which also included some graphical elements and capabilities. Typically there was no mouse or pointy/clicky, just sort of a funky keyboard with a lot of buttons (and usually the keyboard would only include a subset of the letters; other letters would require hitting a shift-key or similar, *). Also, typically they would beep every time a key is hit (sorta like a microwave oven). *: Imagine, instead of like a PC keyboard, they cram *all* of the letters into a 4x4 keypad or similar (so, like half the letters require shifting). A lot of the other keys are effectively F-keys, or used for various menus or similar (or are big special buttons like "cycle start" or an E-stop). Granted, still slightly less annoying than trying to type on a flip-phone (or with the on-screen keyboard on Android). A lot of the PC-based programs (eg: FlashCUT and Mach and similar) use Windows-style GUIs running on a PC (which generally plug into a interface box via USB, which in turn controls the various motors). In my case, I am using a PC as well, but mostly that is because otherwise I would need a screen and keyboard for the RasPi (if I do a kit, if people want a keyboard and monitor for the RasPi, they will probably need to provide this themselves). The main alternative is basically using a PC, and probably streaming the UI from the RasPi (probably via UDP). However, A full bitmap display would mean something more akin to VNC, which is fairly slow and takes a bit more CPU power to stream (VNC into a RasPi is pretty laggy and eats a lot of CPU power). So, a character cell based UI (more like that on a Haas or Fanuc based machine) makes a bit of sense for the use-case. One can fit a full 640x400 graphical display in roughly 64K of VRAM, and most textual updates will only need to stream deltas for the part of the framebuffer corresponding to the character-cell contents (roughly 8K in my design). The existing display interface is actually capable of graphics (sufficient to display Doom and Quake in 320x200), but this generally requires transcoding to color-cell from a bitmapped framebuffer, which I don't really want to do for the CNC. Trying to draw bitmapped-style directly into the color-cell framebuffer is a little bit-twiddly though, and at 640x400 is effectively limited to monochrome (but with a choice of foreground/background color for the various character cells). Granted, if the host PC has a mouse, I could at least support pointy/clicky on some of the on-screen buttons (or using the scroll wheel on the mouse as a jog wheel). Or such...
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-02-14 13:49 +0000 |
| Message-ID | <878syiiip4.fsf@bsb.me.uk> |
| In reply to | #140982 |
BGB <cr88192@hotmail.com> writes: <cut> > Clarification: One doesn't generally need new operators/... > Because it is usually possible to express most concepts sufficiently > via function calls, and if they invoke special logic in the compiler > (like an operator would), then using an operator is merely an > aesthetic convenience. There's are a couple of exceptions. Numerical operators in C are privileged in that they are usually defined for all arithmetic (and sometimes scalar) types. A max operator would be more convenient than that family of max functions. Also, with a binary operator X you would expect an assignment operator X= which is harder to arrange with a function. Keeping a running maximum could then be written mval[i] @= val; Some languages have syntax to let you turn functions into operators and operators into functions. Makes sense when they are only syntactically different, but in C that is not the case though one could imagine some hairy type matching rules that could make it work. <cut> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2019-02-14 09:08 +0100 |
| Message-ID | <q437l7$okp$1@solani.org> |
| In reply to | #140933 |
Am 13.02.19 um 15:43 schrieb David Brown: > > First, you would have to have an idea of /why/ you want extra > punctuation characters. What are they for? Are you talking about > introducing new operators? If that is the case, you have to ask: > > 1. Would they useful enough to justify a new operator? > 2. Would they be clear enough and unmistakeable to users? > 3. Can users type them conveniently? > 4. Can users display them conveniently? > 5. Can they be added without making the language more complicated? > 6. Can they be added without making all of today's tools (compilers, > checkers, IDEs, highlighting editors, etc.) unusable? > > People have suggested this sort of thing before - such as "a ⊓ b" for > minimum and "a ⊔ b" for maximum, and failed on every point above. > > What are you bringing to the table that will change that? Proposals for the introduction of attributes in C2X (i.e. the standard equivalent for GNU __attribute__ and Microsoft __declspec) used new characters, e.g.: ⟦std ∷ maybe_unused⟧ for quite a while. AFAIK [[ :: ]] is now more popular than ⟦ ∷ ⟧ for C++ compability, despite there being some issues with [[ :: ]] (see N2175). Philipp
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-14 09:56 +0100 |
| Message-ID | <q43af3$fiu$1@dont-email.me> |
| In reply to | #140974 |
On 14/02/2019 09:08, Philipp Klaus Krause wrote: > Am 13.02.19 um 15:43 schrieb David Brown: >> >> First, you would have to have an idea of /why/ you want extra >> punctuation characters. What are they for? Are you talking about >> introducing new operators? If that is the case, you have to ask: >> >> 1. Would they useful enough to justify a new operator? >> 2. Would they be clear enough and unmistakeable to users? >> 3. Can users type them conveniently? >> 4. Can users display them conveniently? >> 5. Can they be added without making the language more complicated? >> 6. Can they be added without making all of today's tools (compilers, >> checkers, IDEs, highlighting editors, etc.) unusable? >> >> People have suggested this sort of thing before - such as "a ⊓ b" for >> minimum and "a ⊔ b" for maximum, and failed on every point above. >> >> What are you bringing to the table that will change that? > > Proposals for the introduction of attributes in C2X (i.e. the standard > equivalent for GNU __attribute__ and Microsoft __declspec) used new > characters, e.g.: > > ⟦std ∷ maybe_unused⟧ > > for quite a while. AFAIK [[ :: ]] is now more popular than > ⟦ ∷ ⟧ for C++ compability, despite there being some issues with [[ :: ]] > (see N2175). > You can expect the proposal to use unicode characters here to be quickly rejected by almost everyone - C committee members (other than the guy who suggested them), C compiler writers, IDE makers, programmers. It is a daft idea. Just use [[ :: ]] like C++. It puts a little work on the compiler writers' desks, to support the new syntax. But most compiler vendors who would support C2x attributes in the near future already support C++ and C++ attributes. They already have the solutions in place for C++, meaning it might not be difficult to put it into their C front end. (It might still be a challenge if their front-ends are implemented differently.) It would be /insane/ to insist on unicode characters in the source code. It would be /insane/ to go back to digraphs to get round a new problem being introduced.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2019-02-14 11:06 +0100 |
| Message-ID | <q43ek4$sv9$1@solani.org> |
| In reply to | #140978 |
Am 14.02.19 um 09:56 schrieb David Brown: > Just use [[ :: ]] like C++. It puts a little work on the compiler > writers' desks, to support the new syntax. But most compiler vendors > who would support C2x attributes in the near future already support C++ > and C++ attributes. I don't think so. There are more than 10 times as many C compiler vendors as C++ compiler vendors. Philipp
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-14 15:01 +0100 |
| Message-ID | <q43sbe$fud$1@dont-email.me> |
| In reply to | #140981 |
On 14/02/2019 11:06, Philipp Klaus Krause wrote: > Am 14.02.19 um 09:56 schrieb David Brown: >> Just use [[ :: ]] like C++. It puts a little work on the compiler >> writers' desks, to support the new syntax. But most compiler vendors >> who would support C2x attributes in the near future already support C++ >> and C++ attributes. > I don't think so. There are more than 10 times as many C compiler > vendors as C++ compiler vendors. > How many of those C but not C++ vendors support C11 (at least roughly) today, 7 years after its ratification? Perhaps 10% of them - and that's with the minor changes in C11. How many are likely to want to support C2x? Perhaps 10% of those. How many of /those/ are going to prefer unicode characters for attributes, compared to [[ :: and ]] ? Perhaps 1%. Rounding to the nearest fraction of a C compiler vendor, I expect exactly /zero/ will want to support C2x attributes with unicode symbols. Like it or not (and I don't particularly like it), the field is narrowing and the small C compiler vendors are becoming increasingly irrelevant. They will continue to exist for niche cases, such as small 8-bit CISC microcontrollers - which are themselves becoming niche products.
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2019-02-15 05:30 -0800 |
| Message-ID | <de8132cb-6d09-470e-b836-bffdce3891e5@googlegroups.com> |
| In reply to | #140908 |
On Wednesday, 13 February 2019 11:16:43 UTC, fir wrote: > this is not pure theory not as probably (if i will not die) one year i will be just implementing it and you will see it in some editor in a form of characters you may type in (feels like vague future now hovever) > > the topic is about that that it seems to me that c needs more characters (i dont know how to name them, punctuation characters? i mean such non letter characters like *&^%$#_+_=-;',.<> and so on just wider charset) in its definition > > those chatracters would allow more expression than today set when you sometimes > think what to use and youre limited in options as sometimes things dont fit > > i would hovever like be well understood, i dont want to make C a mess like some communicator for kids full of weird looking emoji icons or something like that > > i more think i would just like something > like present set of graphical characters (everybody knows them, those few tens of asci ones) just with some addition.. if now you got them 30 or some more i would like to get some more (like 15 additional at first and eventually some more later but this should will be well rethinked sett, thinked to be 'new classical' set like preious set is clasical, and most probably be not open to free extensions > > i think this way > > question is what chars to introduce (to make this new classical set (codename it ascii-II or something like that) > > (secondary question is how to implement it in txt documents, prefereably it should be 2-byte unicode conformant) https://dilbert.com/strip/2005-09-10 last panel.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-02-15 05:42 -0800 |
| Message-ID | <6e69cd64-a7f6-4d96-b3ca-c6c903ffbdfd@googlegroups.com> |
| In reply to | #141077 |
W dniu piątek, 15 lutego 2019 14:30:16 UTC+1 użytkownik mark.b...@gmail.com napisał: > On Wednesday, 13 February 2019 11:16:43 UTC, fir wrote: > > this is not pure theory not as probably (if i will not die) one year i will be just implementing it and you will see it in some editor in a form of characters you may type in (feels like vague future now hovever) > > > > the topic is about that that it seems to me that c needs more characters (i dont know how to name them, punctuation characters? i mean such non letter characters like *&^%$#_+_=-;',.<> and so on just wider charset) in its definition > > > > those chatracters would allow more expression than today set when you sometimes > > think what to use and youre limited in options as sometimes things dont fit > > > > i would hovever like be well understood, i dont want to make C a mess like some communicator for kids full of weird looking emoji icons or something like that > > > > i more think i would just like something > > like present set of graphical characters (everybody knows them, those few tens of asci ones) just with some addition.. if now you got them 30 or some more i would like to get some more (like 15 additional at first and eventually some more later but this should will be well rethinked sett, thinked to be 'new classical' set like preious set is clasical, and most probably be not open to free extensions > > > > i think this way > > > > question is what chars to introduce (to make this new classical set (codename it ascii-II or something like that) > > > > (secondary question is how to implement it in txt documents, prefereably it should be 2-byte unicode conformant) > > https://dilbert.com/strip/2005-09-10 last panel. this is what you could get when you would go to much open to unicode in operators.. what im proposing to only take some additional narrow set and stick to it the problem is it needs to be chosen
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2019-02-15 18:19 -0600 |
| Message-ID | <q47kv4$i3l$1@dont-email.me> |
| In reply to | #140908 |
On 2/13/2019 5:16 AM, fir wrote:
> this is not pure theory not as probably (if i will not die) one year i will be just implementing it and you will see it in some editor in a form of characters you may type in (feels like vague future now hovever)
>
> the topic is about that that it seems to me that c needs more characters (i dont know how to name them, punctuation characters? i mean such non letter characters like *&^%$#_+_=-;',.<> and so on just wider charset) in its definition
>
> those chatracters would allow more expression than today set when you sometimes
> think what to use and youre limited in options as sometimes things dont fit
>
> i would hovever like be well understood, i dont want to make C a mess like some communicator for kids full of weird looking emoji icons or something like that
>
> i more think i would just like something
> like present set of graphical characters (everybody knows them, those few tens of asci ones) just with some addition.. if now you got them 30 or some more i would like to get some more (like 15 additional at first and eventually some more later but this should will be well rethinked sett, thinked to be 'new classical' set like preious set is clasical, and most probably be not open to free extensions
>
> i think this way
>
> question is what chars to introduce (to make this new classical set (codename it ascii-II or something like that)
>
> (secondary question is how to implement it in txt documents, prefereably it should be 2-byte unicode conformant)
No, you are reinventing the world. And Unicode UTF-8 is from one byte
to four bytes in length. It may be more in the future.
https://unicode.org/
and
https://en.wikipedia.org/wiki/UTF-8
and
https://www.fileformat.info/info/charset/UTF-8/list.htm
Lynn
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web