Talk:Linoleum (programming language)
From Wikipedia, the free encyclopedia
Hello. Some time ago I realized Wikipedia had an article about L.in.oleum. I have no precise idea who created it and kept it up to date, but I assume it was one or more members of anywherebb, to which I'd like to say "thank you" as a first thing. Now, as the final release of version 1.2 is getting closer, and seeing that request for help at the top of the article, I decided to create an account and... effectively try to help. However, I'm not sure my english meets Wikipedia's standards, so I'd prefere to drop notes in this "discussion" page from time to time, rather than touching the contents of the article itself, assuming someone might find these notes and eventually fit them into the article. That said, a first thing I might do now is mentioning what's going to happen to this programming language with its next release, and here we go...
The most relevant change will concern the coding style of libraries and programs' sources. L.in.oleum has pretty flexible syntax rules, and the compiler can tolerate pratically any layout for the source code. But a human attempting to read and understand the source code would find considerably helpful to find a common style. So I'm coming up with something similar to what OpenBSD developers called the "kernel normal form", ie. an agreement on how to dispose contents in a source code's textual layout. To achieve what, in my humble opinion, would be an elegant and comprehensible style, I've been mostly focusing on two steps. First, I've implemented a few "new" constructs into the 1.2 compiler core library. Second, I've been using those and a simple set of rules to restyle, and sometimes refactor, all of the libraries and example programs found in the package.
For example, upto now, there have been two ways to make a call to the isokernel command parser: writing "=> [isokernel];" or more simply, "isocall;". With the next release it will be possible to further simplify the operation: the isokernel call instruction will be represented by a single dot, a period, prepended to any other instructions, as in: ". [timer command] = read counts;". Used well, this way to write an isocall might make the code more readable, other than eliminating a line. Of course "isocall" and generally the former ways to do this will still be supported by the compiler, for backward compatibility but also because sometimes you may want to witheld one such call, while loading more than one command units, to then have the isokernel perform all the requested commands in a single call (note this has always been possible).
Further efforts were then made to improve the coherence of the whole thing: libraries, subroutine names, and certain variables and constants, had their names changed to look shorter and less cryptic, and generally more coherent with the rest of them. Where applicable, I've strived to keep symbol names in local namespaces to avoid collisions among libraries (formerly it was impossible due to the presence of a single namespace).
Then I've made an important decision to include a couple new, very important libraries, that bring a bit of object-orienting in the sources, but trying to not betray the low-level standpoint of the language. One of the libraries, "gen/mgrab", will control dynamic heap allocation using a locking mechanism, and is managed via bidirectionally linked lists of handles, which might result in rather good performance (all operations, except garbage collection, don't require any loops). The other library will be "gen/lap", for "Library Arguments Packet", a way to define and save on the stack a set of arguments and return values concerning a library's workings or, at programmer's choice, those of single subroutines in a library. The use of LAP objects will involve stacking such packets before loading arguments for a subroutine call, and restoring them after the call. This will avoid interferences between libraries calling other libraries' functions in possible concurrency with the client application, other than providing facilities to use, design, and reducing the chance of troubles while modifying existing libraries. The fact that packets have to be restored from stack, rather than just discarded, theoretically makes this method slower than "stdcall", but there's a balancing factor: being not managed by the compiler, the programmer can choose wether it's relevant to stack the packets or not for a given call, and if the operation would be redundant, as it often happens in repeated calls to a same subroutine, witheld the whole operation. In a nutshell: these features, aimed at simplifying the programmer's work when a project's complexity grows, were not implemented into the compiler, but as libraries, so that the programmer retains full control over them.
Apart from other minor additions, there will be a truly important one: a specially crafted run-time module for the PC BIOS. Run-time modules were assumed to exist so that cross-compilation is possible through different platforms, but at a certain point (October of last year, to be precise) I thought that a microkernel could be designed (in native assembly, of course) to match a machine's BIOS rather than its operating system, and that's what I've suffessfully created: a run-time module that, if linked to the application's code and streamed to a bootable media (starting from the first physical sector, where the partition table lays), can boot the machine and execute its associated application, which I'm in this case calling a "core application". What's the point? Well, if in a core application, written in L.in.oleum just as any others, a file system and a system shell is implemented, it could then play the part of the kernel of an operating system which, apart from the aforementioned short microkernel, could be entirely written in L.in.oleum. So far, I've successfully tested several applications, which I used to compile and run on Windows, and verified that superVGA display (VESA-based, taking advantage of LFB indexing) provides perfect support to what the application knows as its "display window". Mass-memory access is quite nicely implemented with a byte-oriented addressing scheme, and a table of pointers is defined and managed to provide remote entry points for future drivers and resident software. The microkernel also includes a keyboard driver dealing with ports 60h/64h: that wouldn't be the duty of a microkernel, but... at least minimal input support might really be necessary. Keyboard mappings will have to be interpreted by the core application, by looking at what it calls the L.U.C.K. table.
Last but not least, the L.U.C.K. table itself has been re-designed to acknowledge the status of any given keys (including international layouts, japanese and thai keyboards), so that a core application (as well as any others, including those running under an existing operating system) can monitor the keys in real time and produce appropriate keystrokes in multiple circular buffers for each dependant application. The library to do that easily will be included as "gen/ekey". As you can see from the actual package, it formerly was called then "enhanced keystrokes management library". Well, in next version it will be renamed to "entire keyboard management". The iGUI user interface and other widely used pieces of code have been already refit to use that library, which is tied to the sole informations retrieved from the L.U.C.K. table. So, if on one side you'll have to forget comfortable commands like "get console input" (but initiating an ekey session won't be difficult anyway), on another side you'll get much more control on any kinds of keystroke, except those few intercepted by an underlying operating system, and at the same time the whole environment will earn independence from the OS. Of course, "gen/ekey" provides subroutines to easily load and save keyboard layouts, a collection of which could also be made part of an application's stockfile, for the user to simply select the intended layout by means of a configuration menu, or dialog box, or whatever.
Phew... now, should anywherebb people come and see this, I'll also drop a note about me: I'm fine, everything's well, I have been absent because of several things that kept me busy in "real life". I'm still working hard to improve L.in.oleum and I'm still intentioned to complete Noctis when this programming environment will be capable of doing... what I need for that important project. I'll probably come and say hello soon, although my idea was that of coming back with the new L.in.oleum ready. I'm still lacking a few examples and libraries to review, and given the massive amount of changes, I would like to write a wholly new set of help files (to replace the outdated "docs" folder). But I couldn't resist dropping these notes here to let you know that I still care, and that I didn't abandon anything or anybody. I'm sorry for the long absence, as always. After all, you see, a 56K modem and a connection that comes and goes aren't a good incentive to stay on the internet nowadays...
Oh, and thanks again for maintaining this article on Wikipedia!
Sincerely, Alessandro Ghignola
--Alessandro Ghignola 07:43, 28 January 2007 (UTC)
[edit] Get Back To Where You Once Belonged...
<quote>After all, you see, a 56K modem and a connection that comes and goes aren't a good incentive to stay on the internet nowadays...</quote>
Alex:
I used to have have a 56K modem... with AOL on top!... it verily suckethed mightily, but I did check in. You have throngs of worshipers missing you (OK, me, RJ, Xeno, PeterPaul, Gazer, Arrowgrab, Cryo, SL, and Chad (who's rejoined us), and of course, Magnulus) and also a throng of veterans and neophytes that would like to speak with the "MASTER"! So:
GET YOUR FANNY BACK HERE, MISTER!!! (please?)
Skinnymon 01:16, 10 March 2007 (UTC)
[edit] The claim about speed
"claims to be twice as fast as C/C++."
first the note could and shoul link directly to the supposed "evidence". As it is now, downloading and unpacking an archive is needed, just to understand how the claim is supported. Then you discover that this is based on trivial optimizations (that most compilers can do) on a very small toy program. I'm surprised that such claims can find space in wikipedia's db. If no-one objects I'll proceed to delete. --82.53.64.40 (talk) 20:54, 23 December 2007 (UTC)
[edit] Twice as fast...
...as an old form of unoptimized C, in fact. At that time I was often seeing my Borland compiler v3.1 do absolutely inefficient things, especially while working in MS-DOS' 20-bit real-mode environment. For instance, apart from rarely spotting evident optimizations like that I was basing upon, its management of array based on "far" pointers was indeed catastrophic from the point of view of execution speed: it used to re-load segment registers inside inmost loops. That "claim" dated back in the mid 90's and would be, in fact, currently very outdated. Since those years, C and C++ compilers highly improved above such a naive example, and manage such a redundant load without problems. At the time I was providing that example, that simple instance was effectively rather easy to witness.
So it's alright to delete the claim, thank you.
The article would sure need expansion, updates, and removal of other more or less unjustified claims, which I'll probably be willing to do in the near future (providing the article as a whole will still be here), since I'm not far from completing development of "branch 2" of this language. It will be a quite different "world" from the current, very old branch, and will address a very wide amount of issues, ranging from details to massive problems concerning internal coherence, code organization, readability, asbtraction, and reusability.
As of the "notability" principle, that's a topic for Wikipedia's people to deal with, and I won't argue or claim anything in favor of keeping or deleting this article, and/or about the policy behind such a decision in general; I can however hope there will be a day, relatively soon, when there will surely be good reasons to keep an article about my language. But I need some more time. Alessandro Ghignola (talk) 17:16, 19 January 2008 (UTC)
