general question about riscos.

aaaaa

aaaaa

He looks like he know a few things about how computer works

You don’t say.
Acorn, ARM, RISC OS. Round here we’re in the legacy pool.

aaaaa

i don’t get where they got this model from

Read through this: http://www.msknight.com/bbc/manuals/new-advanced-user-guide.pdf

but i don’t see how it is possible to design a system like this with hand written assembly with little team.

Back in the mid 80s, people knew what they were doing and it was generally considered good to do a proper job instead of knocking out endless beta versions.
I guess it helped, also, the very close integration between the guys that designed the processor and the guys that wrote the OS.

And well, the overall design really doesn’t look like something that would be designed to be programmed entirely in assembler.

It was a very different way of looking at using assembler than the 68000, the 6502, the Z80…
You’ll notice I didn’t mention the x86. These were not that popular yet, and with the many horrible attributes of the 8088/8086 to deal with, it would be a while.
Forget any thoughts of OO and such on the early ARM. While there was some Modula2 kicking around, most of the stuff we take for granted today either did not exist (home computers not powerful enough) or they existed but on hardware out of most people’s budgets.

To put it into example, I programmed in BASIC on my A3000, then I went to college and used TurboPascal/TurboC under DOS on a 386 (Windows was fairly new, most stuff still worked under DOS, like the infamous WordPerfect 5.1) and I really thought it was like a step backwards. Sure, the debugger was kind of cool, but the limitation of 64KiB per source, the ass kissing necessary to allocate a largish wodge of memory, the delving through Peter Norton’s bible to work out the right combination of INT calls to do something a simple SWI could manage… About the only thing that was nice about the design of the PC was you could easily get a textual display from low level just by pushing characters into memory (the BBC and RISC OS use graphical display).

I think it was 1992 when a friend of mine showed me his 486 running Windows 3.0 (or was it 3.1 already?) along with Turbo Pascal for Windows. OO features (first introduced in DOS times in Turbo Pascal 5.5) and a proper GUI library. A true IDE. It was streets ahead of everything available for RISC OS at that time. Not to mention the standard FPU inside the 486. Of course Windows was still horrible, but the writing for RISC OS was on the wall. Then came the Internet – I installed Trumpet Winsocket and Netscape 3 Gold and used SLIP or PPP to connect to the university’s dial-in server (with 2400bps!). RISC OS had…nothing. Buying the TCP/IP suite was prohibitively expensive, even the PPP driver cost money.

Still preferred RISC OS :-)

a proper GUI library. A true IDE. It was streets ahead of everything available for RISC OS at that time.

Even if you just used Microsoft Excel, a quick press of Alt + F11 and you have a full blown IDE. VBA might not be a proper OO language but the IDE beats anything on RISC OS. Shame that a consumer/business product has a better developer interface than anything on RISC OS.

And yeah, I can’t do low-level code, but I do like to program using VBA and VB.Net. So easy to use. If we had something similar on RISC OS it would be soooooo good.

Surely to give a breadth of options where you don’t need the speed of bare-metal coding, a decent JVM is what’s required? From there, you’ve any number of languages that can make use of it and a number of IDEs ready-made, or the tools to make an IDE.

Then, if you want an OO scripting language, look at the likes of Groovy, for example – java-like, does OO and can make use of compiled java libraries. Get that working and suddenly you’ve got a massive library of pre-existing work to play with.

aaaaa

aaaaa

Oracle did a lot of work to provide an optimized Hotspot JVM for ARM. Unfortunately, this is only a small part of the work needed for a RISC OS port. The libs needed for a full JRE are numerous. And the Java 2D stack is difficult to optimize – have a look at the various demos by Gerrit Grunwald (http://harmoniccode.blogspot.de/ – he has even more ARM development boards than I have), the performance differences between the various hardware is staggering – without hardware-accelerated graphics rendering, something like JavaFX is incredibly slow, even if it goes directly to the framebuffer without going through X.

If you want to provide an IDE for RISC OS based on Java, you face additional problems. Netbeans uses Swing, and Swing also needs a fairly optimised Java 2D stack. Eclipse uses SWT, which is basically a wrapper for native UI controls. But many of the controls are not available on RISC OS, so apart from providing an SWT implementation, you also need to code various controls from scratch.

aaaaa

it could be done with something close to basalt

It is kind of you to think this way, but Basalt is BASIC, and it is a kludge to extend the usefuleness of the ancient interpreter, although I happen to think it is a reasonably neat kludge

Do you actually mean to refer to the Toolbox? ;-)

if for example component should be programmed with a basalt thing, is if several instance of the component has to be loaded

I cannot make sense of this. A component is an object that is aggregated to another. In the Toolbox that is a gadget or menu item, and these do not exist independently.

it would be hard to handle to have only a single instance of the program loaded in memory but with several ‘instance’ of the data it manipulate,

For the Toolbox it is quite possible to have a single template and create several objects from it, each with its own data. A multi-window editor would do that.

if several instance of the component has to be loaded, with different ‘resources’, kinda like the workspace of the modules,

You do know that a single module can have several instantiations, each with its own data, but sharing code?

aaaaa

aaaaa

aaaaa

aaaaa

aaaaa

In the principle, what basalt do is not far from what a dll loader would do regarding the relocation, but it’s not made to be shared code like an OO library/component.

Basalt has nothing to do with this. Please stop using the name in this context.

aaaaa

aaaaa

Basalt is something to add extension to an existing language by modifying some data in the code at load time.
A dynamic loader add extension to an existing lnaguage by modying some data in the code section at load time.

Your description would equally hold true for a load-time binary patch, ditto for Jon’s JSAPP and Aemulor which no doubt load and “sanitise” older software by replacing “unsafe” code with instructions to call handlers to deal with the situation.

If you make the de4scription vague enough, lots of things apply.
(^_^)

aaaaa

aaaaa

aaaaa