[Info-vax] VSI: "Official 8.4-1H1 Launch"

[Stephen Hoffman]

On 2015-06-05 19:47:50 +0000, Jan-Erik Soderholm said:

> JF Mezei skrev den 2015-06-05 20:10:
>> On 15-06-05 07:45, clairgrant71 at gmail.com wrote:
>> 
>>> VMS_LOADER.EFI is written C and reasonably standard for any platform.
>> 
>> is VMS_LOADER.EFI called by EFI with arguments that point to where the 
>> EFI routines are located so VMS-LOADER.EFI can call them ? Or is there 
>> some equivalemt of a shareable image with transfer vectors to the EFI 
>> fixed memory locations ?

So you're looking at how an EFI bootstrap works, at a detailed level?  
OK.  EFI has a boot-time environment with rather more capabilities and 
— once the operating system has booted — transitions into a more 
limited run-time environment, and there are callbacks into EFI 
available.   This transition is intended to reduce the memory footprint 
of EFI.   The EFI specs are at:
<http://www.uefi.org>

>>> primary VMS loader IPB.EXE and it is also mostly C with a bit of assembler.
>> 
>> Wow, I didn't expect to see C used at such a low /early step.
> 
> I do not follow here. C is used in microcontroller embedded 
> applications where there isn't even any operating system between the 
> hardware and and C-application. Using the right compiler there is 
> (close to) nothing beeing done in assembler that cannot also be done in 
> C.

Ayup.  It's also possible to combine the two, and to write assembler in 
C, with many compilers.  OpenVMS Alpha can do this, as the bozo that 
wrote this example clearly showed:

<http://h71000.www7.hp.com/wizard/swdev/alpha_implver_amask_features.c>

Alas, the OpenVMS I64 C compiler didn't ever get support for inline 
assembler, either; just the built-in stuff.  I don't know off-hand if 
the C compiler used for IPB can do this; that particular module 
operated (operates?) across both OpenVMS source and build environment 
and the EFI development environment, which made it (at least at one 
point) somewhat unusual to build.

As was mentioned, embedded C code can target and can run on bare iron.  
As for the environment that the OpenVMS EFI bootstrap-related bits are 
working in, EFI is an operating system by any definition, and what's 
available is rather past the primitive environment that an embedded 
application inherently has to deal with on bare iron.  For an example 
of the EFI environment:
<http://labs.hoffmanlabs.com/node/563>

>>> Not emulators but VMs. We need to run directly on x86 and as a VM guest 
>>> and we plan to take advantage of the debugging environment of KVM 
>>> whenever we can along the way.
>> 
>> Cool. So VMS will be available on VMs right off the bat if you are 
>> developping it on them.
> 
> That certenly makes the hardware selection process easier, since you 
> "only" has to select a hardware that runs KVM.
> 
> Now, you do get a second platform (OS) with its specific sets of 
> patches and so on.

Ayup.  Same complexity as arises with emulation, or app stacking or the rest.

Hmmm.  (*ponders whether KVM will boot under OS X using 
virtualization... KVM is built on libvirt, and libvirt is an option for 
OS X via homebrew, so...*)


-- 
Pure Personal Opinion | HoffmanLabs LLC