What do you think about something like Pascal bytecode?

[winni]

[
Borland Turbo Pascal 2.0 states that there were no default value for String type, so you were forced to always declare String length from 1 to 255.
https://winworldpc.com/download/c38f0125-c3ac-25c3-8511-c3a6e280947e

Yes I was wrong. Just look in my "historic" sources and there is always something like this on top:

Code: Pascal  [Select][+][-]

1. Type string255 = String[255];

Too long ago ...

Winni

[guest64953]

I think all of you misunderstood my idea. Please read my post again 

[tr_escape]

I think all of you misunderstood my idea. Please read my post again 

I think you want to create a pascal virtual machine that works on compiled byte code. Maybe you might be intereset pascalscript project as I remember it has got similar byte code output.

The main problem I think there are a lot of target and you (compiler) have to recreate same / similar ops again for each target subsystem (like as linux windows or js maybe)

[marcov]

I think he wants a dialect mode for minimal backend uses. However he fails to explain what exactly the problem is with the current situation, specially since with 3.0 we have "&"

[Thaddy]

Well, https://sourceforge.net/projects/pascalp5/ is a pascal bytecode compiler(it is actually used in the tests to test ISO conformance in {$mode iso})
And the author sometimes visits this forum. Freepascal - at least 3.2.0 and trunk- can compile this compiler...
Scott Franco, the author, is a bit of a ISO standards guru, at least to me.

His website also contains the original pascal-s and some previous efforts.

[PascalDragon]

By "bytecode" I don't mean something like JVM bytecode, LLVM's bitcode but a very simpilfied Pascal dialect. We will specify this dialect explicitly by ${mode pascal-bytecode}. It will allow others to utilize fpc as a backend compiler. e.g: as gcc with freebasic -gen gcc.

The route is as follow: I want to write an Oberon compiler. There are a bunch of them available, most of them generate low quality machine code. My compiler is in fact compile the Oberon code into an intermediate Pascal bytecode source file then invoke fpc to have the final executable. It's somewhat like LLVM IR but it's higher level than LLVM IR, since it's still Pascal code.

${mode pascal-bytecode} should be designed just for this purpose, it has to be simple enough to allow easily converting other programming languages code into. ObjFPC could be used, of course, I know there are languages compile to C++, but it would be not that easy to machine generate working ObjFPC code, though 

I don't see a use for this. It would mean maintenance of a dialect that has very restricted use. Write a transpiler from Oberon to (Object) Pascal instead and then you can simply use the existing compiler.

[MarkMLl]

By "bytecode" I don't mean something like JVM bytecode, LLVM's bitcode but a very simpilfied Pascal dialect. We will specify this dialect explicitly by ${mode pascal-bytecode}. It will allow others to utilize fpc as a backend compiler. e.g: as gcc with freebasic -gen gcc.

I don't see a use for this. It would mean maintenance of a dialect that has very restricted use. Write a transpiler from Oberon to (Object) Pascal instead and then you can simply use the existing compiler.

Perhaps more to the point, having a compiler emit a bytecode sequence as a well-documented intermediate representation is "very 1980s". With all respect to Scott, Bernd and the other maintainers of historic compilers, the way it's done these days is for the frontend to generate a parse tree which might- or might not- be published and documented: and if OP wants to help document some of the FPC arcana I'm sure his help would be appreciated :-)

Noting that Bernd's port of P4 http://bernd-oppolzer.de/job9.htm runs on at least some of the classic mainframe OSes, I'd add that poor understanding of FPC's internal operation was one of the reasons that FPC didn't get ported to those platforms.

MarkMLl

[Thaddy]

Noting that Bernd's port of P4

Why did he port that? The original author already did that: Scott Franco (a.k.a. Scott Moore). Better use the source, the source and not some vague ports.
BTW: byte code is not in any way dated. It is a tool available to any modern compiler engineer.
Examples are opengl and family, Java, C# etc. It is just that Pascal happens to be one of the oldest.
Another good example is TRegExpr which is a full and fast byte code compiler for regular expressions.

[PascalDragon]

By "bytecode" I don't mean something like JVM bytecode, LLVM's bitcode but a very simpilfied Pascal dialect. We will specify this dialect explicitly by ${mode pascal-bytecode}. It will allow others to utilize fpc as a backend compiler. e.g: as gcc with freebasic -gen gcc.

I don't see a use for this. It would mean maintenance of a dialect that has very restricted use. Write a transpiler from Oberon to (Object) Pascal instead and then you can simply use the existing compiler.

Perhaps more to the point, having a compiler emit a bytecode sequence as a well-documented intermediate representation is "very 1980s". With all respect to Scott, Bernd and the other maintainers of historic compilers, the way it's done these days is for the frontend to generate a parse tree which might- or might not- be published and documented: and if OP wants to help document some of the FPC arcana I'm sure his help would be appreciated :-)

Well, LLVM does also have a bytecode variant... *shrugs*

And yes, help for documenting FPC's internals is definitely welcome.

[Thaddy]

Well, LLVM does also have a bytecode variant... *shrugs*

Ohhhh, big oversight by me again. Of course.

[marcov]

(didn't java ditch interpretable bytecode since the introduction of JIT in what, Java 1.5?)

Bytecode as IR for a compiler and bytecode for interpretation are two different things.

[Thaddy]

(didn't java ditch interpretable bytecode since the introduction of JIT in what, Java 1.5?)

Bytecode as IR for a compiler and bytecode for interpretation are two different things.

the distinction is not made here. And it is the same family.

[hansotten]

Why did he port that? The original author already did that: Scott Franco (a.k.a. Scott Moore). Better use the source, the source and not some vague ports.

IIRC P4 originated at ETH, was built for portability by Wirth's team in the seventies. and was indeed ported to many platforms. Stanford Pascal was one of those ports, for IBM mainframes. Scott Moore was not  the original author, but he did (much later in time!) quite a remarkable job digging up the original source code and publishing it. And made a 'P5' out of it. All compiler-interpreters with p-code (not bytecode!)

[marcov]

Afaik, ETH's P4 was meant as bootstrap compiler because the small bytecode interpreter would be easily portable.
Since the compiler didn't use the full ISO dialect, neither did P4.

That's why Scott made P5, which is P4 expanded to support the full ISO dialect.

[guest64953]

I think he wants a dialect mode for minimal backend uses. However he fails to explain what exactly the problem is with the current situation, specially since with 3.0 we have "&"

Yes. I mean we should have a subset of ObjFPC called PascalBytecode, this dialect specially designed to be generated by machine, not human coder. It's somewhat like asm.js. It will be the target to convert source code of other programming languages into and utilizing fpc to build the final executable. This will very useful if the source languages are also Wirthian languages like Pascal.

e.g: Source language: Oberon -> My Oberon compiler -> Target language: PascalBytecode -> fpc -> executable.

p/s: I don't know what is "&", though