Here we go again, you actually want me to ignore you, another rude insulting rant (emphasis added by me) where you attack demons of your own making. You're ignored for abusive and demeaning language.
sublime!
uint32_t rotl32a (uint32_t x, uint32_t n)
{
return (x<<n) | (x>>(32-n));
}
That's basically where what @Jportici wrote came from 3. Array bounds checking: The language would have built-in array bounds checking to prevent out-of-bounds errors when accessing arrays.
Here I think we can support two modes, fast and slow. The fast simply ensures that the referenced element lies inside the array, it might be accessed with illegal subscripts, be the wrong element, but it is inside the array. The slow verifies each subscript against the arrays defined bounds. In a 10x10 array for example accessing [2,12] is wrong but won't corrupt system memory (only user data memory). These checks are not hard to do and some CPUs even offer instructions to assist. This capability could also be enabled/disabled at runtime, perhaps even on a per-array basis...
10. Support for hardware-level control: The language would have support for interacting with low-level hardware, in order to allow for the precise control that is often required in embedded systems.
This needs better definition IMHO. The language does offer "bit" as a data type and supports declaring arrays of bits and various alignment options too. But is there more too this? What does "low level" really mean? I can see scope for abstract access to the stack, some operations that might allow stack walking perhaps but we soon get to target specific stuff which is undesirable.
27. Static analysis: The language would have built-in static analysis tools that can analyze the code and detect potential errors, such as null pointer dereferences, race conditions, and buffer overflows, before the code is even run.
This is good, I've not thought much about this though, so this needs more definition perhaps...
if a < b < c > d then
log("Conditions Met.");
if a < b && b < c && c > d then
log("Conditions Met.");
3. Array bounds checking: The language would have built-in array bounds checking to prevent out-of-bounds errors when accessing arrays.
Here I think we can support two modes, fast and slow. The fast simply ensures that the referenced element lies inside the array, it might be accessed with illegal subscripts, be the wrong element, but it is inside the array. The slow verifies each subscript against the arrays defined bounds. In a 10x10 array for example accessing [2,12] is wrong but won't corrupt system memory (only user data memory). These checks are not hard to do and some CPUs even offer instructions to assist. This capability could also be enabled/disabled at runtime, perhaps even on a per-array basis...
When passing an array to a function, the compiler should also pass the the length of the array to the function, so that the function can obtain the length of the array at the run-time.
For example, in C this needs to be done manually by introducing an additional parameter to the function. Also, any array bounds checking needs to be done manually. It is very easy to produce off-by-one array access errors in C.
The programmer should be able to enable/disable the compiler-generated array bounds checking. During unit testing, the programmer may want to enable all checks for best test coverage. For the production code, the programmer may want to disable the bounds checking selectively in some parts of the code.10. Support for hardware-level control: The language would have support for interacting with low-level hardware, in order to allow for the precise control that is often required in embedded systems.
This needs better definition IMHO. The language does offer "bit" as a data type and supports declaring arrays of bits and various alignment options too. But is there more too this? What does "low level" really mean? I can see scope for abstract access to the stack, some operations that might allow stack walking perhaps but we soon get to target specific stuff which is undesirable.
I read this as "the programming language should have means to define and access the peripheral registers with an ease".
Typically the operations for peripheral registers are reading/writing a register, and testing/setting/clearing/toggling a bit or set of bits in the register.
The language should have support for defining bits and bitmasks for the registers, and prevent using a (wrong) bit mask defined for another register.
This whole register access-topic is quite complex, and needs careful analysis to get it right. For example, some registers may be read-only, some write-only, and some register may contain bits that are read-only, etc. It would be a good thing if the programming language had support for expressing these things, and the compiler could check for proper register and bit accesses. At this point I do not have any good ideas for this, though.27. Static analysis: The language would have built-in static analysis tools that can analyze the code and detect potential errors, such as null pointer dereferences, race conditions, and buffer overflows, before the code is even run.
This is good, I've not thought much about this though, so this needs more definition perhaps...
This might be tricky, and I know very little about this topic. However, using compile-time static asserts/checks, and checks/asserts during runtime with preconditions, post-conditions and other checks could help conveying the information how the functions are expected to behave and what kind of parameter values functions are expecting. These run-time checks can be enabled during unit testing, and selectively turned off in the production code. The compiler should be able to ascertain that there are no unwanted side effects when performing these checks.
procedure sort_table (table);
arg table(*,*,*) bin(15);
end;
sublime!
talking about sublime, I checked an old copy of my Dr. Dobb's Journal, and it says ROL and ROR were useful during i386 era for bit-by-bit examining a value in a way that is non-information-destructive.
Kind of bit(x)-test for intel chips
Then it points out something like this. Nice, isn't it?
("Safe, Efficient, and Portable Rotate in C/C++")Code: [Select]uint32_t rotl32a (uint32_t x, uint32_t n)
That's basically where what @Jportici wrote came from
{
return (x<<n) | (x>>(32-n));
}
3. Array bounds checking: The language would have built-in array bounds checking to prevent out-of-bounds errors when accessing arrays.
Here I think we can support two modes, fast and slow. The fast simply ensures that the referenced element lies inside the array, it might be accessed with illegal subscripts, be the wrong element, but it is inside the array. The slow verifies each subscript against the arrays defined bounds. In a 10x10 array for example accessing [2,12] is wrong but won't corrupt system memory (only user data memory). These checks are not hard to do and some CPUs even offer instructions to assist. This capability could also be enabled/disabled at runtime, perhaps even on a per-array basis...
When passing an array to a function, the compiler should also pass the the length of the array to the function, so that the function can obtain the length of the array at the run-time.
For example, in C this needs to be done manually by introducing an additional parameter to the function. Also, any array bounds checking needs to be done manually. It is very easy to produce off-by-one array access errors in C.
The programmer should be able to enable/disable the compiler-generated array bounds checking. During unit testing, the programmer may want to enable all checks for best test coverage. For the production code, the programmer may want to disable the bounds checking selectively in some parts of the code.10. Support for hardware-level control: The language would have support for interacting with low-level hardware, in order to allow for the precise control that is often required in embedded systems.
This needs better definition IMHO. The language does offer "bit" as a data type and supports declaring arrays of bits and various alignment options too. But is there more too this? What does "low level" really mean? I can see scope for abstract access to the stack, some operations that might allow stack walking perhaps but we soon get to target specific stuff which is undesirable.
I read this as "the programming language should have means to define and access the peripheral registers with an ease".
Typically the operations for peripheral registers are reading/writing a register, and testing/setting/clearing/toggling a bit or set of bits in the register.
The language should have support for defining bits and bitmasks for the registers, and prevent using a (wrong) bit mask defined for another register.
This whole register access-topic is quite complex, and needs careful analysis to get it right. For example, some registers may be read-only, some write-only, and some register may contain bits that are read-only, etc. It would be a good thing if the programming language had support for expressing these things, and the compiler could check for proper register and bit accesses. At this point I do not have any good ideas for this, though.27. Static analysis: The language would have built-in static analysis tools that can analyze the code and detect potential errors, such as null pointer dereferences, race conditions, and buffer overflows, before the code is even run.
This is good, I've not thought much about this though, so this needs more definition perhaps...
This might be tricky, and I know very little about this topic. However, using compile-time static asserts/checks, and checks/asserts during runtime with preconditions, post-conditions and other checks could help conveying the information how the functions are expected to behave and what kind of parameter values functions are expecting. These run-time checks can be enabled during unit testing, and selectively turned off in the production code. The compiler should be able to ascertain that there are no unwanted side effects when performing these checks.
sublime!
talking about sublime, I checked an old copy of my Dr. Dobb's Journal, and it says ROL and ROR were useful during i386 era for bit-by-bit examining a value in a way that is non-information-destructive.
Kind of bit(x)-test for intel chips
Then it points out something like this. Nice, isn't it?
("Safe, Efficient, and Portable Rotate in C/C++")Code: [Select]uint32_t rotl32a (uint32_t x, uint32_t n)
That's basically where what @Jportici wrote came from
{
return (x<<n) | (x>>(32-n));
}
I'm sure it was well known long before Dr Dobbs.
Now that ChatGPT has been involved in this process, I think we're gonna reach the sublime!
Comparison Chaining
I've been reading about how some languages support comparison operator chaining. Now the grammars of most languages support it, it is a semantic question really.Code: [Select]
if a < b < c > d then
log("Conditions Met.");
This can be interpreted asCode: [Select]
if a < b && b < c && c > d then
log("Conditions Met.");
I find this quite appealing, thoughts?
Comparison Chaining
I've been reading about how some languages support comparison operator chaining. Now the grammars of most languages support it, it is a semantic question really.Code: [Select]
if a < b < c > d then
log("Conditions Met.");
This can be interpreted asCode: [Select]
if a < b && b < c && c > d then
log("Conditions Met.");
I find this quite appealing, thoughts?
it may be that i use too much C but i do not want to think about precedence, even when writing other languages.
So i use parentheses
I probably still use this notation only when writing on paper
dcl counter bin(15);
counter <= 123;
if counter = 321 then
return;
namespace test;
dcl root_ptr pointer;
procedure outer (arg);
dcl counter bin(15);
dcl window bin(31);
if counter = 123 then
return;
end;
end procedure;
procedure rerun (arg);
call s$system.memory.allocate_virgin(10 0000:H); // 1,048,576 in dec FYI
end procedure;
end;
namespace utility.sundry;
// an empty namespace
end;
namespace s$system;
namespace memory;
procedure allocate_virgin(size);
arg size bin(31);
end;
end;
end;
Moderators: please can I stop notifications from this to thread? I've learned my lesson.
Moderators: please can I stop notifications from this to thread? I've learned my lesson.
def devices enum bin(15),
gps = 10,
adc,
spi
end;
def folders enum string(32),
devices = "devices",
logs = "logs,
dumps = "dumps"
end;
def rates enum,
fast,
medium,
slow,
stopped
end;
dcl mydata folders; // dcl an instance of the "folders" enum
<dcl-keyword> <identifer> [multiple other attributes in any order] <semicolon>
type baud_rates enum string(31);
dcl rates as baud_rates;
type baud_rates enum bit(8),
first = 1010 0011:b,
second = 1110 1101:b,
third = 1101 0111:b,
fourth = 0010 1100:b
end;
Moderators: please can I stop notifications from this to thread? I've learned my lesson.See the buttons at the top right and bottom right of the entire thread: Reply, Notify/Unnotify, Mark unread, Send this topic, Print, Search?
If you see Notify, click on it, click Yes, and then it changes to Unnotify. Click Unnotify, and Yes, and no more notifications!
(Even if new posts are made to this thread, it will not show up in the New Replies to Your Posts list.)
No, that does not work. It controls notification emails or something, not "Show new replies to your posts", which I believe it is impossible to disable for a given thread.
So being able to define something as (in an arbitrary language) binary [8\8] would be nice, an 8 bit integer part and an 8 bit fraction part. [...] Is this already a thing, or is it too obscure to be worried about?