OSDev.org

Posted: **Tue Mar 17, 2020 11:22 am**

mikegonta wrote:And yet you are obviously not interested in a compile time assert statement with a runtime message attached.

It's hard to be interested when you've deleted all of your other posts about your compiler. At least if I download it I'll have something that you can't delete.

Posted: **Wed Mar 18, 2020 12:36 pm**

Not only can nobody download it, it's also not clear what it's supposed to do. What are it's features, non-features and trade-offs compared to existing tools?

Posted: **Wed Mar 18, 2020 1:10 pm**

Korona wrote:Not only can nobody download it, it's also not clear what it's supposed to do. What are it's features, non-features and trade-offs compared to existing tools?

Ah … the post subject is assert that with which just might be one of it's features, non-features and trade-offs that you might want to comment on before you do any downloading.

Posted: **Wed Mar 18, 2020 1:30 pm**

The merits of that feature are not self-evident.

Posted: **Wed Mar 18, 2020 5:06 pm**

Korona wrote:The merits of that feature are not self-evident.

I agree.
The assert statement generally only indicates where the assertion failed. With the addition of an optional formatted message
the location in the code where the failure originated can also be displayed. Of course, this is only something that would be
applicable to compilers, parsers etc.

Code: Select all

The assertion that 'the rider's token is "repeat" or that the rider's token is "break" or that the rider's token is "return"' FAILED
in the routine 'compile the next statement with a rider {single}' in the file '09 - statement.ideom' at line 242
Error in to compile the next statement given a rider {if}.txt - line 102.
The rider's token is 'breaker'!
>>>>> if the rider's token is "otherwise"? compile the next statement given the rider {otherwise} and breaker;

Posted: **Wed Mar 18, 2020 5:17 pm**

I don't know what you think you have here that is special or new or even remotely worth telling us about.

Literally every mainstream language from the last two decades has a testing framework with robust assertions that can provide error messages with the failed assertion, the file it was in, the line number, and "optional formatted display messages".

Posted: **Wed Mar 18, 2020 5:54 pm**

klange wrote:Literally every mainstream language from the last two decades has a testing framework with robust assertions that can provide error
messages with the failed assertion, the file it was in, the line number, and "optional formatted display messages".

Really.
And I suppose "C" doesn't count as a "mainstream language from the last two decades".
I don't see any formatted message.
I don't see the file/line number of the offending code (only the line number of the assert statement).

Posted: **Wed Mar 18, 2020 6:02 pm**

mikegonta wrote:
klange wrote:Literally every mainstream language from the last two decades has a testing framework with robust assertions that can provide error
messages with the failed assertion, the file it was in, the line number, and "optional formatted display messages".
Really.
And I suppose "C" doesn't count as a "mainstream language from the last two decades".
I don't see any formatted message.
I don't see the file/line number of the offending code (only the line number of the assert statement).

C is from 1972, so, no.

Posted: **Wed Mar 18, 2020 6:12 pm**

Here is an example from Python:

Code: Select all

def foo(bar):
    assert bar > 5, f"bar should be greater than five, but it was {bar}"

def some_other_function():
    foo(4)

some_other_function()

This will produce the following traceback, which includes the complete stack trace that led to the failed assertion, and has a formatted message:

Code: Select all

Traceback (most recent call last):
  File "test.py", line 7, in <module>
    some_other_function()
  File "test.py", line 5, in some_other_function
    foo(4)
  File "test.py", line 2, in foo
    assert bar > 5, f"bar should be greater than five, but it was {bar}"
AssertionError: bar should be greater than five, but it was 4

Posted: **Wed Mar 18, 2020 6:15 pm**

Here is an example in Java:

Code: Select all

class TestThing {
    public static void foo(int bar) {
        assert bar > 5 : "bar should be greater than five, but it was " + bar;
    }
    public static void main(String args[]) {
        foo(4);
    }
}

Again, I get a traceback with all the function calls that led to the assertion failure, as well as a formatted message:

Code: Select all

Exception in thread "main" java.lang.AssertionError: bar should be greater than five, but it was 4
	at TestThing.foo(TestThing.java:3)
	at TestThing.main(TestThing.java:6)

(A common Java testing library, JUnit, provides an extensive assertion module with lots of useful functions for automatic pretty-printing of assertion conditions and actual vs. expected values: https://junit.org/junit4/javadoc/latest ... ssert.html)

Posted: **Wed Mar 18, 2020 6:43 pm**

klange wrote:Here is an example in Java:

Well at least I'm in good company.
the-ideom (which is written in ideom) is only a small simple single pass (concept oriented) imperative compiler (which compiles itself directly to a WIN32 executable).

Posted: **Thu Mar 19, 2020 1:35 am**

mikegonta wrote:the-ideom (which is written in ideom) is only a small simple single pass (concept oriented) imperative compiler

mikegonta wrote:the-ideom can re-compile itself in less than 1 second (on my Celeron NUC) and requires 4 passes to generate the code.

I see your compiler has gone from four passes to one. What changed?

And why did you delete your post about how the-idiom is able to translate various control flow constructs into a consistent internal representation?

Posted: **Thu Mar 19, 2020 9:51 am**

Octocontrabass wrote:
mikegonta wrote:the-ideom (which is written in ideom) is only a small simple single pass (concept oriented) imperative compiler
mikegonta wrote:the-ideom can re-compile itself in less than 1 second (on my Celeron NUC) and requires 4 passes to generate the code.
I see your compiler has gone from four passes to one. What changed?

Terminology.

the-ideom does a single pass over the entire source (including any included files).

It is during this pass that the high level ideom abstract concepts are extracted.
These include type and global definitions, global bodies, routine headers and routine bodies.
These can be used and defined in any order, as well as used before defined.
During the analysis stage the-ideom reduces these to their conceptual common denominators and
represents them internally in a flat list-like internal representation.
A routine's fragments represent the statements and structure of the routine.
During the transmogrifying (code generating) stage a series of consolidations take care of
what is normally referred to as simple optimizations. Other consolidations such as constant folding,
operator precedence and parenthesis are actually taken care of during the initial analysis and transformed
for the IR.

There follows 4 distinct and well defined passes over all and then some of the IR during the outputting of x86 machine code.

The first such pass generates the machine code and the addresses of the individual fragments.
This is an "optimistic" process in that the shortest form of the intel instructions is initially assumed.
This applies to relative jumps. There are also short form instruction which use an offset - the EBP based
frame pointer local variables. the-ideom has, prior to code generation sorted these local variables by usage
so that the most frequently used are located closer to the start of the frame.

The next pass is to resolve the obvious differences in instruction size for those jump relative instructions
in which the actual distance is greater than the initial optimistic assumption.

The third pass is to resolve the former short distance relative jumps which are now longer due to the increase
lengths of the previous pass. The three passes guarantee generation of the shortest possible instructions.
There are however a small group of alternate instructions which are in some cases shorter which the-ideom does
not currently employ.

After these three passes a virtual address for the data can be calculated. The data sections are then generated.

The fourth pass is more like a "linking" pass than code generation (the-ideom currently generates the PE executable
directly). Now that the data has been addressed. These addresses as well as the final addresses of the routines are
filled in.

Posted: **Thu Mar 19, 2020 11:06 am**

mikegonta wrote:the-ideom does a single pass over the entire source (including any included files).

[...]

There follows 4 distinct and well defined passes over all and then some of the IR during the outputting of x86 machine code.

So it's a single-pass compiler, and a four-pass assembler.

Any particular reason you chose to directly output machine code?

I notice you did not answer my question about your deleted post. Why is that?

Posted: **Thu Mar 19, 2020 11:52 am**

Octocontrabass wrote:
mikegonta wrote:the-ideom does a single pass over the entire source (including any included files).
[...]
There follows 4 distinct and well defined passes over all and then some of the IR during the outputting of x86 machine code.
So it's a single-pass compiler, and a four-pass assembler.

No actual assembly language is generated and there is no assembler. The (integrated) code generator "assembles" the machine code.
In the past the axiomatic concepts consisted of hex string statements such as $BADBEEF; which were the machine code for those
particular low level routines. For example:

Code: Select all

to put a u32 into another u32:
  $8B7424048B7C24088B068907;
end;

The ideom definition is:

Code: Select all

to put a u32 into another u32:
  put the u32 into the other u32;
end;

It is these axiomatic concepts (low level CPU instructions) that the higher level ideom concepts (routines) are based on.
That's really all the-ideom knows about these axioms (as much as any other compiler), the rest is up to the code generator.

the-ideom is a very simple thing. At the highest level of abstraction (the source file) - did I mention that ideom is a
concept oriented programming language - the-ideom only deals with 4 abstract concepts

routines - begin with 'to'
types - begin with an indefinite article (a, an, some)
globals - begin with the definite article (the)
include files (include "file", "file";)

and everything else is ignored. For example here is the start of an ideom file:

Code: Select all

the-ideom by Mike Gonta, 2020

This is a comment, just don't start the line with the, a, an, some or include.
\ Actual comments can start with \ and extend to the end of the line
Remarks are enclosed in [ and ] and can be nested and extend across any number of lines.

****************************************************************************************************

to run:

Octocontrabass wrote:Any particular reason you chose to directly output machine code?

The generation of x64, elf for Linux, C and object file format are on my todo list.
the-ideom was derived (with permission) from the closed source (albeit available for reading/studying)
Plain English compiler and that's how it works.
Since then I have added many changes and today ideom is it's own language.

The tldr; link to the source is at that site.

Octocontrabass wrote:I notice you did not answer my question about your deleted post. Why is that?

Because I can.

OSDev.org

assert that with (have you hugged your compiler today)

Re: assert that with (have you hugged your compiler today)

Re: assert that with (have you hugged your compiler today)

Re: assert that with (have you hugged your compiler today)

Re: assert that with (have you hugged your compiler today)

Re: assert that with (have you hugged your compiler today)

Re: assert that with (have you hugged your compiler today)

Re: assert that with (have you hugged your compiler today)

Re: assert that with (have you hugged your compiler today)

Re: assert that with (have you hugged your compiler today)

Re: assert that with (have you hugged your compiler today)

Re: assert that with (have you hugged your compiler today)

Re: assert that with (have you hugged your compiler today)

Re: assert that with (have you hugged your compiler today)

Re: assert that with (have you hugged your compiler today)

Re: assert that with (have you hugged your compiler today)