But the issue would be that if you included that statement in the language, and people start using it, even when it was not really needed. Any architectures, that DON'T have a 64 bit, bit count instruction, may run that instruction very inefficiently.
Although you are right, that some programmers, might have understood it. It should have been written clearly enough so that all or nearly all, programmers, could understand it.
C does support embedded assembly language though, can one go any lower?
You raise some good points. But your example using a = a - 2; is something done routinely, even in C. You'd need to show a better example of an abstract idea that's "low level" and that C doesn't support, that you consider would be too low level.
I didn't explain the a = a - 2 section very well.
Another (possibly better) example, would be a low level instruction, which counts how many bits in total, are set (1), in an unsigned, 64 bit integer. Which is useful for some types of algorithms and program types.
So the high level language, could include a low level statement, which counts up the bits set count, works in only 1 CPU clock cycle (because the initial CPU architecture has such an assembly language instruction), for the current CPU architecture, and so runs very quickly.
But the issue would be that if you included that statement in the language, and people start using it, even when it was not really needed. Any architectures, that DON'T have a 64 bit, bit count instruction, may run that instruction very inefficiently.
There are faster methods, but essentially the function would be performing something like:
// Code vaguely based on Pascal
// Count the total bits set in variable x
bit_count = 0;
for bit = 0 to 63 do
begin
if x and 1 == 1 then bit_count++;
x /= 2;
end
There are faster algorithms.C does support embedded assembly language though, can one get any lower level than that?
That is an interesting question. Computers are getting rather complicated these days, because as well as the CPU which processes conventional instructions. There can be various other sections (System on a chip, SoC), such as AI/Machine learning accelerators (technical names can vary), hardware encryption, video encoders/decoders. Even finite state machines (FSMs), FPGAs, the list these days, seems to go on and on.
So I suppose it depends on ones definition. But anyway, technically speaking some of these SoC (names can vary), features, can be at a relatively simple/low level (lower than standard double floating point or 64 bit integers), but typically, it is done at incredibly high speeds. Compared to the main/normal/standard CPU instruction set.
If you run code that uses these intrinsics on hardware that doesn't support the popcnt instruction, the results are unpredictable.
dcl Substr builtin;
dcl Sqrt builtin;
dcl Offset builtin;
dcl Popcount intrinsic;
dcl Emit intrinsic;
dcl Prefetch intrinsic;
Long thread, so I have not read the entire thing. I will say that anytime you are working close to the metal, or even just controlling things, Forth is an excellent choice. Yet, I haven't seen it mentioned very much here.
Forth is my go to language for any programming I do outside of a spreadsheet.
Why are people not more interested in Forth? Is it just a matter of it being so different from languages like C?
C does support embedded assembly language though, can one get any lower level than that?
Long thread, so I have not read the entire thing. I will say that anytime you are working close to the metal, or even just controlling things, Forth is an excellent choice. Yet, I haven't seen it mentioned very much here.
Forth is my go to language for any programming I do outside of a spreadsheet.
Why are people not more interested in Forth? Is it just a matter of it being so different from languages like C?
I'm interested in many languages, I admit to knowing very little about Forth, I read a lot about it years ago, it was used early on when MCU's came out in the 1970s.
So tell me about Forth, what do you like about it?
Long thread, so I have not read the entire thing. I will say that anytime you are working close to the metal, or even just controlling things, Forth is an excellent choice. Yet, I haven't seen it mentioned very much here.
Forth is my go to language for any programming I do outside of a spreadsheet.
Why are people not more interested in Forth? Is it just a matter of it being so different from languages like C?
Why are people not more interested in Forth? Is it just a matter of it being so different from languages like C?
Forth has weird conventions and mechanisms.
I prefer PostScript. It is much improved over Forth, clearer to read, better data structures, and more dynamic by default, though you can "bind" things for speed when needed.
Forth has weird conventions and mechanisms.
I prefer PostScript. It is much improved over Forth, clearer to read, better data structures, and more dynamic by default, though you can "bind" things for speed when needed.
sectorforth, see here:
https://github.com/cesarblum/sectorforth
Fits the entire Forth system into a tiny, single 512 byte sector (of a floppy disk, I think). Which shows the power of both assembly language it is mainly written in, Forth, and some peoples determination, to do things, just because they can.
That is so small, you could fit it into just 8 of the 16 or 32 registers of an AVX-512 equipped processor. Call it just 25% of the AVX-512 accumulators/registers, or an even lower percentage, if you include the mask registers.
How long would it take, to create a Postscript system, complete with all its 400+ commands/instructions (an average of a byte or so, for each one), to fit into a single 512 byte sector?
I think for some new programming languages. Forth's potential, high efficiency in some areas, and the fact that much of it, is actually written in Forth itself, makes it interesting. Because it allows final end users (programmers), to freely extend its functionality, as if it was part of the original interpreter.
But as suggested in quote, PostScript, seems interesting to consider as well. Thanks for mentioning it. I seem to very strongly associate it with Laser Printers, rather than seriously considering it as a programming language, for various reasons. Also, I consider GhostScript, a rather unreliable and buggy way of trying the language out. At least it (GhostScript) was (rather/very buggy), a long time ago.
C does support embedded assembly language though, can one get any lower level than that?
These bit patterns can be emitted directly by the compiler without using an assembler.
512 bytes is very small, even for a Forth. Are there no additional word definitions that get loaded as source? Source compilation is so fast, that systems often have just a core in binary, and load the remainder from source.
I've wanted to try it out for some time, but been put off, because you have to sort out some kind of 386 system (e.g. an emulator), to try it out.
Looking at the hello world, example program. Here:
https://github.com/cesarblum/sectorforth/blob/master/examples/01-helloworld.f
It seems there are only 8 primitive words (see readme file for more information, sorry, I called them functions in my earlier post, I tend to call things functions or procedures, or even subroutines, even if the language prefers other names). So the hello world example program, defines a very large number of relatively primitivefunctionswords, in order to make the required program.
In fairness, 512 bytes is rather tight to fit a full (ALL) Forth word, system into. But even so, to have enough of a Forth System, to make a usable entity, is still very impressive!
E.g. The hello world program has definitions, such as:Quote\ stack manipulation words
: drop ( x y -- x ) dup - + ;
: over ( x y -- x y x ) sp@ 2 + @ ;
: swap ( x y -- y x ) over over sp@ 6 + ! sp@ 2 + ! ;
: nip ( x y -- y ) swap drop ;
: 2dup ( x y -- x y x y ) over over ;
: 2drop ( x y -- ) drop drop ;
So it is sort of cheating. But it also shows the expressive power of Forth, rather nicely.
QuoteThese bit patterns can be emitted directly by the compiler without using an assembler.
emitted how? By inline asm DC?
If the machine layer is not awere of them and they are emmited as "raw" data, then it's a trick
Sure it works, but it's an hack
Does not pass QA
Makes ICE confused
Makes the source dirty
Makes the compiler unable to understand what's going on
Makes the source not portable
Opens doors to undefined run time behaviors
How long would it take, to create a Postscript system, complete with all its 400+ commands/instructions (an average of a byte or so, for each one), to fit into a single 512 byte sector?
Also, I consider GhostScript, a rather unreliable and buggy way of trying the language out. At least it (GhostScript) was (rather/very buggy), a long time ago.
I don't know of any PostScript tools that are generally available for embedded systems. Would using PS on an ARM with 16 kB of Flash even be possible?
I don't know of any PostScript tools that are generally available for embedded systems. Would using PS on an ARM with 16 kB of Flash even be possible?
Of course. Why not? It's very similar in complexity to Forth, and much simpler than, say, Python or JavaScript, both of which have small microcontroller implementations.
PostScript works best in a non-interactive batch processing mode.
MCLK_Enable <= ( MCLK_Divide = 0 );
BCLK_Enable <= ( BCLK_Divide = 0 );
LRCK_Enable <= ( LRCK_Divide = 0 );
: test ( MCLK_Divide, BCLK_Divide, LRCK_Divide -- MCLK_Enable, BCLK_Enable, LRCK_Enable)
0= rot 0= rot 0= rot ;
MCLK_Divide 0= rot DoSomethingMCLKWithTheResult
BCLK_Divide 0= rot DoSomethingBCLKWithTheResult
LRCK_Divide 0= rot DoSomethingLRCKWithTheResult
ICE??? If you need an ICE, your program is far too complex.
You use a lot of nasty sounding adjectives. Where have you been working, porn web sites?
Calling it a trick or a hack is silly. I designed a bit slice processor as a DMA controller for an array processor (the supercomputer of the 70s). I wanted to use some instructions that I created, which were not part of the assembler by default. I added them. QA didn't complain. I just had to document it.
QA didn't complain. I just had to document it.
QuotePostScript works best in a non-interactive batch processing mode.
This is the exact opposite of Forth... well, I shouldn't say opposite. Forth handles batch mode just fine. But the interactivity of Forth is a powerful debugging technique.