Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.msdos.programmer > #1086 > unrolled thread
| Started by | "Alexei A. Frounze" <alexfrunews@gmail.com> |
|---|---|
| First post | 2013-12-01 08:15 -0800 |
| Last post | 2015-09-06 15:55 -0700 |
| Articles | 20 on this page of 85 — 5 participants |
Back to article view | Back to comp.os.msdos.programmer
Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-01 08:15 -0800
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-01 18:42 +0000
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-01 19:14 -0800
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-02 11:13 +0000
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-02 03:21 -0800
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-03 06:21 +0000
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-02 23:17 -0800
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-03 13:31 +0000
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-03 06:05 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-03 10:47 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-03 21:18 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-03 12:23 -0500
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-03 16:26 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-03 23:58 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-04 04:31 -0500
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-04 05:01 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-04 02:20 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-05 06:33 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-05 21:37 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-06 12:19 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-06 22:23 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-07 13:48 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-07 16:34 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-08 02:12 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-13 03:32 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-15 04:47 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-15 02:14 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-15 13:21 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-04 23:39 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-05 06:38 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-05 21:40 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-06 04:19 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-06 13:40 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-14 21:07 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-03 22:22 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-04 04:30 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-04 23:21 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-05 04:23 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-05 21:31 -0800
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-10 04:59 +0000
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-10 06:17 +0000
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-11 02:36 -0800
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-11 13:44 +0000
Re: Smaller C compiler Harry Potter <rose.joseph12@yahoo.com> - 2013-12-10 10:41 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-11 03:06 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-11 10:47 -0500
Re: Smaller C compiler Harry Potter <rose.joseph12@yahoo.com> - 2013-12-11 08:01 -0800
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-11 13:40 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-11 22:07 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-25 02:33 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-29 03:24 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-21 15:55 -0800
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-29 17:16 +0000
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-12-29 21:54 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-29 19:38 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-29 19:36 -0800
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2013-12-30 05:07 +0000
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2013-12-29 21:58 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-01-05 19:43 -0800
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2014-01-06 15:27 +0000
Re: Smaller C compiler "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-06 19:51 -0500
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2014-01-07 04:27 +0000
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-01-06 21:52 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-02-16 22:57 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-02-25 00:17 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-03-01 21:31 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-03-10 01:46 -0700
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-04-20 20:19 -0700
Re: Smaller C compiler Harry Potter <rose.joseph12@yahoo.com> - 2014-04-23 11:20 -0700
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-04-23 11:41 -0700
Re: Smaller C compiler Harry Potter <rose.joseph12@yahoo.com> - 2014-04-25 06:08 -0700
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-09-14 03:06 -0700
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-11-09 03:26 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-11-28 04:06 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2014-12-21 01:56 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-01-10 10:37 -0800
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-04-19 23:55 -0700
Re: Smaller C compiler "Auric__" <not.my.real@email.address> - 2015-04-22 06:13 +0000
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-04-22 00:12 -0700
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-04-25 21:11 -0700
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-05-16 17:49 -0700
Re: Smaller C compiler "Bill Buckels" <bbuckels@mts.net> - 2015-05-19 20:01 -0500
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-05-19 18:18 -0700
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-08-15 02:13 -0700
Re: Smaller C compiler "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-09-06 15:55 -0700
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | "Auric__" <not.my.real@email.address> |
|---|---|
| Date | 2013-12-10 06:17 +0000 |
| Message-ID | <XnsA291ECE0D66C9auricauricauricauric@78.46.70.116> |
| In reply to | #1143 |
I wrote: > Alexei A. Frounze wrote: > >> In case this is of interest to anyone, I'm working on a small and >> simple C compiler currently targeting x86 (and MIPS:), Smaller C. > [snip] >> Testers/test-drivers? ;) > > Just reporting, tcc & lcc both working good with the current revision of > the source. Same notes re: building apps with smlrc as before. (tcc: no > external linker; lcc: works good, but compile & link for win32 only.) > > I should perhaps mention that lcc has a *nix version as well; I haven't > tried it, nor do I really intend to. I just discovered I have a forgotten install of Borland C++ 5.5.1 for Win32 (the one that they used to give away for free, dated 2000). It has no problem compiling Smaller C: bcc32 smlrc.c ...so yay, another success -- but I'm having problems linking smrlc apps with bcc32's ilink32. Compiling my test.c goes like so: smlrc -seg32 test.c test.asm nasm -f win32 test.asm ilink32 test.obj Error: 'D:\WINTOOLS\PROGRAMMING\BCC551\BIN\TEST.OBJ' contains invalid OMF record, type 0x4c (possibly COFF) If I try using nasm's "obj" format, I get: smlrc -seg32 test.c tess-bcc.asm nasm -f obj test-bcc.asm ilink32 test-bcc.obj Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland Fatal: Unsupported 16-bit segment(s) in module test-bcc.asm I haven't spent any time investigating what it takes to make nasm output a 32-bit "obj" object. The docs make it seem like it should "just happen"; pointers would help me move this testing along. -- Free your mind from doubt -- all you have is now. Free your mind from shame -- it will only bring you pain.
[toc] | [prev] | [next] | [standalone]
| From | "Alexei A. Frounze" <alexfrunews@gmail.com> |
|---|---|
| Date | 2013-12-11 02:36 -0800 |
| Message-ID | <057b1381-9a82-4551-96ad-13aacfcc95d6@googlegroups.com> |
| In reply to | #1144 |
On Monday, December 9, 2013 10:17:01 PM UTC-8, Auric__ wrote: ... > ...so yay, another success -- but I'm having problems linking smrlc apps > with bcc32's ilink32. Compiling my test.c goes like so: The OBJ/OMF format is known to be overdesigned and implemented sufficiently differently in different assemblers, compilers and linkers, to the point of them being hardly compatible with one another when used outside of their native toolchain. I know NASM works with 16-bit Borland/Turbo compilers/linkers and with gcc/ld (ELF and DJGPP's COFF formats). That's a lot already. Alex
[toc] | [prev] | [next] | [standalone]
| From | "Auric__" <not.my.real@email.address> |
|---|---|
| Date | 2013-12-11 13:44 +0000 |
| Message-ID | <XnsA29344AA8E64Bauricauricauricauric@78.46.70.116> |
| In reply to | #1150 |
Alexei A. Frounze wrote: > On Monday, December 9, 2013 10:17:01 PM UTC-8, Auric__ wrote: > ... >> ...so yay, another success -- but I'm having problems linking smrlc >> apps with bcc32's ilink32. Compiling my test.c goes like so: > > The OBJ/OMF format is known to be overdesigned and implemented > sufficiently differently in different assemblers, compilers and linkers, > to the point of them being hardly compatible with one another when used > outside of their native toolchain. Ah, ok. Didn't know that; I don't have much experience with the various object formats. > I know NASM works with 16-bit Borland/Turbo compilers/linkers and with > gcc/ld (ELF and DJGPP's COFF formats). That's a lot already. I guess the problem is with ilink32 -- therefore, I'm guessing that bcc32 can't be used as the backend for your compiler. Not unless you want to add support for tasm32. In unrelated news, I discovered I also happen to have yasm installed on this machine (v1.1.0.2352, dated Aug 7 2010). Yasm works with my test file as compiled by your compiler, which is unsurprising since yasm was based on nasm (or forked from it? I'm not entirely clear on that). -- Does. Not. Compute.
[toc] | [prev] | [next] | [standalone]
| From | Harry Potter <rose.joseph12@yahoo.com> |
|---|---|
| Date | 2013-12-10 10:41 -0800 |
| Message-ID | <1a10e66d-b3b3-4b76-a397-60a3a474e126@googlegroups.com> |
| In reply to | #1086 |
I am sorry for not fully reading this thread: I can be lazy at times. :( However, I am interested in your idea. It may be useful for games. I have a C compiler-in-planning for 8-bit computers with full optimizations and thinking about a quick-C compiler for the same for small, efficient programs. I am wondering: how good is your compiler at optimizing? BTW, right now, I have limited access to computers: right now, I am working on computers on which I have limited rights; I can only download at a local library; at my mother's house--the only time I get usable computer access--my WinVista computer--is broken; and I can only go to my mother's house every so often. However, I will still try to download the files. :)
[toc] | [prev] | [next] | [standalone]
| From | "Alexei A. Frounze" <alexfrunews@gmail.com> |
|---|---|
| Date | 2013-12-11 03:06 -0800 |
| Message-ID | <3ef67017-061c-4fa7-b6a6-a942c10151af@googlegroups.com> |
| In reply to | #1146 |
On Tuesday, December 10, 2013 10:41:55 AM UTC-8, Harry Potter wrote: > I am sorry for not fully reading this thread: I can be lazy at times. :( However, I am interested in your idea. It may be useful for games. I have a C compiler-in-planning for 8-bit computers with full optimizations and thinking about a quick-C compiler for the same for small, efficient programs. I am wondering: how good is your compiler at optimizing? > Not good at all. Currently it generates about 30% extra code compared to x86 Turbo C++ 1.01 and 200% extra code compared to MIPS32 gcc. It's better than the original Small C, though. :) It's not trivial to implement most of the basic C programming language features in a small compiler and have it compile itself into 64K code + 64K data and at the same time do more than trivial optimizations. For more features and for better optimization I need more memory than that (I'm close to the limit at the moment and I still haven't implemented struct!). To use more memory I'll need to write and rewrite lots of code to make it still work in DOS in 16-bit mode, which is one of the goals. I may need to split the compiler into smaller parts and run them one by one or use many more segments of memory (via far pointers) or do something else (use files as memory). At the same time I don't want the compiler to be tied to DOS or have lots of DOS-specific code in its core. And that's a more important goal. It's quite bad when you can't recompile code because it's not portable enough. Alex
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2013-12-11 10:47 -0500 |
| Message-ID | <op.w7xp5mo25zc71u@localhost> |
| In reply to | #1152 |
On Wed, 11 Dec 2013 06:06:12 -0500, Alexei A. Frounze <alexfrunews@gmail.com> wrote: > On Tuesday, December 10, 2013 10:41:55 AM UTC-8, Harry Potter wrote: >> [code opt.] > > Not good at all. Currently it generates about 30% extra code compared to > x86 Turbo C++ 1.01 and 200% extra code compared to MIPS32 gcc. It's > better than the original Small C, though. :) > Yeah, I've never seen much written about how Turbo C generated decent code - not excellent - so fast. I'm still curious. > It's not trivial to implement most of the basic C programming language > features in a small compiler and have it compile itself into 64K code > + 64K data and at the same time do more than trivial optimizations. For > more features and for better optimization I need more memory than that > (I'm close to the limit at the moment and I still haven't implemented > struct!). Today, I use files instead of memory for most of my compiler projects. You can use fseek() and/or ftell(), or fgetpos() and/or fsetpos(), to move around within the file(s). A cleanly formatted fprintf() to write the data, and fscanf() to (re)read the data. I happen to like my programs to output to stdout by default or a file when specified. Obviously, you can't rewrite earlier data if the file pointer is stdout. Of course, there are file size limits set by the operating system as well as representation limits for the seek functions. Memory is far faster, if you keep your linked-lists, etc, formats simple with minimal memory movement, clearing, and/or compaction etc. Although, since there are no file I/O like functions which work on memory, the coding for memory is more work upfront. Obviously, the quantity of memory is limited which can be a problem with larger files, or the limited capacity of the memory allocator. For memory based programs, I usually just warn and exit, if the file is too large. About five years ago, I did create a set of memory functions which treat memory as a file. Mainly, I saw it as a defect of C to not have them. I called them m_fopen, m_fwrite, m_fread, m_fclose, m_rewind, but, you mwrite, mread, mclose, mopen, mrewind would be more appropriate. Basically, this required creating file I/O like in stdio.h, but simplified somewhat for memory. Unfortunately, they are only tested for one time usage, single memory file, not multiple memory files. So, five functions, a handful of helper functions, an MFILE struct, and a struct for a link to link MFILE structs into a linked-list to keep track. In the end, I decided that file I/O using tmpfiles(), which generally use memory for speed, was a better choice, since the file I/O for files was fully tested. > To use more memory I'll need to write and rewrite lots of code > to make it still work in DOS in 16-bit mode, which is one of the goals. ... > I may need to split the compiler into smaller parts and run them one by > one or use many more segments of memory (via far pointers) or do > something else (use files as memory). At the same time I don't want the > compiler to be tied to DOS or have lots of DOS-specific code in its > core. And that's a more important goal. It's quite bad when you can't > recompile code because it's not portable enough. That could be a difficult situation. You're always going to be dealing with segmented memory for 16-bit DOS, e.g., far near huge FP_SEG FP_OFF MK_FP. You might also need to use DPMI calls for 32-bit DOS. That's all environment specific code ..., i.e., "non-portable". The pragma's for packing is different for each compiler too. Include files will be different too. Buffering of streams, especially to the screen, will be different also. Personally, I have no problem using macro's provided by the compiler for each compiler and for each processor mode to separate code. E.g., every program for DJGPP and OpenWatcom I have has some code like this: #ifdef __DJGPP__ /* 32-bit DPMI */ #endif #ifdef __WATCOMC__ #ifdef __386__ /* 32-bit DPMI */ #else /* 16-bit */ #endif #endif There will be some at the top for specific compiler includes, and usually some in the code for DPMI/MK_FP, or different functions. The more you deviate from ANSI C and move into DOS specific code, the more different and compiler specific the C code becomes. For OW and DJGPP at least, the closest you can get for common packing is: #ifdef __DJGPP__ #define HANDLE_PRAGMA_PACK_PUSH_POP 1 #endif #pragma pack(push,1) /* packed structs */ #pragma pack(pop) For GCC compilers, IIRC, there is also an attribute for packing. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Harry Potter <rose.joseph12@yahoo.com> |
|---|---|
| Date | 2013-12-11 08:01 -0800 |
| Message-ID | <0b7fb2c9-34b4-440f-a805-5f580bd12ebc@googlegroups.com> |
| In reply to | #1159 |
On Wednesday, December 11, 2013 10:47:36 AM UTC-5, Rod Pemberton wrote: > About five years ago, I did create a set of memory functions which > treat memory as a file. Mainly, I saw it as a defect of C to not > have them. I called them m_fopen, m_fwrite, m_fread, m_fclose, > m_rewind, but, you mwrite, mread, mclose, mopen, mrewind would be > more appropriate. Basically, this required creating file I/O like > in stdio.h, but simplified somewhat for memory. Unfortunately, they > are only tested for one time usage, single memory file, not multiple > memory files. So, five functions, a handful of helper functions, > an MFILE struct, and a struct for a link to link MFILE structs into > a linked-list to keep track. In the end, I decided that file I/O > using tmpfiles(), which generally use memory for speed, was a better > choice, since the file I/O for files was fully tested. > I think that memory-based I/O emulation functions are a good idea. Of course, file access could be made faster through a RAM drive, but your program may not be able to detect a RAM drive. Sorry about pushing the RAM drive issue: I've been in a RAM drive kick lately ad often in my history. They helped me a little, but one use was required to emulate a missing hard drive.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2013-12-11 13:40 -0500 |
| Message-ID | <op.w7xx5vz25zc71u@localhost> |
| In reply to | #1161 |
On Wed, 11 Dec 2013 11:01:54 -0500, Harry Potter <rose.joseph12@yahoo.com> wrote: > Of course, file access could be made faster through a RAM drive, but > your program may not be able to detect a RAM drive. Sorry about pushing > the RAM drive issue: I've been in a RAM drive kick lately ad often in my > history. They helped me a little, but one use was required to emulate a > missing hard drive. I used a ramdisk (XMSDSK) - started in DOS - for WinSE to good effect. Mostly, I used it for temporary space for my web browser. I might've used it for the WinSE swap file too... I still use DOS and WinSE for personal DOS development, but I'm on Linux now for daily, Internet, and general computer use. This Linux distro (64-bit) was setup to use a ramdisk (TMPFS) out of the box. It's setup as 1.7GB. I also installed a 1GB swap partition initially, since all prior attempts to use Linux needed one. The Linux 'swapon -s' and 'free -m -t' commands, shows the swap partition has *never* been used. 'df -v' never shows more than 1% use for the ramdisks. I have 4GB of memory. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Alexei A. Frounze" <alexfrunews@gmail.com> |
|---|---|
| Date | 2013-12-11 22:07 -0800 |
| Message-ID | <3ecd4873-9562-4fdb-9105-4bcccef92c18@googlegroups.com> |
| In reply to | #1159 |
On Wednesday, December 11, 2013 7:47:36 AM UTC-8, Rod Pemberton wrote: ... > For OW and DJGPP at least, the closest you can get for common > packing is: > > #ifdef __DJGPP__ > #define HANDLE_PRAGMA_PACK_PUSH_POP 1 > #endif > #pragma pack(push,1) > /* packed structs */ > #pragma pack(pop) > > For GCC compilers, IIRC, there is also an attribute for packing. Check it out, most recent GCC supports the same #pragma pack's: http://gcc.gnu.org/onlinedocs/gcc/Structure-Packing-Pragmas.html Alex
[toc] | [prev] | [next] | [standalone]
| From | "Alexei A. Frounze" <alexfrunews@gmail.com> |
|---|---|
| Date | 2013-12-25 02:33 -0800 |
| Message-ID | <l9ecai$1fo$1@speranza.aioe.org> |
| In reply to | #1159 |
On Wednesday, December 11, 2013 7:47:36 AM UTC-8, Rod Pemberton wrote: > On Wed, 11 Dec 2013 06:06:12 -0500, Alexei A. Frounze <...@gmail.com> > wrote: [snip] > Yeah, I've never seen much written about how Turbo C generated > decent code - not excellent - so fast. I'm still curious. > > > It's not trivial to implement most of the basic C programming language > > features in a small compiler and have it compile itself into 64K code > > + 64K data and at the same time do more than trivial optimizations. For > > more features and for better optimization I need more memory than that > > (I'm close to the limit at the moment and I still haven't implemented > > struct!). > > Today, I use files instead of memory for most of my compiler projects. > You can use fseek() and/or ftell(), or fgetpos() and/or fsetpos(), to > move around within the file(s). A cleanly formatted fprintf() to write > the data, and fscanf() to (re)read the data. I happen to like my > programs to output to stdout by default or a file when specified. > Obviously, you can't rewrite earlier data if the file pointer is stdout. > Of course, there are file size limits set by the operating system > as well as representation limits for the seek functions. > > Memory is far faster, if you keep your linked-lists, etc, formats > simple with minimal memory movement, clearing, and/or compaction etc. > Although, since there are no file I/O like functions which work on > memory, the coding for memory is more work upfront. Obviously, > the quantity of memory is limited which can be a problem with larger > files, or the limited capacity of the memory allocator. For memory > based programs, I usually just warn and exit, if the file is too large. > > About five years ago, I did create a set of memory functions which > treat memory as a file. Mainly, I saw it as a defect of C to not > have them. I called them m_fopen, m_fwrite, m_fread, m_fclose, > m_rewind, but, you mwrite, mread, mclose, mopen, mrewind would be > more appropriate. Basically, this required creating file I/O like > in stdio.h, but simplified somewhat for memory. Unfortunately, they > are only tested for one time usage, single memory file, not multiple > memory files. So, five functions, a handful of helper functions, > an MFILE struct, and a struct for a link to link MFILE structs into > a linked-list to keep track. In the end, I decided that file I/O > using tmpfiles(), which generally use memory for speed, was a better > choice, since the file I/O for files was fully tested. > > > To use more memory I'll need to write and rewrite lots of code > > to make it still work in DOS in 16-bit mode, which is one of the goals. > ... > > I may need to split the compiler into smaller parts and run them one by > > one or use many more segments of memory (via far pointers) or do > > something else (use files as memory). At the same time I don't want the > > compiler to be tied to DOS or have lots of DOS-specific code in its > > core. And that's a more important goal. It's quite bad when you can't > > recompile code because it's not portable enough. > > That could be a difficult situation. > > You're always going to be dealing with segmented memory for 16-bit DOS, > e.g., far near huge FP_SEG FP_OFF MK_FP. You might also need to use > DPMI calls for 32-bit DOS. That's all environment specific code ..., > i.e., "non-portable". The pragma's for packing is different for each > compiler too. Include files will be different too. Buffering of > streams, especially to the screen, will be different also. Personally, > I have no problem using macro's provided by the compiler for each > compiler and for each processor mode to separate code. E.g., every > program for DJGPP and OpenWatcom I have has some code like this: [snip] > There will be some at the top for specific compiler includes, and > usually some in the code for DPMI/MK_FP, or different functions. > The more you deviate from ANSI C and move into DOS specific code, > the more different and compiler specific the C code becomes. I've just spent a couple of days fooling around the ideas of multiple segments, far pointers and the huge memory model (as Borland or whoever coined it). The result, I've got Smaller C to compile itself into 16/32-bit real-mode code, still a regular DOS MZ .EXE (~200KB). Ints and pointers are 32-bit. Pointers are physical addresses (the top 12 bits naturally get lost during conversion to segment:offset pairs). Neither of FP_SEG(), FP_OFF() and MK_FP() is needed. 64KB segment limit(ation)s are significantly relaxed. The stack is still limited to 64K, which is OK, and individual functions are limited to 32K in size, which shouldn't be much of a problem either. Other than that, unless you want to write inline assembly code (*), things look nice and clean. You can use ((unsigned char*)0xB8000)[0] to access the character at the top left corner of the screen in text mode. Of course, the cheap and conservative adjustments in the code generator result in significantly worse performance of code compiled using this huge memory model, and the code gets bigger as well. But it's OK. It's still a toyish compiler, and while it's at this level, it should not be considered for serious/important stuff. But for relatively small things (the DOS world has now shrunk to small and few things anyway), including some hobby OS dev projects, it can be used. Also, this should allow creation of a usable standard library now that we can have 32-bit integers in real-mode code (fseek() and ftell() with their at least 32-bit-long file offsets are not a problem anymore). This new huge stuff is still raw, but I'm expecting to commit it to github no later than January 2014. (*) The code generator generates relocation tables for the huge memory model. They are used at startup. Inline assembly code will need to either avoid referencing global variables and functions by their names or it will need to contribute a record or a few to the relocation tables, which is not a big deal, but isn't very nice looking. Alex
[toc] | [prev] | [next] | [standalone]
| From | "Alexei A. Frounze" <alexfrunews@gmail.com> |
|---|---|
| Date | 2013-12-29 03:24 -0800 |
| Message-ID | <l9p0pe$ac9$1@speranza.aioe.org> |
| In reply to | #1224 |
I've just added support for the huge memory model via the -huge option. It'll let you compile 32-bit code for DOS. Ints and pointers are 32-bit. Pointers are 32-bit physical addresses. No need to mess with segments. And you can have arrays larger than 64KB! :) In this model the stack is limited to 64KB and the cumulative size of local variables is limited to 32KB (this is a per-function limit). Individual functions are limited to 32KB of code size. These limitations should not pose problems normally. This is how you can (re)compile Smaller C using the huge memory model (provided you have a 32-bit Smaller C already, compiled with gcc/DJGPP, Open Watcom C/C++ for Windows/DOS4G, etc): smlrc -huge -no-externs lbdos.c lbdos.asm smlrc -huge -no-externs -label 1001 smlrc.c smlrc.asm nasm -f bin smlrchg.asm -o smlrchg.exe Enjoy and a happy New Year! Alex
[toc] | [prev] | [next] | [standalone]
| From | "Alexei A. Frounze" <alexfrunews@gmail.com> |
|---|---|
| Date | 2013-12-21 15:55 -0800 |
| Message-ID | <l959qc$rpf$1@speranza.aioe.org> |
| In reply to | #1086 |
New additions in Smaller C: - goto - conditional/ternary operator ?: - type casts! - (already mentioned in this group) you can now (re)compile Smaller C into a 16-bit DOS .EXE using only Smaller C and NASM (no linker!) Happy holiday season everyone! Alex
[toc] | [prev] | [next] | [standalone]
| From | "Auric__" <not.my.real@email.address> |
|---|---|
| Date | 2013-12-29 17:16 +0000 |
| Message-ID | <XnsA2A56895F6F7Dauricauricauricauric@78.46.70.116> |
| In reply to | #1086 |
Alexei A. Frounze wrote: > In case this is of interest to anyone, I'm working on a small and simple > C compiler currently targeting x86 (and MIPS:), Smaller C. Another compiler working, Pelles' C: http://www.pellesc.de/ Unfortunately, I don't know enough to get it to link compiled apps together, so I don't know if it can be used as a backend for your compiler. (I'm guessing it *probably* can, but I'm not sure *how*.) -- Bless their mercenary little hearts.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> |
|---|---|
| Date | 2013-12-29 21:54 -0500 |
| Message-ID | <op.w8vw1xcb5zc71u@localhost> |
| In reply to | #1229 |
On Sun, 29 Dec 2013 12:16:52 -0500, Auric__ <not.my.real@email.address> wrote: > Alexei A. Frounze wrote: >> In case this is of interest to anyone, I'm working on a small >> and simple C compiler currently targeting x86 (and MIPS:), >> Smaller C. > > Another compiler working, Pelles' C: > > http://www.pellesc.de/ > > Unfortunately, I don't know enough to get it to link compiled apps > together, so I don't know if it can be used as a backend for your > compiler. (I'm guessing it *probably* can, but I'm not sure *how*.) > Pelles C and LCC-Win uses the LCC compiler by Fraser and Hanson of "A Retargetable C Compiler: Design and Implementation": http://en.wikipedia.org/wiki/LCC_(compiler) IIRC, one or both of them work for Microsoft now, something Alex is familiar with. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Alexei A. Frounze" <alexfrunews@gmail.com> |
|---|---|
| Date | 2013-12-29 19:38 -0800 |
| Message-ID | <l9qpse$94s$2@speranza.aioe.org> |
| In reply to | #1233 |
On Sunday, December 29, 2013 6:54:59 PM UTC-8, Rod Pemberton wrote: > Pelles C and LCC-Win uses the LCC compiler by Fraser and Hanson > of "A Retargetable C Compiler: Design and Implementation": > > http://en.wikipedia.org/wiki/LCC_(compiler) > > IIRC, one or both of them work for Microsoft now, something > Alex is familiar with. I've never used LCC nor met any of its authors. And I no longer work at Microsoft. Alex
[toc] | [prev] | [next] | [standalone]
| From | "Alexei A. Frounze" <alexfrunews@gmail.com> |
|---|---|
| Date | 2013-12-29 19:36 -0800 |
| Message-ID | <l9qpsb$94s$1@speranza.aioe.org> |
| In reply to | #1229 |
On Sunday, December 29, 2013 9:16:52 AM UTC-8, Auric__ wrote: > Alexei A. Frounze wrote: > > In case this is of interest to anyone, I'm working on a small and simple > > C compiler currently targeting x86 (and MIPS:), Smaller C. > > Another compiler working, Pelles' C: > > http://www.pellesc.de/ > > Unfortunately, I don't know enough to get it to link compiled apps > together, > so I don't know if it can be used as a backend for your compiler. (I'm > guessing it *probably* can, but I'm not sure *how*.) I'm pretty sure PellesC will compile Smaller C under Windows. I've once compiled a hello-world program with PellesC (I used the commandline tools, not the IDE) and it was easy. Alex
[toc] | [prev] | [next] | [standalone]
| From | "Auric__" <not.my.real@email.address> |
|---|---|
| Date | 2013-12-30 05:07 +0000 |
| Message-ID | <XnsA2A5E10CBB734auricauricauricauric@78.46.70.116> |
| In reply to | #1234 |
Alexei A. Frounze wrote: > On Sunday, December 29, 2013 9:16:52 AM UTC-8, Auric__ wrote: >> Alexei A. Frounze wrote: >> > In case this is of interest to anyone, I'm working on a small and >> > simple C compiler currently targeting x86 (and MIPS:), Smaller C. >> >> Another compiler working, Pelles' C: >> >> http://www.pellesc.de/ >> >> Unfortunately, I don't know enough to get it to link compiled apps >> together, so I don't know if it can be used as a backend for your >> compiler. (I'm guessing it *probably* can, but I'm not sure *how*.) > > I'm pretty sure PellesC will compile Smaller C under Windows. I've once > compiled a hello-world program with PellesC (I used the commandline tools, > not the IDE) and it was easy. The problem was with linking programs compiled by Smaller C -> nasm (sorry for the unclear phrasing) but I've got it figured out. Looks like you have to explicitly link in the appropriate libraries, like so: SET PELLES=D:\Wintools\Programming\PellesC SET LIB=%PELLES%\Lib;%PELLES%\Lib\Win Smaller-C -seg32 test.c test.asm nasm -f win32 test.asm polink /LIBPATH:%LIB% /SUBSYSTEM:CONSOLE test.obj %PELLES%\Lib\crt.lib (The environment variables are just to save space here.) -- There is at least one vampire, and it is far more terrifying than any Transylvanian count; its name isn't Dracula but leukemia, and there is no stake you can put through its heart.
[toc] | [prev] | [next] | [standalone]
| From | "Alexei A. Frounze" <alexfrunews@gmail.com> |
|---|---|
| Date | 2013-12-29 21:58 -0800 |
| Message-ID | <l9r309$o27$1@speranza.aioe.org> |
| In reply to | #1237 |
On Sunday, December 29, 2013 9:07:23 PM UTC-8, Auric__ wrote: > Alexei A. Frounze wrote: > > On Sunday, December 29, 2013 9:16:52 AM UTC-8, Auric__ wrote: > >> Alexei A. Frounze wrote: > >> > In case this is of interest to anyone, I'm working on a small and > >> > simple C compiler currently targeting x86 (and MIPS:), Smaller C. > >> > >> Another compiler working, Pelles' C: > >> > >> http://www.pellesc.de/ > >> > >> Unfortunately, I don't know enough to get it to link compiled apps > >> together, so I don't know if it can be used as a backend for your > >> compiler. (I'm guessing it *probably* can, but I'm not sure *how*.) > > > > I'm pretty sure PellesC will compile Smaller C under Windows. I've once > > compiled a hello-world program with PellesC (I used the commandline > > tools, > > not the IDE) and it was easy. > > The problem was with linking programs compiled by Smaller C -> nasm (sorry > for the unclear phrasing) but I've got it figured out. Looks like you have > to explicitly link in the appropriate libraries, like so: > > SET PELLES=D:\Wintools\Programming\PellesC > SET LIB=%PELLES%\Lib;%PELLES%\Lib\Win > Smaller-C -seg32 test.c test.asm > nasm -f win32 test.asm > polink /LIBPATH:%LIB% /SUBSYSTEM:CONSOLE test.obj %PELLES%\Lib\crt.lib > > (The environment variables are just to save space here.) Got it, thanks! Alex
[toc] | [prev] | [next] | [standalone]
| From | "Alexei A. Frounze" <alexfrunews@gmail.com> |
|---|---|
| Date | 2014-01-05 19:43 -0800 |
| Message-ID | <lad8p0$157$1@speranza.aioe.org> |
| In reply to | #1237 |
On Sunday, December 29, 2013 9:07:23 PM UTC-8, Auric__ wrote: > Alexei A. Frounze wrote: > > > On Sunday, December 29, 2013 9:16:52 AM UTC-8, Auric__ wrote: > >> Alexei A. Frounze wrote: > >> > In case this is of interest to anyone, I'm working on a small and > >> > simple C compiler currently targeting x86 (and MIPS:), Smaller C. > >> > >> Another compiler working, Pelles' C: > >> > >> http://www.pellesc.de/ > >> > >> Unfortunately, I don't know enough to get it to link compiled apps > >> together, so I don't know if it can be used as a backend for your > >> compiler. (I'm guessing it *probably* can, but I'm not sure *how*.) > > > > I'm pretty sure PellesC will compile Smaller C under Windows. I've once > > compiled a hello-world program with PellesC (I used the commandline > > tools, > > not the IDE) and it was easy. > > The problem was with linking programs compiled by Smaller C -> nasm (sorry > for the unclear phrasing) but I've got it figured out. Looks like you have > to explicitly link in the appropriate libraries, like so: > > SET PELLES=D:\Wintools\Programming\PellesC > SET LIB=%PELLES%\Lib;%PELLES%\Lib\Win > Smaller-C -seg32 test.c test.asm > nasm -f win32 test.asm > polink /LIBPATH:%LIB% /SUBSYSTEM:CONSOLE test.obj %PELLES%\Lib\crt.lib > > (The environment variables are just to save space here.) With the most recent change on github you can now recompile Smaller C into a 32-bit Windows executable: smlrc -seg32 -no-externs -D _WIN32 lb.c lb.asm smlrc -seg32 -no-externs -label 1001 smlrc.c smlrc.asm nasm -f bin mzstub.asm -o mzstub.bin nasm -f bin smlrcw.asm -o smlrcw.exe I'll probably support the same compilation scheme for Linux as well. I think ELF isn't as bad as PE (at least, when you can invoke syscalls without importing anything from DLLs). Alex
[toc] | [prev] | [next] | [standalone]
| From | "Auric__" <not.my.real@email.address> |
|---|---|
| Date | 2014-01-06 15:27 +0000 |
| Message-ID | <XnsA2AD560A98E84auricauricauricauric@78.46.70.116> |
| In reply to | #1243 |
Alexei A. Frounze wrote: > With the most recent change on github you can now recompile Smaller C > into a 32-bit Windows executable: > > smlrc -seg32 -no-externs -D _WIN32 lb.c lb.asm > smlrc -seg32 -no-externs -label 1001 smlrc.c smlrc.asm > nasm -f bin mzstub.asm -o mzstub.bin > nasm -f bin smlrcw.asm -o smlrcw.exe > > I'll probably support the same compilation scheme for Linux as well. > I think ELF isn't as bad as PE (at least, when you can invoke syscalls > without importing anything from DLLs). IIRC, the MZ stub isn't really necessary. You can start the PE header at 0x00 as long as you point 0x3C there (which would set "stack commit size" = 0). -- [insert sound of soul dying here]
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.os.msdos.programmer
csiph-web