A rough, short list in my head:

* multi-threading. In addition to support Java threading, also a background gc thread is required
* dynamic memory management (malloc() and alike). Java objects are heap allocated
* debugging strictly speaking is not a requirement but convinience for developing. But JVM spec does require a management interface, jdb is part of that I belive. Put all specs aside, a debugging mechanism is a must in my opinion, for any programming platform that is responsible and considerate to its intended developers!

Multi-threading for the GC seems a bit weird to me, my impression was that the JVM would mainly own the control flow and thus implement threading itself, including calling into the GC when needed. Is that view incorrect?


I... will shamefully admit to almost never using debuggers, which is probably one reason why it was never pushed on gint's side. x_x

Yes that is completely correct. One can interleave gc in the control flow with no problem. You can even implement Java threading the same way. But a threading architecture is clearer & more elegant and provides more extensibility.





Admin edit: removing double-post: .. Also, a debugging session will probably count on a separate thread?

Ok, I just figured out that gint and Yatis's gint are two related whereas different things, it's the later has threading.

With regard to gint I have some questions, would you please kindly help with?

1. gint has USB driver right? I am very interested in this. USB has the advantage of universal availability (well this is a literal proof of the U in USB) while serial port needs a special cable (that we cannot just buy one) and a TTL converter at the PC end. Can add-ins use USB as freely as with serial port? In my understanding the OS limits it to pre-determined use cases such as USB drive, sw update etc.

2. How to start? Except RTFSC (Read The F**king Source Code) are there some guides or sample projects to learn?

EDIT:

I have managed to setup gint & fxSDK (on Ubuntu in wsl2), and noticed `fxsdk new` created a Hello World. This is where I get started I think. However any extra beginner guides will be helpful.

You have done such a great work!! The toolset is so impressive. Nearly cannot wait to know more about gint API and capabilities. Respect!!

Yes indeed! But after experimenting with it, we eventually decided on a design that allows you to implement threading as a library. Functions from <gint/cpu.h> provide some basic operations (although no context saves yet, that's one of the things we had to merge from his prototype) and you can use a timer to schedule your tasks, switching tasks if you need, etc. You just need to be aware of interrupts.


gint has a basic USB driver, yes. Currently it supports USB 2.0 bulk transfers, but only from the calculator to the PC. This is because I spent quite some time on it and had to catch up on other parts when it became functional. Right now it's third on the TODO list after magically-optimized image rendering and native overclock support.


Since you managed to set everything up (well done btw, despite my best efforts it's not always easy!), you can start with these tutorials. I recommend to simply chuck them by sections through DeepL, as I've consistently checked that the automated translation was almost as good as I'd write on my own. Feel free to ask if you have any questions!


Thank you for your praise. This has been a major project for me and seeing enthusiasm with it makes me really happy.

Will follow the tutorials. May I send you private messages (I just found out this functionality) with questions that I think are not appropriate in public place ? I fear frequent newbie questions deliver no value or make others annoyed..

You can, but I think even newbie questions are welcome. Plus, more activity and new ideas are always well perceived

Hi Lephe,

Bon jour~ I have gone through your tutorial #1. It was a pleasant journey! I have high confidence in gint now if any doubt earlier. Clean API, great tools as well as great tutorials! Well done sir!

Meanwhile, as you have said,



you will merge threading code in to future gint releases right? When should I expect to have it?

I'm glad you like it!


In terms of organization, I usually work on the most requested features at a given time, as these days there is enough demand to keep me busy all the time. The latest TODO list was published at the end of this post; fast image rendering is in progress, overclock progressed a lot yesterday, and so far debugging is the main driver behind USB. I hope I can get the rendering and overclocking stuff done in the next two weeks, so potentially we could look at threading at this time if that's your priority.

But it's not clear to me exactly what you need as far as threading is concerned. What Yatis did was implement context switching (in a way that is stable in the presence of interrupts), and I think we could reuse that. I don't think he implemented threading primitives (spawning/yielding/synchronization primitives/etc) or a scheduler, and even if he did, I'm not entirely clear whether the JVM could use that.

Most programming languages I know (eg. OCaml) are pretty conservative with their GC as it's a major performance concern, and never run it randomly. So my intuition is that with the JVM you'll want to control thread scheduling yourself, for instance by running the GC when allocations are performed. Is that assumption correct?

In any case, any details about your expectations/approach would be very welcome to help me frame a suitable implementation in gint.

Wow you are a fast-paced coder indeed. I guess you have a hot keyboard Please take your time, and stick to your plan, which is already beyond my expectation.

Yes I acknowlege that threading support from OS-level is not a mandatory requirement for JVM, however I prefer to have one, and delegate the hard work to it Some of the benifits are:

- It will make non-VM but supportive facilities like debugging a lot easier to implement
- Fewer work to do to port JVM to different platforms (yes i AM lazy)
- Applications can choose among different scheduling algorithms (preemptive, round robin, cooperative ..), without JVM invoved. Chances are most OSes can provide one or more of them, despite Prizm OS doesn't?

Surely the bottom line is we can always implement threading ourselves, directly in the fetch-decode-execution procedure, and base any further requirements of threading on that. Why not GC with a JAVA thread, just like we need not to create eggs ourselves if we have created chicken?

Looks like Yatis've done the CPU related hard work. I hate (or lack a brave heart) to read the datasheet, study the asm instructions and calling conventions of a new processor.. However higher level facilities such as synchronization locks are hardware neutral thus more feasible for me -- at least we already have FreeRTOS out there!

I will definitely do it on the shoulder of gint -- if I will ever finish it, I hope so.. -- either with your near future release or the (Yatis's + FreeRTOS) combination. This is my thought for now.

Once again, take your time!! You needn't do it for me! In the meantime gint API & CMake will keep me busy for quite awhile I'm afaid.

Cheers!

.. Oh I forgot to answer that: Context saving is the BIGGEST relief for me. That will be sufficient for me to get started. Further threading or sync primitives are bonus.

Alright I see it better already!


Yes exactly! This was my original intuition.


We could possibly implement that, yes. The Prizm OS provides no threading, as this makes little sense on the calculator.


Ok so let's start with this: after I'm done with the rendering and overclocking, I'll grab the CPU primitives from Yatis' project and get them into gint, then prototype a trivial context-switching scheduler to serve as a demo for you. That shouldn't be too hard and hopefully raise it to a high-enough level that you can start from it without worrying about low-level details. Then, we can look at the higher-level primitives and support functions as you go, and if you write some we can surely merge them

Cool! Merci!

I have another question for you when you are here: the gint tutorial game, when switch to main menu then switch back, the status bar appears, and it wont disappear until one of the direction keys is pressed. Did you ever notice that? How are gint add-ins expected to cope with status bar when it's desirable to have it as a part?

EDIT: Do syscalls have their place in this situation?

Yes I did notice it. So what's happening is the procedure to go back to the main menu is a bit complicated. First you need to yield control out of gint and back to the OS kernel (which happens transparently). And then the core problem is that the fx-CG has no way to properly invoke the main menu (I have seen some promising syscalls but they tend to crash).

What we do to get the main menu to show up is to essentially call GetKey() and then use a timer to inject KEY_MENU into the key buffer, this simulating the required key press. That much is also transparent. However, once we get back, then the fx-CG OS redisplays its VRAM along with the status bar and does not give control back until a new key is pressed. gint catches that key press and somewhat gives the illusion that it's in control as soon as you reclick the app icon the main menu, but it's not actually the case.

In general, gint add-ins can't use the status bar since gint uses a different screen resolution (by removing the margins on 3 sides) and does its own rendering + display driving. Ideally you'd never see it, but so far I haven't been able to actually disable it and I don't know of a syscall that brings up the main menu and then gives back control immediately when you re-enter the add-in. It's a bit annoying, admittedly!

Okay... understand a bit. Can we have this status-bar-hiding "effect" visible when the add-in is newly started? So that I can see it as a gint feature rather then imperfection Or it's a reminder for user that "I am back!". Not a good idea maybe

At startup gint takes control immediately, so you couldn't really show it even if you wanted to. I'd rather hide it all the time, which might be possible by looking further into available syscalls (I'm thinking about SpecialMatrixCodeProcessing). But it's not really a priority. People that are concerned with this usually put a "press a key to resume" to screen which blends it fairly well.

Also, if anyone has an idea why ConfigureStatusArea(3) does not hide the status bar after we come back from the menu, I'd like to know. ^^