The great thing about having a light website is that its fast. Learning HTML and PHP is a great way using a website. When will we see a release for you OS?
Well, I think you meant that, and we must stress "seems" Although you're wrong about optimisation, because compilers can do a really good job with high level languages (just check out gcc's optimisation flags). To my experience one has to be a really skilled programmer to come up with a better Assembly code than the generated one (but it is not impossible). The main reason for this is that compilers do micro-optimisations, while a talented and experienced programmer can also do algortihmic and macro-optimisations. Unfortunately most programmers never learned how to do that.Aran wrote: ↑Fri Jan 25, 2019 8:21 pmit is true the assembly seems limited because it does not bring all the possibilities of a high level language like Python. But we know exactly the code that is generated. An assembly instruction is a code directly executed by the machine: we can not do more optimized.
I think you're right, but for the wrong reason. Assembly also needs compilation, and you can write an USB driver in C. Interrupt handlers are trickier, it is often more benefitial to have a small Assembly wrapper than using obscure C attributes like "interrupt" or "register".And this is necessary when you want to be at the ready of the hardware when designing a driver such as USB, or management of processor interrupts. C is a low-level language, so close too, but I dismissed it because the programming environment is heavy, and requires compilation.
Now that's a unarguable reason Fasm is the best Assembler ever, period. (And I say that with more than 30 years of experience with masm, tasm, nasm and gas).Nothing is easier with FASMARM https://arm.flatassembler.net/. We modify its code, we compile in a few seconds, and we can send it on the Raspberry for testing.
And much much more. This will blow up your mind: Object Oriented Assembly. Fasm can do all of that stuff and more, check out "virtual" directive and it's friends too.Moreover with a little rigor, I manage to program in a structured way. And finally we can do a lot of things similar to C, such as structures.
Yep, like I learn a lot from bzt and the others who have done baremetal.Hi Gavinmc42,
Well, I'm learning a lot of terms with you
.On September, 2011 OpenVG working group decided not to make any regular meeting for further standardization. However, working group decided to continue maintenance and promotion of OpenVG 1.1 specification.
[Nothing has happened on the spec in 7 years tells a story/quote]
No need to change, it's perfect as it is
For 2D GUI it is ideal, simpler than OpenGLES.
I whipped up a LCARS style interface in a few hours just using rects, rounded rects, circles and text.
Simple touch screen interfaces for single purpose use, perfectly fine.
Auto-scales on displays so no counting pixels.
I am now busy collecting Orville screenshots as I like the colour scheme.
Have to learn the path and curve stuff to do proper lists that are more optimized.
People forget the VC4 is an old design so code that was designed at the same time is the proper code.
Of course if it had a VC5 then Vulkan would be my choice.
Can Vulkan run on VC4?
For an OS that would be better but would it be fast enough?
So single purpose OS or general purpose OS?
Lots of multipurpose OS's, we don't have as much choice for embedded OS's.
Most are old and not good enough for graphics, that has been changing recently.
Well Pi's only have OpenGLES hardware but I'm running an OpenGL Desktop.VC4 can't do full vulkan it requires GLES3 hardware.
With the rest of the spec emulated in software and why the performance is down.Gavinmc42 wrote: Well Pi's only have OpenGLES hardware but I'm running an OpenGL Desktop.
Yes but almost everyone has deemed it isn't worth doing because it will be slow, so you need someone who has a reason.Gavinmc42 wrote:Just because it has not been done does not mean it will not be done..
The CortexA53 is designed to co run 64 bit and 32 bit OS and apps you simply need to start it in 64 bit mode.Gavinmc42 wrote: GCC 6.3, Clang 3.9., Rustc 1.24, FPC 3.0.0, two versions of each, aarch64 and aarch32.
I can now compile for 32 and 64 bit Pi's perhaps even at the same time
Ok, so they are not the latest versions but I am trying to get my head around this.
Almost any C compiler for the Pi can act as an assembler along with all a battery of GNU assemblers themselves there is no shortage of options. You lost me with the significance of flatassembler. On any GCC 64 bit compiler then "gcc -m32-bit" will force it to compile 32 bit codeGavinmc42 wrote:I think all those compilers have been known to make baremetal code for Pi's, one left?
The Pi 2 and 3 do support OpenGL through an experimental driver. The driver is far from production-ready, but it does provide hardware acceleration through the VC4 GPU.
Nice list, but I think you forgot two important items:Aran wrote: ↑Sat Feb 02, 2019 11:00 amIndeed before creating the elements that interact with the user as a web browser, you must already have the basic components of the system. I published an article about this, which lists all the essential basic modules : here.
But it must be said that a calculator is a must have, which is easy to make compared to the implementation of the wifi protocol
I think I may have been unclear a bit. I'm not suggesting a full-blown libc, just a minimal wrapper library one can link (or with fasm more like include) and use as "BL fopen" instead of "SVC 0x1234" for example.LdB wrote: ↑Sat Feb 02, 2019 4:08 pmWhile I definitely agree with bzt on point 1, on point 2 I am going to suggest that is very linux and single core centric answer.
However it is not worth getting into until you start writing a multicore kernel and there are a number of elegant alternatives.
Basically you will need your system call load to be balanced across all the cores so such a simple system call mechanism can lead to other problems. You will also require communication between the cores as some of the kernel code must be sequential even though running in parallel on different cores. Anyhow that is for way down the track.
Yeah, something like that. TBH since fasm is so capable with macros, one could create "spideros_fopen" mnemonic as well in that header, it does not need to be a classic library. Good point! "Another abstraction layer" is the proper phrase.For now I would simply say you need another abstraction layer as point 2 and leave it at that.
I don't believe this is true. Because:An assembly instruction is a code directly executed by the machine: we can not do more optimized.
This is clearly not true. As demonstrated by the fact that pretty much all operating systems are written in a high level language. Only a very small sprinkling of assembler is required in odd corners.this is necessary when you want to be at the ready of the hardware when designing a driver such as USB, or management of processor interrupts.
C requires compilation. Assembler requires assembling. Yes perhaps a C compilation takes a bit more time but really, it's hardly anything. And think of all that optimization it is doing for you.C is a low-level language, so close too, but I dismissed it because the programming environment is heavy, and requires compilation.
The most fun I had programming in assembler for decades was for the Propeller MCU from Parallax Inc. 32 bits and 8 cores. Sweet. But with limitations that make assembler essential.I thought to be the only extraterrestrial to dare to program assembly : happy to see that this is not the case
Yes compilers are variable but that thread shows that variability between languages and even small algorithm changes have a much bigger effect on performance than specific C compilers. My take away from that thread is that it's amazing how good they are!Compilers are variable, results are in a long post on the Off Topic thread about Basic