Reddit Tech VN BotỨng dụng TripOS mới ra mắt trên iOS giúp bạn quản lý chuyến đi dễ dàng hơn! Ứng dụng này tích hợp mọi thứ bạn cần vào một giao diện duy nhất, từ hỗ trợ AI, quản lý ngân sách, lịch trình, thời tiết, lưu trữ tài liệu đến dịch thuật ngoại tuyến. Hoàn toàn miễn phí! ✈️
VertigoOne of the things I constantly worry about with the #Kestrel3 is setting myself up for deliberate attacks against the platform because of my preferred choice of system software.
Besides #Forth, I'm also porting a recent clone of #Tripos called #cintpos. Tripos is a rather contentious OS which, frankly, has directly or indirectly lead to people to write screeds against it. It isn't uncommon for someone to compare it against the more advanced features of Unix and its shell interface.
Scanner implementation of the new RISC-V assembler is coming along quite nicely. Just implemented support for identifiers, decimal, octal, and hexadecimal (unsigned) literals, and end of stream detection. It also tracks line and column numbers.
I made a number of patches to my local copy/repo of #cintsys and #BCPL build scripts. In theory, it ought to build out of the box on any 64-bit POSIX-like environment that runs Bash and GNU make. It will *probably* run on other makes and shells too; but, these configs are not tested.
Awaiting feedback from Dr. Richards on how to best contribute my changes back.
These *might* help solve some of the problems I'm having when building #Cintpos (#Tripos) as well. Again, untested.
Today is going to be another work day for me. Except, instead of going into the office, I'll be doing a ton of laundry and dishes and whatnot.
I know I've said that I'd reconsider making a new stack architecture CPU; however, the idea of making a new CPU optimized for running #BCPL and #Tripos is equally as intriguing to me, and wouldn't be any harder than a stack CPU, really. Especially since I have a somewhat retargetable BCPL compiler ready-made.
Bad idea for today: I wonder if it'd make more sense to implement a processor that interprets the Cintcode bytecode directly in hardware, and then just write a RISC-V emulator in BCPL. #tripos
That moment when you download the latest build of the #tripos (Cintpos) sources, only to find out that the damn thing doesn't build because the Makefile is literally missing almost half of its dependencies' build steps.
I really only wanted the source code for reading anyway. #Kestrel3 's version of Tripos kernel will most likely be written in Forth, leaving only its (pardon the misnomer) user-space to be written in BCPL.
Still, it'd be nice if the build instructions were accurate.
I was studying how #tripos scheduler works this morning. I've never used a preemptive kernel that *didn't* support round-robin scheduling before (AmigaOS supports round robin scheduling).
Tripos is definitely the simpler of the two, by a *long* way, and as long as you are strictly I/O bound, every bit as powerful as with round-robin schedulers.
(Or, put another way, you can have *one* CPU-bound task as long as it's the lowest priority task in the system.)
@EdS I look forward to hacking on it and taking it in my own direction.
Just remember, though: I'm planning on writing it in Forth, not BCPL, so all pointers will by APTRs, *not* BPTRs. That is a significant source of incompatibility with existing #tripos implementations (except BOAR Project's).
Unless you foresee a good reason to use BPTRs? I don't anticipate porting BCPL to the #Kestrel3, but perhaps I can be convinced otherwise?