From: cr88192@gmail.com   
      
   On 1/8/2022 8:42 AM, James Harris wrote:   
   > On 06/01/2022 17:54, muta...@gmail.com wrote:   
   >> On Thursday, January 6, 2022 at 2:40:30 AM UTC+11, James Harris wrote:   
   >>   
   >>> After a long absence from OS development I recently returned to it - and   
   >>> it feels great to be doing this stuff again!!! The reason for the   
   >>> absence (other than life!) was that I was developing a language to write   
   >>> the OS in.   
   >>   
   >> What's wrong with C?   
   >   
   > That's a good question to ask in comp.lang.misc. There's a guy there who   
   > has compiled a very good list. I agree with the points he had on his   
   > list when I last looked at it though that was some time ago.   
   >   
   > That said, for writing an operating system the flaws in C are nothing   
   > major. I decided to produce my own language to make OS writing easier   
   > but found out that I could do a lot of what I wanted the OS for by using   
   > my own language.   
   >   
   > That said, I would definitely not recommend anyone go down the course   
   > that I did unless he is a genius! Producing a 'good' language has been   
   > far more difficult than I expected.   
   >   
      
   FWIW, my own languages had generally ended up mostly being:   
   BGBScript family, JS/AS style syntax, mostly dynamic types;   
   BGBScript2 family, slightly more Java like syntax, hybrid types.   
      
   At present, I have a compiler (for my own ISA) which does variants of   
   BS, BS2, and C.   
      
   Though, because these are static compiled in this case, and are on a   
   relatively resource constrained target, they lack support for "eval" or   
   similar at present.   
      
      
   In this compiler, some amount of the BGBScript and BGBScript2 features   
   are available in C via language extensions, and it is possible in this   
   case to fairly directly call from one language to another.   
      
   So, say (BS):   
      var obj={x:3, y:4};   
      var arr=[3, 4, 5];   
      var fcn=function(x,y) { return(x+y); };   
      ...   
   Maps to (C extension):   
      __var obj=__var{x:3, y:4};   
      __var arr=__var[3, 4, 5];   
      __var fcn=__function(x,y) { return(x+y); };   
      
      
   Things like type-tagging are partially supported at the hardware level,   
   and the dynamic type-tagging system is also partially specified in the ABI.   
      
      
   Generally, for pointer type values:   
   * (63:60): 0000   
   * (59:48): Object Type-Tag   
   * (47: 0): Memory Address (48-bit address, up to 47 bit userland, *1)   
   **: *1: If virtual memory was usable...   
      
   Normal pointer access (in hardware) simply ignores bits (63:48), though   
   they may apply in certain contexts.   
      
   Fixint:   
      (63:62): 01   
      (61: 0): Value (62-bit, sign extended to 64 bits).   
      
   Flonum:   
      (63:62): 10   
      (61: 0): Value (Double, right-shifted by 2 bits)   
      
   Some other misc stuff goes into the remaining tag space.   
      
      
   In the past, did compare a prime sieve written in normal C (static   
   types), vs one using dynamic types, and saw a roughly 3x speed   
   difference. However, this was "pretty good" all things considered   
   (dynamically typed code consists primarily of runtime calls; array   
   accesses require a fair bit more heavy lifting, ... So seeing only a 3x   
   delta here was better than expected).   
      
   For code which primarily uses static types, the relative cost of   
   occasionally using dynamic types is much less.   
      
      
   It is also possible to retain portability (with normal C compilers) by   
   wrapping the dynamic types in a way that they can fall back to a plain C   
   implementation on different compilers (eg, via a bunch of preprocessor   
   macros).   
      
      
   However, for higher-level scripting tasks, a design more like BS or BS2   
   makes more sense.   
      
      
   > ...   
   >   
   >> In either case, I always load to a fixed address, so I   
   >> may as well produce a flat binary, so that is what I   
   >> am likely to do.   
   >   
   > That makes sense. I chose to allow the code to run from different   
   > locations so that option is not open to me.   
   >   
      
   On x86, if one needs a 16-bit section, then using a flat binary for this   
   part makes sense. Would probably also write it in ASM as well.   
      
      
   One loader option is, say, for the boot loader:   
   Read in second stage loader image;   
   Read in kernel image (using most of conventional memory as buffer space);   
   Second stage loads/unpacks kernel image to its intended load address.   
      
      
   Something like LZ4 still makes sense, since this allows fitting a   
   potentially larger kernel image into the memory one has available in   
   real mode. Also it is simple enough to not be unreasonably complicated   
   to write a decoder for it in ASM (unlike, say, Deflate or LZMA, which   
   are significantly more complicated).   
      
      
   In my custom ISA project though, the FAT driver, PE/PEL4 loader, ... are   
   all handled by the Boot ROM though. This benefits from having 32K   
   available to work with, although the FAT driver (FAT16/FAT32) and   
   "Sanity Check" code eat up a lot of this (the sanity check code   
   basically tests out various ISA instructions and features to make sure   
   things behave as expected).   
      
   Granted, the FAT driver is potentially a little overbuilt for what is   
   theoretically needed in this case. For example, if one mandates that the   
   boot image is contiguous (rather than walking the FAT chain), then a bit   
   of simplification would be possible.   
      
      
   >>   
   >>> Elf and PE have the opposite problem. Either of them should be easy to   
   >>> create but how would one invoke the image? Options:   
   >>>   
   >>> 2a. Extract the executable part (how?) for inclusion in the loadable   
   >>> image.   
   >>   
   >> You will need the same logic as a loader. Public domain   
   >> code is available here for both:   
   >>   
   >> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/bios/exeload.c   
   >   
   > Thanks for the link. I see in its exeloadLoadPE function the following.   
   >   
   >      if ((coff_hdr.Characteristics & IMAGE_FILE_RELOCS_STRIPPED) != 0)   
   >      {   
   >          printf("only relocatable executables supported\n");   
   >          return (2);   
   >      }   
   >   
   > and I think that's what's happening here. The linker or something else   
   > is stripping out the relocs. ATM I cannot imagine why it would do such a   
   > thing.   
   >   
   > Assuming I can fix the link process I can also see some useful   
   > calculations in the page you mention such as   
   >   
   >    rel_block = exeStart + data_dir->VirtualAddress   
   >   
   > such calcs may be simple but they confirm what needs to be done and are   
   > easier to read than the specs!   
   >   
      
      
   The mainstream linkers generally tend to strip relocs by default for EXE   
   files.   
      
   One possible workaround would be to compile their binaries as DLLs.   
      
      
   >>   
   >>> 2b. Include the whole executable file, including the headers, and write   
   >>> some asm code to parse the headers and jump to the executable part of   
   >>> it.   
   >>   
   >> Why can't you write 16-bit C code to do that instead   
   >> of assembler? That's what I do. If I had my time again   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)