I spent time on google trying to find articles about OS development
using HLA but i did not find anything useful. Does anyone have ever
read an article about this ?

HLA is not directly compiled, but it generates MASM assembler instead,
but i need to know if some people tried to use this generated code for
OS development, to have an idea of if it is possible.

"NewbiZ" asked:

> I spent time on google trying to find articles about OS development
> using HLA but i did not find anything useful. Does anyone have ever
> read an article about this ?

Never heard and hardly ever will :)

> HLA is not directly compiled, but it generates MASM assembler instead,
> but i need to know if some people tried to use this generated code for
> OS development, to have an idea of if it is possible.

OS development needs a tool which is able to create mixed 16/32-bit code.

AFAIK HLA converts its source to GAS/MASM/FASM to compile it then there.
You can use GAS, FASM or NASM or even MASM without this detour,
because all these famous LIBs will not fit in an new OS anyway.

__
wolfgang

NewbiZ wrote:
> I spent time on google trying to find articles about OS development
> using HLA but i did not find anything useful. Does anyone have ever
> read an article about this ?

There are a couple posts to the Yahoo AoAprogramming group on the subject.

> HLA is not directly compiled, but it generates MASM assembler instead,

This is no longer true. (it *will* still optionally produce Masm code, 
but check the legality of using Masm for your OS)

> but i need to know if some people tried to use this generated code for
> OS development, to have an idea of if it is possible.

Not very "suitable". It won't do 16-bit code at all, so forget about a 
bootsector or "transition" (to pmode) code. You'll have to use GRUB or 
something (often recommended anyway).

The thing that makes HLA "special", besides the not-Intel-not-AT&T 
syntax, is the libraries. Port the library to your OS, and it might be 
useful...

Best,
Frank

On Dec 9, 3:19 pm, NewbiZ  <spamt...@crayne.org> wrote:
> I spent time on google trying to find articles about OS development
> using HLA but i did not find anything useful. Does anyone have ever
> read an article about this ?
>
> HLA is not directly compiled, but it generates MASM assembler instead,
> but i need to know if some people tried to use this generated code for
> OS development, to have an idea of if it is possible.

As long as you write your boot loader code with a 16-bit assembler
(i.e., not HLA), everything else could be written with HLA.  You will,
however, want to take a look at the following article:

http://webster.cs.ucr.edu/AsmTools/HLA/HLADoc/HTMLDoc/DoingUnits.html

"NewbiZ" <spamtrap@crayne.org> wrote in message
news:2235b6de-2ef6-4ad9-bf32-279e04505fa1@s8g2000prg.googlegroups.com...
> I spent time on google trying to find articles about OS development
> using HLA but i did not find anything useful. Does anyone have ever
> read an article about this ?
>
> HLA is not directly compiled, but it generates MASM assembler instead,
> but i need to know if some people tried to use this generated code for
> OS development, to have an idea of if it is possible.
>

You're going to have the same problems with using HLA for OS development
that you'd have using a C library for OS development.  Basically, you need
to determine which parts of HLA are OS dependent and OS independent.  OS
independent parts can be used immediately, while the OS dependent parts
would have to be ported.

1) any function which uses an OS dependent function (calls Linux, Windows,
BIOS, DOS, etc.), won't be useable as is.  e.g., functions which use a) file
input or output or b) memory allocation or deallocation.  File I/O sometimes
includes functions you wouldn't expect to use file I/O, e.g., console text.
If you want or need to use them, they'll have to be ported to work with your
OS, or you can write your own replacements.   C based OSes typically write
their own replacement for file I/O based printf(), e.g., kprintf().

2) any function which uses cpu instructions whose usage conflicts with the
your OSes layout for memory, memory protection, paging or not, or code
execution privileges, won't be useable as is.  e.g., use of lgdt to set a
GDT different from your OS, lidt to set an IVT or IDT different from your
OS, enables paging but OS doesn't use, etc.

3) any function which uses a privileged instruction won't be useable in less
privileged code.  e.g, use of rdtsc for some timing function won't be
useable by "user" code, aforementioned lgdt, lidt, etc.

4) any function which destroys registers you expect to be preserved or
corrupts the stack from your OSes perspective won't be useable.  HLA
documentation should tell which registers are preserved and destroyed by the
library calls.  Anyway, register and stack problems can arise due to coding
errors and are hard to locate except by trial and error, since you won't
have a debugger available to help you debug your OS...  If you notice a
function not working as expected, it's best to eliminate it's use and try
something else.

The easy way to find problems with 2) and 3) are to search for privileged
instructions (lgdt,lidt, etc.) and code sequences which won't execute on any
cpu, but "need information" about the cpu before executing, i.e., determines
the cpu type or uses the cpuid instruction to identify supported cpu
features.  You can also search for directives such as .386p, .486p, .586p,
..686p, which, when used properly, indicate that a privileged instruction
should follow.  Or, you could search for "int", such as a Linux OS call:
int( $80 )  Windows calls should be identifiable easily too...


Rod Pemberton
PS.  You might post to alt.os.development for OS related issues and to
alt.lang.asm for other assembly issues.

On Mon, 10 Dec 2007 21:51:18 -0500, "Rod Pemberton"
<spamtrap@crayne.org> wrote:

<snip>

>3) any function which uses a privileged instruction won't be useable in less
>privileged code.  e.g, use of rdtsc for some timing function won't be
>useable by "user" code, aforementioned lgdt, lidt, etc.

RDTSC works just fine in user code.

Best regards,


Bob Masta
 
              DAQARTA  v3.50
   Data AcQuisition And Real-Time Analysis
             www.daqarta.com
Scope, Spectrum, Spectrogram, FREE Signal Generator
        Science with your sound card!

"Bob Masta" <NoSpam@daqarta.com> wrote in message
news:475e88f5.1111502@news.sysmatrix.net...
> On Mon, 10 Dec 2007 21:51:18 -0500, "Rod Pemberton"
> <spamtrap@crayne.org> wrote:
>
> <snip>
>
> >3) any function which uses a privileged instruction won't be useable in
less
> >privileged code.  e.g, use of rdtsc for some timing function won't be
> >useable by "user" code, aforementioned lgdt, lidt, etc.
>
> RDTSC works just fine in user code.
>

It depends on privilege, specifically the state of the flag CR4.TSD...


Rod Pemberton

On Tue, 11 Dec 2007 16:43:42 -0500, "Rod Pemberton"
<spamtrap@crayne.org> wrote:

>
>"Bob Masta" <NoSpam@daqarta.com> wrote in message
>news:475e88f5.1111502@news.sysmatrix.net...
>> On Mon, 10 Dec 2007 21:51:18 -0500, "Rod Pemberton"
>> <spamtrap@crayne.org> wrote:
>>
>> <snip>
>>
>> >3) any function which uses a privileged instruction won't be useable in
>less
>> >privileged code.  e.g, use of rdtsc for some timing function won't be
>> >useable by "user" code, aforementioned lgdt, lidt, etc.
>>
>> RDTSC works just fine in user code.
>>
>
>It depends on privilege, specifically the state of the flag CR4.TSD...
>
>
>Rod Pemberton
>

Bob Masta
 
              DAQARTA  v3.50
   Data AcQuisition And Real-Time Analysis
             www.daqarta.com
Scope, Spectrum, Spectrogram, FREE Signal Generator
        Science with your sound card!

On Tue, 11 Dec 2007 16:43:42 -0500, "Rod Pemberton"
<spamtrap@crayne.org> wrote:

>
>"Bob Masta" <NoSpam@daqarta.com> wrote in message
>news:475e88f5.1111502@news.sysmatrix.net...
>> On Mon, 10 Dec 2007 21:51:18 -0500, "Rod Pemberton"
>> <spamtrap@crayne.org> wrote:
>>
>> <snip>
>>
>> >3) any function which uses a privileged instruction won't be useable in
>less
>> >privileged code.  e.g, use of rdtsc for some timing function won't be
>> >useable by "user" code, aforementioned lgdt, lidt, etc.
>>
>> RDTSC works just fine in user code.
>>
>
>It depends on privilege, specifically the state of the flag CR4.TSD...
>

To clarify, RDTSC works in standard (Ring 3) user programs in all
Windows versions I have tested though XP.  (Haven't tested Vista yet.)

Best regards,



Bob Masta
 
              DAQARTA  v3.50
   Data AcQuisition And Real-Time Analysis
             www.daqarta.com
Scope, Spectrum, Spectrogram, FREE Signal Generator
        Science with your sound card!