Here's a question then... would this back-end compiling also work for drivers as well? Say your audio or video driver would then be compiled specifically for your CPU? Having the apps and OS compiled in this way I think sounds like a nice idea considering I myself don't feel like I should have to muck around with a compiler to get an optimized system up and running. It should be able to do it for me without my intervention, but having source for those who want it is just fine.

Quote:

Hahha, woah, woah, woah, relax, It isn't that bad. So I do see a general averseness the idea of a byte-coded virtual CPU like Java. But read carefully, the "cut-the-compiler-in-half" idea, done first I believe by Oberon/Juice, and now by TenDRA, apparently, doesn't cause a slowdown and in fact could cause a speed-up. It works like this:

All compilers, including GCC, have a front-end and a back-end. The front end converts the source code into an intermediate form -- it strips comments, resolves symbols, digests the commands into a more machine-code-like stream, and even performs some optimization. But at this stage, it's a pre-digested mess that doesn't mean anything to any specific CPU. Then the back-end takes over. It translates this code into machine code that the target CPU can understand, doing further optimizations. The "cut-the-compiler-in-half" idea basically works this way. The programmer runs the front-end, but not the back-end, on the code when they want to distribute it. What issues from the front end is captured into a standard format and saved into a file. Then, the user, downloads this onto their own machine and runs the back-end process on their own machine, and runs it. Of course this works invisibly. There is no virtual machine, no just-in-time compiling of bytecode, nothing, so no slowdown. In fact, a speedup. Here's why:

When you download a binary for your AROS box, or even compile one using the current instructions and build system, it creates something that would be happy running on your screaming new Pentium 4, or AMD, but would also be quite happy running on a 486. However, the AMD and 486 do differ (REALLY?? ) YES, REALLY! The AMD has more instructions and for optimal execution, would organize them differnetly or use differnet instructions than a 486, but an executable compiled for a 486 can't take advantage of them (though it will, of course, still run). If your OS does the final back-end processing on your own machine, however, it knows that it's an AMD and not a 486, so will optimize the code production around that chip. True, the final binary will run only on that specific chip -- but if a 486 user downloads the same intermediate code, their back-end compiler will do the right thing and produce 486 machine code for them. All in all, it will result in a faster, not slower, experience than what happens now with AROS.

I still believe that downloading the source directly and compiling it entirely is best -- we have all the tools today to do this, up and running, and remember you can obfuscate it if you need to deal with it in a proprietary way.

Quote:

Hahha, woah, woah, woah, relax, It isn't that bad. So I do see a general averseness the idea of a byte-coded virtual CPU like Java. But read carefully, the "cut-the-compiler-in-half" idea, done first I believe by Oberon/Juice, and now by TenDRA, apparently, doesn't cause a slowdown and in fact could cause a speed-up. It works like this:

All compilers, including GCC, have a front-end and a back-end. The front end converts the source code into an intermediate form -- it strips comments, resolves symbols, digests the commands into a more machine-code-like stream, and even performs some optimization. But at this stage, it's a pre-digested mess that doesn't mean anything to any specific CPU. Then the back-end takes over. It translates this code into machine code that the target CPU can understand, doing further optimizations. The "cut-the-compiler-in-half" idea basically works this way. The programmer runs the front-end, but not the back-end, on the code when they want to distribute it. What issues from the front end is captured into a standard format and saved into a file. Then, the user, downloads this onto their own machine and runs the back-end process on their own machine, and runs it. Of course this works invisibly. There is no virtual machine, no just-in-time compiling of bytecode, nothing, so no slowdown. In fact, a speedup. Here's why:

When you download a binary for your AROS box, or even compile one using the current instructions and build system, it creates something that would be happy running on your screaming new Pentium 4, or AMD, but would also be quite happy running on a 486. However, the AMD and 486 do differ (REALLY?? ) YES, REALLY! The AMD has more instructions and for optimal execution, would organize them differnetly or use differnet instructions than a 486, but an executable compiled for a 486 can't take advantage of them (though it will, of course, still run). If your OS does the final back-end processing on your own machine, however, it knows that it's an AMD and not a 486, so will optimize the code production around that chip. True, the final binary will run only on that specific chip -- but if a 486 user downloads the same intermediate code, their back-end compiler will do the right thing and produce 486 machine code for them. All in all, it will result in a faster, not slower, experience than what happens now with AROS.

I still believe that downloading the source directly and compiling it entirely is best -- we have all the tools today to do this, up and running, and remember you can obfuscate it if you need to deal with it in a proprietary way.

It would be a good idea to make this Datatypes system cross-OS. Perhaps this would interest some Linux developers, and it would help increase the speed of it's developement. This would also bring some apps that would be easier to port. And last but not least, it can also serve as some kind of marketing tool to attract some of those developers to also work opn AROS.

But first we need to write a somewhat detailed paper on the design of the system, ensuring cross-OS is possible. For example, what about the GUI? Custom, or something like WxWindows?

Quote:

I suggest you read the other thread ("Hi & cross-platform OS"). There's a wonderful alternative to using a VM: TenDRA.

I like the idea of extending the datatypes.

There would be no need for plug-ins for the software you are using. No compatibility issues with other programs. Great idea. Each program would act as a plug-in in it's own unique way.
You only load what you need to, as and when required. You could run complex programs such as Photoshop only reduce the memory footprint considerably, Creating your own individual software fitting within the memory constraints of your system.

Nice one.

Quote:

I almost had the same idea, and I think this can be done to a certain point. I see several advantages to such a kind of Object Oriented system :
- No need to write a whole app, just write a tool that applie to a certain type of document.
- Is perfect for Open Source development since it would be easier and quicker to write a tool, and no need to wait the whole app to be in a stable state before beeing useable.
- Superclass of all kind of tools would already exist and there would be no need to rewrite annoying things such as open a window, read/write a file... All you have to do is one task on one particular type of object.
- Provide the user to configure a system that really fit his needs.
- Allow making composite documents (eg. Text document that embed a picture. You edit the text with text tools then click on the picture and it loads imaging tools. Then you can save your work in any format like pdf, ms word, etc.)

I was thinking about starting design of such a system for AROS (and more generally Amiga-like systems) when my Radeon Driver is done (and it's really not at the moment). So, if anyone is interested ... :)

Although it's datatypes that gave me (and you) this idea, they should not be the base of the system but a component of it, as tools would be, because some operation you do with a computer are not file-based (IRC is a good example). Such a system would have to be more generic if you want it to be useful for other things than document creation.

I think the amiga is the perfect platform for this, because the library system could be used for "the atomic executables", and we already have a scripting language : Arexx.

Quote:

NO, NO, NO, NOOOOOOOOOOOOOOOOOOOOOOOOOO!!!
Not that java kind stupid stuff. As an amigan I cannot accept such a slowdown of the system, and such a waste of cpu time. Keep my CPU away from your dirty thoughts

For reasons that aren't clear to anyone, least of all myself, I've decided to go on a freeform fantasizing jamboree about a perfect Desktop OS. AROS is close, but doesn't have everything of course. Here are the ideas that are floating around in my head. I apologize to anyone who might wish they'd stayed there, in advance!

The perfect Desktop OS ---

I like the core AmigaOS/AROS three-way division -- Exec (core kernel), Graphics/Intution (interface, desktop) and AmigaDOS (file system and file management). So lets keep that. So by section:

Exec (core kernel) -- BeOS-like or better smoothness, memory protection, total hardware abstraction, including the CPU (which means either "virtual machine with bytecode" type or "cut-the-compiler-in-half" type CPU abstraction). Orderly hardware and network management, plug-in-play, USB, bluetooth, 80211x, firewire support.

AmigaDOS (filesystem and file management). First of all, no textual information of any kind flows through this system that isn't in Unicode, unless it came from an external source. Filenames, device names, and all names or tags of any kind are named in Unicode. If a language is set, then absolutely no system messages appear that aren't in that language, from the moment power is applied to the device, whether it's French, Mandarin, English, or any other. Case-sensitivity would be Amiga-like in the sense that searching is case-insensitive but creating is case-sensitive. It would be impossible to create two files that differed only by the case of the characters in their filenames (it would be okay if they differed by their tags -- more on this later). Of course this only applies to languages with character case. The filesystem itself wouldn't be heirachial, but would have two concepts for organizing files -- both types would be used in concert -- #1:flat association (a single tag would be associated to any number of files, and any file could be attached to any number of tags) or #2:dependancies (one file is tagged that it is dependant on another file to be useful). This would allow deinstallation of an entire app by simply deleting the main executable, all other associated files would dissapear, except libraries which have other executables which are dependant on them. They would dissapear when the last dependant app does however. Special "system" associative tags would be used for concepts like permissions, executability, and owner. Since a tag can be associated with other tags, groups would be done in this way. Devices would have system tags as well. So it would be trivial to list all files on a specific device, list all files owned by a specific user, and so on. Database like search facilities, wrapped in an easy-to-use file management GUI would exist. Each file could exist arbitrarily over the network, locally, or in ram -- no distinction is made at the user level -- although each file is carefully and automatically tagged depending on its domain.

Graphics/Intuition (interface) -- The old concepts of windows would go away and be replaced by the much more efficient concept of frames and overlays. The whole screen starts as a frame but would subdivide into smaller frames, which of course, can further subdivide ad-infinum. Features like frame-swapping, hiding, and an expose-like finding utility would be there to assist the user. Overlays, which could be sprites, mouse pointers, and other informative over-the-whole-mess elements would exist. Frame-stacks would also exist, in situations where that would make sense. Frames could be made to snap to their smallest or biggest possible size with an easy mouse gesture. Again, hardware independance would be key, with total physical independance of the visual system. Resolution, and to a lesser-extent, color depth wouldn't matter, fonts, icons, and frame frames would be rendered through vector information.

The concept of Datatypes would be extended to its logical Oberon System 3 extreme. No actual apps would exist, but everything would be as atomic as possible. This would allow, for example, opening up a still-frame-picture frame, a .png for example, which would render directly from the datatype. Then, as many graphics editing tools as you wanted could be opened, all editing on the same picture as it sat. Techncially, each specific transformative process (drawing a line, brightening the picture, merging two pictures) would be a completely separate (and very, very small) executable, but of course program authors would organize them into useful toolkits for the user. The user could then custom make their own toolkits as they desired, by dragging buttons from various other programs into a single, newly created button panel. Since the Datatype's API is completely open, any programmer could create a new tool at any time. Furthermore, a generic interface for each tool's output, input, and settings would exist. Simple GUI's for creating your own tools by combining and maniputing the exposed elements (input streams, output streams, and settings) of existing tools would exist, and would be easy even for a non programmer to use, A powerful scripting language would exist to fill in for purposes which required more than that, and the full development environment and source code would be included with each copy for anyone who wanted to go deeper.

Hm. Okay, fantasy over. Did I miss anything?