Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #9231 > unrolled thread

misc comments

Back to article view | Back to alt.os.development

Contents

  misc comments "Benjamin David Lunt" <zfysz@fysnet.net> - 2016-03-01 17:21 -0700
    Re: misc comments "Alexei A. Frounze" <alexfrunews@gmail.com> - 2016-03-01 21:52 -0800
      Re: misc comments "Benjamin David Lunt" <zfysz@fysnet.net> - 2016-03-02 10:28 -0700
        Re: misc comments Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-02 18:58 -0500
          Re: misc comments "Benjamin David Lunt" <zfysz@fysnet.net> - 2016-03-03 12:04 -0700
        Re: misc comments "Alexei A. Frounze" <alexfrunews@gmail.com> - 2016-03-02 23:41 -0800
    Re: misc comments Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-03-02 18:58 -0500
      Re: misc comments "Benjamin David Lunt" <zfysz@fysnet.net> - 2016-03-03 12:08 -0700

#9231 — misc comments

[
 I was going to post this at the bottom of my reply to
 Isaac, but it got a little long, so forgive the new topic.
]

Hey guys.  I'm still here and have been reading some/most of
the posts within these groups.  I have been quite busy with other
things.

I have been wanting to get back to what Alex is doing with
SmallerC.  You added floating point support, did you not?
My assembler's floating point support is rough, so this may
be a great opportunity to test my work.

I have done little to no work on my OS development, nor any
work on my books.  Darn it!  :-)

I do remember reading a small article on the new USB Type C
adapter where some cheap knockoffs are being produced.  For
example, if you have a Micro B cable to charge your phone
but only have a Type C port, you can get an adapter to
go from Type C to Micro B.  However, the cheap knock offs
don't have the correct pull-down resistor, or don't have
it at all, and will allow full USB 3.1 charging current
to your phone, which by the way, may damage your phone since
it expects a lot less current.

I hope to be able to get back to Volume 6 of my series.
The GUI is coming along well.

  http://www.fysnet.net/temp/vol6_gui.png

The text of the book, the body, or heart of the book is *not*
coming along so well.  It is hard to explain the details
so that a beginner to programming can somewhat understand
what is going on.  It's a project where you really need
some programming background to understand the subject.
I have yet to find that knowledge level where the reader
should be.  If I assume the reader is fluent in C's Unions
and Structures, the beginner will be lost.  If I don't,
a lot of the text is describing the C language.  I find
myself adding text and removing it, numerous times trying
to find that line.  Oh well, soon.  :-)

Anyway, wanted to let everyone know I am still around and
do try to read all the posts.

Thanks,
Ben

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Forever Young Software
http://www.fysnet.net/index.htm
http://www.fysnet.net/osdesign_book_series.htm
To reply by email, please remove the zzzzzz's

Batteries not included, some Assembly required. 

[toc] | [next] | [standalone]

#9233

On Tuesday, March 1, 2016 at 4:21:47 PM UTC-8, Benjamin David Lunt wrote:
> I have been wanting to get back to what Alex is doing with
> SmallerC.  You added floating point support, did you not?

Yes, this work is in a separate branch:
https://github.com/alexfru/SmallerC/tree/wip_float

The compiler proper recognizes float and double (the latter
being an alias for the former) and implements single precision
floating point support. Increment/decrement and compound
assignment operators aren't supported with floats at the
moment.

Most of the math library is in, but a few pieces are still
to be done (e.g. pow(), cosh()/sinh()/tanh()). printf() works
with floats, but scanf() doesn't and there isn't atof() or
strtod() yet. Nor difftime().

I should throw in a few library tests for a good measure.
Will get there.

> My assembler's floating point support is rough, so this may
> be a great opportunity to test my work.

The compiler proper does not emit FPU instructions or
floating-point constants. It emits calls to support routines
for the arithmetic operations, comparison and conversion and
uses the existing calling convention with everything passed
on the stack and returned in EAX. Floating-point constants
are just integers with the same bit patterns. So, the only
way for you to stress your assembler's floating point is to
actually feed it some hand-written assembly code (or generate
some with a dedicated tool). You could take bits of the math
library and convert them from NASM syntax to NBASM syntax.

But there's an upside to this. You don't need to change the
code generator at all in order to get floats. Just update
the main part of the compiler. Hopefully, there aren't many
collisions with your changes.

> The text of the book, the body, or heart of the book is *not*
> coming along so well.  It is hard to explain the details
> so that a beginner to programming can somewhat understand
> what is going on.  It's a project where you really need
> some programming background to understand the subject.
> I have yet to find that knowledge level where the reader
> should be.  If I assume the reader is fluent in C's Unions
> and Structures, the beginner will be lost.  If I don't,
> a lot of the text is describing the C language.  I find
> myself adding text and removing it, numerous times trying
> to find that line.  Oh well, soon.  :-)

I can relate. :)

Alex

[toc] | [prev] | [next] | [standalone]

#9236

"Alexei A. Frounze" <alexfrunews@gmail.com> wrote in message 
news:66ec3ffd-520d-47e0-b565-16dc520710f2@googlegroups.com...
> On Tuesday, March 1, 2016 at 4:21:47 PM UTC-8, Benjamin David Lunt wrote:
>> I have been wanting to get back to what Alex is doing with
>> SmallerC.  You added floating point support, did you not?
>
> Yes, this work is in a separate branch:
> https://github.com/alexfru/SmallerC/tree/wip_float
>
>
> Most of the math library is in, but a few pieces are still
> to be done (e.g. pow(), cosh()/sinh()/tanh()). printf() works
> with floats, but scanf() doesn't and there isn't atof() or
> strtod() yet. Nor difftime().
>
> The compiler proper does not emit FPU instructions or
> floating-point constants. It emits calls to support routines...

If this is the case, and being that SmallerC is self compilable,
did you compile/assemble the math library with something else?

In the end, the math library must have FPU instructions in
it, therefore, you have to either compile it with another
compiler that does emit these instructions, or you hand
assembled a library.

I guess I will need to go have a look to see what you did.

It surprised me at first that you don't emit FPU instructions,
but then I remembered that most, even modern compilers call
libraries to do the math.

When I get a chance, I will have to take a look and see what
you have done.

Thanks,
Ben

[toc] | [prev] | [next] | [standalone]

#9238

On Wed, 2 Mar 2016 10:28:06 -0700
"Benjamin David Lunt" <zfysz@fysnet.net> wrote:

> > The compiler proper does not emit FPU instructions or
> > floating-point constants. It emits calls to support routines...  
> 
> If this is the case, and being that SmallerC is self compilable,
> did you compile/assemble the math library with something else?

Why would he need floating point to compile the compiler? ...

> In the end, the math library must have FPU instructions in
> it, therefore, you have to either compile it with another
> compiler that does emit these instructions, or you hand
> assembled a library.

The compiler just needs to emit the correct instructions
as assembly, which the compiler can do with printf(), or
as binary, which a compiler could do with byte sequences,
i.e., emits unsigned char's to a binary stream.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#9243

"Rod Pemberton" <NoHaveNotOne@bcczxcfre.cmm> wrote in message 
news:20160302185839.2dea803a@_...
> On Wed, 2 Mar 2016 10:28:06 -0700
> "Benjamin David Lunt" <zfysz@fysnet.net> wrote:
>
>> > The compiler proper does not emit FPU instructions or
>> > floating-point constants. It emits calls to support routines...
>>
>> If this is the case, and being that SmallerC is self compilable,
>> did you compile/assemble the math library with something else?
>
> Why would he need floating point to compile the compiler? ...

The compiler itself? Maybe not, but the included libraries,
maybe so.

As Alex commented in his reply, the simple addition/subtraction
of float's could possibly be in the compiler part itself.
Anyway, somewhere, the/a compiler must aventually generate
FPU instructions.  In the case of SmallerC, the math library.

I was just commenting that if Alex wanted all of, and the
math library would be part of that, all of SmallerC to be
self compilable, SmallerC would have to generate FPU instructions
(putting inline code aside).

>> In the end, the math library must have FPU instructions in
>> it, therefore, you have to either compile it with another
>> compiler that does emit these instructions, or you hand
>> assembled a library.
>
> The compiler just needs to emit the correct instructions
> as assembly, which the compiler can do with printf(), or
> as binary, which a compiler could do with byte sequences,
> i.e., emits unsigned char's to a binary stream.

I see where you are coming from.  SmallerC only generates
asm text for another assembler to assemble.  This is what
I meant, I just didn't express it very well.

Ben

[toc] | [prev] | [next] | [standalone]

#9242

On Wednesday, March 2, 2016 at 9:28:20 AM UTC-8, Benjamin David Lunt wrote:
> "Alexei A. Frounze" <...@gmail.com> wrote in message 
> news:66ec3ffd-520d-47e0-b565-16dc520710f2@googlegroups.com...
> > On Tuesday, March 1, 2016 at 4:21:47 PM UTC-8, Benjamin David Lunt wrote:
> >> I have been wanting to get back to what Alex is doing with
> >> SmallerC.  You added floating point support, did you not?
> >
> > Yes, this work is in a separate branch:
> > https://github.com/alexfru/SmallerC/tree/wip_float
> >
> >
> > Most of the math library is in, but a few pieces are still
> > to be done (e.g. pow(), cosh()/sinh()/tanh()). printf() works
> > with floats, but scanf() doesn't and there isn't atof() or
> > strtod() yet. Nor difftime().
> >
> > The compiler proper does not emit FPU instructions or
> > floating-point constants. It emits calls to support routines...
> 
> If this is the case, and being that SmallerC is self compilable,
> did you compile/assemble the math library with something else?
> 
> In the end, the math library must have FPU instructions in
> it, therefore, you have to either compile it with another
> compiler that does emit these instructions, or you hand
> assembled a library.

Floating point types and operations appear only in fp.c and
srclib\x87.c ("inline" asm code) and aren't used unless
the code being compiled uses floating point. So, in theory,
you could have Smaller C recompile its newer source code
with empty functions f2u(), f2i(), u2f(), i2f(), fneg(),
fadd(), fsub(), fmul(), fdiv(), fcmp() in fp.c (and x87.c
would just compile). The new executable would not be able
to evaluate constant floating-point expressions yet, but
would recognize floating-point types and would be able to
generate proper asm code for floating point otherwise. Then,
after one or two more iterations with progressively more
complete functions in fp.c, you can get full floating-point
support in Smaller C. Of course, none of this hassle is
needed if you have another C compiler.

> I guess I will need to go have a look to see what you did.

A bit too many changes, but nothing drastic otherwise.
I also fixed one or two bugs w.r.t. lvalues and such
(previously in some rarely seen cases you could get your code
miscompiled instead of a compilation error) and a bug in
memcmp().

> It surprised me at first that you don't emit FPU instructions,
> but then I remembered that most, even modern compilers call
> libraries to do the math.

For the primitive operations (like addition, multiplication and
comparison) compilers normally generate instructions (of course,
if the CPU has such instructions), but anything beyond that
(e.g. log() or sin()) can rarely be done with a single instruction
or with just a few (x86/87 is exceptional here) as so for that
the library is used. Don't forget that setting errno may be
needed and that alone expands into a handful of instructions.
Inlining of all of that code will make programs larger and
heavier on the instruction cache.

On top of that Smaller C has to and generate code for a MIPS
CPU that has no floating-point support. So, generating calls
is the commonest(?) ground you can have cheaply.

What's more, I even named the support routines in x87.c the
way gcc and clang expects them to be named. There are open-
source integer-only implementations of those in the
compiler-rt project, e.g. here:
https://github.com/llvm-mirror/compiler-rt/tree/master/lib/builtins
So, for anyone porting the compiler to a new CPU without
f-p support, those routines are available. Once you have
those, you can implement everything on top of them or
yet again borrow some code from e.g. FreeBSD, musl, etc.
Looks like Sun wrote pretty decent implementations of the
math library functions.

Alex

[toc] | [prev] | [next] | [standalone]

#9239

On Tue, 1 Mar 2016 17:21:22 -0700
"Benjamin David Lunt" <zfysz@fysnet.net> wrote:

> The text of the book, the body, or heart of the book is *not*
> coming along so well.  It is hard to explain the details
> so that a beginner to programming can somewhat understand
> what is going on.  It's a project where you really need
> some programming background to understand the subject.
> I have yet to find that knowledge level where the reader
> should be.  If I assume the reader is fluent in C's Unions
> and Structures, the beginner will be lost.  If I don't,
> a lot of the text is describing the C language.  I find
> myself adding text and removing it, numerous times trying
> to find that line.  Oh well, soon.  :-)

Well, they should understand structures if they've had
any high-level language.  If they don't understand
unions, they might understand overlays, which is
similar to using a pointer to a typedef'd struct in
C, setting a pointer to the typedef, then accessing
items via the typedef's struct elements.  A "union"
in an overlay setting would be setting multiple overlays
of different objects to the same region.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#9244

"Rod Pemberton" <NoHaveNotOne@bcczxcfre.cmm> wrote in message 
news:20160302185854.0351de69@_...
> On Tue, 1 Mar 2016 17:21:22 -0700
> "Benjamin David Lunt" <zfysz@fysnet.net> wrote:
>
>> The text of the book, the body, or heart of the book is *not*
>> coming along so well.  It is hard to explain the details
>> so that a beginner to programming can somewhat understand
>> what is going on.  It's a project where you really need
>> some programming background to understand the subject.
>> I have yet to find that knowledge level where the reader
>> should be.  If I assume the reader is fluent in C's Unions
>> and Structures, the beginner will be lost.  If I don't,
>> a lot of the text is describing the C language.  I find
>> myself adding text and removing it, numerous times trying
>> to find that line.  Oh well, soon.  :-)
>
> Well, they should understand structures if they've had
> any high-level language.  If they don't understand
> unions, they might understand overlays, which is
> similar to using a pointer to a typedef'd struct in
> C, setting a pointer to the typedef, then accessing
> items via the typedef's struct elements.  A "union"
> in an overlay setting would be setting multiple overlays
> of different objects to the same region.

My code uses a lot of unions, or as you comment, a better
description would be overlays.

Every item in the GUI is an overlay, so that a single
OBJECT * pointer can be used for any item.  It is then
up to the callee to "extract" the data from the overlay.

My difficulty stands where a beginning reader might not
understand that a "Window object" and a "Text object" can
have the exact same overlay.

Ben 

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.development

csiph-web